.
![[ Powered by Fedora Core ]](/icons/powered_by_fedora.png){kind=icon}
****** Distribution unlimited. Feel free to post to the world. -wsr *******
Someone from (or pretending to be from) Romania has written a relatively fast ssh-attacking program. One afternoon our main machine logged 8500 password guessing attempts in 2.5 hrs. If the attack had kept up for a week it would have allowed the attacker to test 0.5 million passwords. That is a wide enough search that even some "good" passwords that aren't in any dictionary might have been discovered.
Logins using 1k-bit RSA or DSA keys are still immune to this sort of brute force attack. Even someone trying 500,000 keys out of a potential 21024 or 1.797693134 x 10308 keys [1] will barely scratch the surface. My feeling is that it is time to turn off unix password logins for ssh and use the superior protection offered by RSA or DSA public keys.
To secure openssh, edit /etc/ssh/sshd_config and add these lines while removing or commenting out any conflicting lines.
Protocol 2
PermitRootLogin without-password
PasswordAuthentication no
ChallengeResponseAuthentication no
ClientAliveInterval 60
ClientAliveCountMax 30
UsePAM no
The first line says to stop using the old, lower security ssh protocol-1.
The second line is a hedge that says never allow root logins using the unix password -- always use some other authentication.
The third line says don't allow ssh to use unix passwords at all.
The fourth line says don't allow skey authentication. It is a good idea to turn this off if you aren't using skey at this time. (Skey implements a series of non-reusable, one-time passwords. If you were using it you would know.)
The fifth and sixth lines simply make sure that any connection to a client that doesn't respond at least once each half hour gets closed. (This prevents dead connections from building up and helps keep a remote user's NAT translation tables fresh by having sshd send a packet each minute.)
The "UsePAM no" line says never bypass the ssh login settings by also allowing pam authorized logins. This line may or may not generate an error depending if PAM was already turned off at ssh compile time. (Unfortunately it isn't possible to easily tell if pam was compiled in, so the only choice is to try it with this line and comment it out if it generates an error. Remember, a future ssh may have it compiled in so you want to keep this line here but commented out to remind you to test it again after any upgrades.)
After editing the sshd file, restart sshd or reboot for the changes to take effect.
Next one has to make the RSA or DSA keyfiles for each user. To do this go to the LOCAL machines one wants to log in *from* and run:
ssh-keygen -t rsa
It will ask for the keyfile name. Just hit return. Next it will ask for your passphrase. Most people will want to use their unix passwords, although one is free to choose as long a sentence or phrase as one wants. The longer the harder to guess, but also the more cumbersome it is to type. This passphrase protects the private key. In order to break into the computer that attacker would need to have the encrypted secret key file and the passphrase. This would let them decrypt the secret key file and use that secret key to log in.
Now that the secret and public key has been generated, one needs to copy the public key from the LOCAL machine to the REMOTE machine. One way would be to mail it to oneself at the destination machine.
mail myself@REMOTE-MACHINE.example.com < ~/.ssh/id_rsa.pub
At the REMOTE machine one would copy that one-line key to the file ~/.ssh/authorized_keys . Sshd is very picky about file permissions. It won't allow the keys to be used if the .ssh directory or authorized_keys file is world or group writable. We have to play along and set the permissions as follows:
chmod 755 ~/.ssh
chmod 644 ~/.ssh/authorized_keys
To reiterate, the LOCAL machine is the one that needs to have the ssh-keygen created files ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub . The REMOTE machine is the one that needs to have the ~/.ssh/authorized_keys file.
Obviously, and just for completeness, one would make sure that all other login services such as telnet, ftp, rsh etc would be turned off in /etc/inetd.conf . In fact /etc/inetd.conf should ideally be empty. (Ours only has a single line for starting the "ident" server on both ipv4 and ipv6. Even that is optional.) On linux systems the inetd config file is called /etc/xinetd.conf and it usually includes all the files in /etc/xinetd.d . One needs to make sure all the login services in the xinitd.d directory are also turned off (with a "disable = yes" in their settings).
Q: Can I copy the ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub files to different machines.
A: Sure. It gives you slightly finer control when you make fresh id_* files on each machine but coping them around is ok too. (You must copy id_rsa and id_dsa with a secure copy mechanism. It is safer and easier to just make a new key on each machine.)
Q: I use a computer that is running a Microsoft operating system. What should I do?
A: What you should really do is install a secure operating system [2] which will come with the latest version of ssh. Barring that, you can install putty, an ssh for MS systems.
Follow putty's instructions for generating an rsa secret/public key pair. Mail the public key (and only the public key!) to the REMOTE machine and install that key into the REMOTE machine's ~/.ssh/authorized_hosts as above. If you mail the secret key by mistake, it is best to generate another key pair and try again.
Q: How do I tell if someone was trying to break into my system via sshd?
A: There is usually a log file that logs sshd activity. On linux systems I have seen it called /var/log/secure. On bsd systems /var/log/authlog. Look for:
sshd ... Failed password for ... from ...
The following command run as root should help summarize the ssh activity.
grep sshd /var/log/secure | more
1 - Thats 1 followed by 308 zeros. A very big number indeed.
Someone testing 1 billion passwords per second for the whole lifetime of the universe (very roughly 10 billion years) would have covered less than 1/10281 of the possibilities. Thats 1 over 10 followed by 280 more zeros.
2 - Any current offering from the following sites should be more than good enough:
(or any of the other fine linux distributions, too numerous to mention individually.)
.
wolfgang.rupprecht+web@gmail.com
(Wolfgang S. Rupprecht)
WSRCC Home Page || Up One
Level
..