[LUAU] Excellent SSH advice
Dwight Victor
dwight.victor at gmail.com
Wed Jan 12 11:31:56 PST 2005
If you know the IP addresses of the machines that you'll be SSHing
from...it's best to compile your version of SSH to support
tcp_wrappers and configure your /etc/hosts.allow and /etc/hosts.deny
files to only allow SSH access from your know IP addresses.
This also helps cut down on those irritating automated SSH attacks.
Dwight...
On Fri, 17 Dec 2004 10:53:51 -1000, R. Scott Belford <scott at hosef.org> wrote:
> In monitoring the K12OSN list, the following piece of SSH advice was
> eloquently shared by a gentleman by the name of Rob Owens. It is so
> good that it *must* be shared.
>
> Quoted from Rob Owens
>
> "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:
> PasswordAuthentication no
>
> How then will the user be authenticated? Using keys.
> PubkeyAuthentication yes
>
> 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):
> PermitEmptyPasswords no
>
> 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.
>
> MaxStartups
> 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.
>
> PermitRootLogin no
> 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.
>
> AllowGroups
> AllowUsers
> 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."
>
> Quoted from Rob Owens
> _______________________________________________
> LUAU at lists.hosef.org mailing list
> http://lists.hosef.org/cgi-bin/mailman/listinfo/luau
>
--
Dwight Victor
Resident Mad Scientist and All Around Good Guy
dwight.victor at gmail.com
More information about the LUAU
mailing list