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 <[EMAIL PROTECTED]> 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 > _______________________________________________ > [email protected] mailing list > http://lists.hosef.org/cgi-bin/mailman/listinfo/luau > -- Dwight Victor Resident Mad Scientist and All Around Good Guy [EMAIL PROTECTED]
