[K12OSN] ssh security
robowens at myway.com
Fri Dec 17 11:45:22 UTC 2004
The topic of ssh security was touched upon in the "uh oh" thread. I have a couple comments about it.
I recommend disabling password authentication in sshd_config:
How then will the user be authenticated? Using keys.
Any user who wishes to use ssh must generate a key using the ssh-keygen utility. Note that the key can utilize a passphrase if desired.
The advantages of this setup are as follows:
Suppose I am a hacker. I see that your server is listening for ssh attempts. I start attempting at guessing usernames. If I manage to guess that you have a user named "John", then I need to guess has password. Unless John doesn't even have a password! To cover this scenario, your sshd_config file should contain this line (I believe it is the default in most systems):
So I guess that John's password is "computer2004" and now I'm in. But if password authentication was disabled, I'd need to have John's key. A key is a large (I forget how many bits), seemingly random string of characters. If I managed to steal a copy of John's key somehow (maybe it was on a floppy disk that I stole from him), I would still need to guess his passphrase in order to activate the key. This is of course assuming he used a passphrase when he generated the key.
Your regular user password needs to be secure enough to keep people with physical access to your machines from logging in as you. You might feel comfortable with a password that is 10 characters long. But ssh allows anybody on the internet to try to log in as you. For this you might not be satisfied with a 10 character password and instead require 20 or 30 characters. But a 30 character password is a pain in the neck to type in every time you log into your machine. This is why keys and passphrases are so great. You have extra protection for remote access, but you are not hassled when trying to log in locally. Your ssh passphrase can be 30 characters long, and you can keep your 10 character local password.
Some other precautions to take with ssh are:
LoginGraceTime -- the default is 120 (seconds) but you can shorten it. This gives a hacker less time to guess at your passwords, keys, or passphrases before he is forced to re-initiate contact w/ your server.
This is the maximum # of unauthenticated users who can attempt authentication at the same time. The default is 10 on my system. Keep this to a reasonable amount so that a hacker cannot run 50 simultaneous attempts that are all working in unison, guessing login names and passwords. If the admin is the only one using ssh, then setting this to 1 would be good. Note that this does not control the maximum simultaneous ssh sessions, just the maximum simultaneous connection attempts.
Every hacker knows there is a user named "root" on your system. Don't allow root to ssh. Instead, ssh as your regular user and then su to become root. The hacker will then need to guess 2 sets of passwords in order to do get root access.
These options are self-explanatory. If the administrator is the only one who needs to use ssh, then don't allow anybody else access. That makes for a lower number of valid login names for a hacker to guess at.
One more note about keys:
ssh uses keys for its data encryption and as a way to verify the identity of the machines. These are the files you'll find in /etc/ssh. These keys are typically generated automatically by the ssh package you install. This is different that the keys I referred to above. The keys I'm talking about are used for user authentication, and they are found in the appropriate subdirectories of ~/.ssh on the local and remote machines.
I'm not an expert on this, I've just read up on it a bit. If I've left anything out or made any mistakes, somebody please post it.
No banners. No pop-ups. No kidding.
Make My Way your home on the Web - http://www.myway.com
More information about the K12OSN