Best SSH Practices?

L

liquidcypher

Weaksauce
Joined
Jun 15, 2003
Messages
104
I have a SUSE 10.1 Box. I originally set it up just to learn on, but have come to love the features and hosting capabilities.

Now that it’s staying, I would like to make it more secure. I have seen multiple references to adding restrictions on SSH so that people can’t use root or try brute force attacks by limiting the number of incorrect tries in a certain time frame.

How do you do this on SUSE 10.1?

Thanks in advance for the help.

Liquid
 
http://denyhosts.sourceforge.net/faq.html#1_3

What steps can I take to make sshd more secure?

OpenSSH has many settings that can be adjusted in order to increase security. You may wish to refer to OpenSSH security websites or to the many books on the subject. However, here are some things that you may wish to consider based on my experience:

1. Disable logins to root. This can be accomplished by setting the PermitRootLogin setting in the sshd_config file (typically, /etc/ssh/sshd_config).
PermitRootLogin no

2. Disable password logins entirely by editing the PasswordAuthentication setting. By doing so, each user with access to the server will need to create ssh keys (which is beyond the scope of this document).
PasswordAuthentication no

3. Run sshd on a different port. By default, sshd runs on port 22. Most sshd hackers will only attack port 22 so if you run sshd on a different port, the chances of being compromised are reduced dramatically. However, by running sshd on an alternate port requires each user to be aware of this (so if your server is accessed by many user accounts then this solution might not be feasible). To run sshd on an alternate port simply edit the sshd_config and set the Port setting appropriately:
Port 9922

To access yourserver running on port 9922 you would connect using the -p command line option:
$ ssh -p 9922 yourserver

Alternatively, you can edit your $HOME/.ssh/config file or your site-wide /etc/ssh/ssh_config file and add an entry similar to:

Host yourserver
Port 9922

4. Install DenyHosts!

Note: After saving changes to the sshd_config file you will need to restart the sshd server for these settings to take effect
Click to expand...
 
Their is also fail2ban for the brute force catching. You might compare that to the deny host and see which one you like better.


By the way, even if you disable password logins in sshd_config if you enable pam and have
Code: 
ChallengeResponseAuthentication yes
then passwords will still work, set that to
Code: 
ChallengeResponseAuthentication no
and then ssh keys are the only way to get in (might not be perfect for every one).

Another thing, depending on what version of OpenSSH, you can also do
Code: 
PermitRootLogin without-password

This will allow direct root login, but only using some other method (ssh keys, kerberos, etc)

BTW, I didn't put the spaces between the n and authenticatio
 
Xipher said:
...
Another thing, depending on what version of OpenSSH, you can also do
Code: 
PermitRootLogin without-password

This will allow direct root login, but only using some other method (ssh keys, kerberos, etc)

...
Click to expand...
IMO, do not ever login as root via SSH, it is bad practice -- I don't care what you are doing, you don't need to login as root over ssh. You can use su and sudo for stuff that needs root access from a regular user account.

Personally, I have firewall rules that only allow SSH from trusted hosts. period. Black Hole all other traffic that doesn't need to go to the machine.

If you absolutely need to have public SSH access (unless you are doing hosting / shells..probably not?) I second the fail2ban / denyhosts methods of stopping bruteforce attacks on your ssh server.

Since you mentioned hosting, you may want to look into chrooting your users into their home directories (or web directories, or whatever) so they have no access to anything else on the system.
I've never done this on anything other than FreeBSD, but a google search quick turned up: http://chrootssh.sourceforge.net/index.php .. that might be worth looking at.

In all reality, you need to have a combination of all of the above methods that have been posted -- using access control via firewalls, configuring fail2ban (or some brute force mitigation software) and tweaking the SSH config so that you only allow pubkey logins.
 
Awesome info. I am going to give it a try tonight, and i will post what I came up with tomorrow.
 
I agree in disabling direct root access, this is a good practice and gives you some trail (logs) to follow. I am simply mentioning it in for others to reference.

I tried and dropped the trusted host thing. It's not about trusted hosts either, it's about trusted networks, if your not on a network/address in your list, you may still be on a trusted host (your laptop maybe) but on a untrusted network (hotel, etc). You can still trust the host, but if your not able to hop threw a machine in a trusted network, your SOL. I rather just black hole any one trying to brute force, and let myself in using a private key I keep that is password protected. This has worked well for me so far. If you need or want more control their is nothing wrong with that, just saying it can be a bigger pain then it's worth.
 
fail2ban is awesome. It took me 30 seconds to setup. Right now I'm seeing if it unbans me from my own server, 5 minutes to go. Not to worried, I'm ssh'ed in from another machine now.

Edit, yup, it works. Awesome.
 
You must log in or register to reply here.
Back
Top