[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