root@metasploitable:/etc/ssh# service sshd restart
service sshd restart
The program 'service' can be found in the following packages:
* debian-helper-scripts
* sysvconfig
Try: apt-get install <selected package>
bash: service: command not found



Please help...

Hi, and welcome here, at LQ
first of all cracking is not allowed on LQ, so we can't really help you to do that.
Your post contains no usable information about your system and environment, dropping in an error message is not really sufficient to help you. So please read the rules and also this page: https://www.catb.org/esr/faqs/smart-...html#beprecise

service is the old command. Most systems use systemctl, and the verb is first like "systemctl start sshd". Do a "systemctl status sshd" to see the service's status.

as for pass cracking. no help.

but note SSHD used to install on debian with "signing that appeared to make random keys for security" which infact did NOT protect the debian machine from remote login.

it is up to you to test it / make sure your version of (debian) is actually not a root kit

1 members found this post helpful.

It takes a little work to do this, but you should configure sshd so that digital certificates are required and so that it will not "fall back to 'simple passwords.'"

Although ssh's handling of certificates is still very weak, especially since you can "slip in" a new accepted key without being noticed, it does effectively stop the "brute force attacks" which will otherwise consume a tremendous amount of system resources. Either you have an acceptable key or you don't.

Certificate-based openVPN is far stronger, particularly because an end-user cannot directly specify the set of keys which are allowed. (The keys are not "per-user.") Here you can set things up so that you must first "cross the openVPN moat" before you even get a chance to reach the "ssh portcullis." You can set things up so that the presence of openVPN is hidden: there are no "open ports" to "scan." I wrote an article about this on my own website entitled "Number of Unauthorized Access Attempts: Zero." A key benefit of openVPN is that it runs at the level of the network stack. "It's just there."

Could you just stop fabricating nonsense please?

2 members found this post helpful.

Hmm, maybe not fabricating but misunderstanding or misrepresenting. Possibly prompted by
https://www.debian.org/security/2008/dsa-1571.

Just wanted to add that "password cracking" is an entirely legitimate activity, if performed as part of a security audit. In fact, it would be a dereliction of duty for a sysadmin not to do this regularly in order to expose users (deliberately or accidentally) circumventing policy.

I don't think so. I think the quality of passwords is checked when they are typed. So you can't use something that doesn't fit into the rules. Hacking passwords (and knowing other people's passwords) in my opinion (at my company) is not allowed for anyone for any reason.
If you change the rules you can force the people to change their passwords.

The word lists are constantly updated, and the methodologies of password guessing change over time as well.

Besides, it's not practically possible to implement a realtime password validator that goes through thousands of permutations of every phrase in a reasonably-sized list.

In BLFS you can build and install a program called CrackLib which monitors entered passwords for quality and rejects those that are easily cracked. But if you install it, you have to rebuild shadow to take advantage of it.

2 members found this post helpful.

But, there are a few "reality checks" that you can apply when someone wants to focus too-much on "password cracking" ...

• Can an outsider actually situate himself into the position where he could actually exploit a "vulnerable" password?

• And, if he did, would he thereby gain sufficient access to be "significant?"

• And, if he did, is it reasonable that he would actually know "what to do next," unless our "intruder" was actually an insider?

• Would our supposedly-ignorant "intruder" actually be able to try "the right" password before tripping other conventional defenses such as "failed password count locks?"

"Portals" that might be accessible to authorized employees, who might actually be in the position to use such passwords, should be stoutly protected by properly-implemented VPNs, not(!) SSH! To enter the front hall of the building, you must first have a unique badge. Once inside that front hall, you will be given the opportunity to present a password. Two layers of defense.

IMHO, "SSH" should never be your first, public-facing, line of defense! Because this will directly(!) present any potential intruder with the following irresistible target:

login:

Instead, let "SSH" be your portcullis, while VPN is your moat. (Ideally, if using "OpenVPN" and tls-auth, with a hidden(!) drawbridge.)