Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

What measures can/should I take to make sure that security around my SSH server is absolutely impermeable?

This will be community wiki from the start, so lets see what people does to secure their servers.

share|improve this question
9  
Absolute impermeability requires turning the box off. –  Thorbjørn Ravn Andersen Aug 16 '10 at 15:44
    
@Thorbjørn, Helt sikkert! The best way to secure any application is to turn off your computer... –  Source Lab Aug 16 '10 at 17:30
    
What if you have Wake-on-LAN? –  rebus Oct 20 '10 at 23:11
    
The problem would be the LAN part... Wake-on-LAN packages are not routed, so you would have to have access to a machine inside the LAN to send the WOL package... –  Source Lab Oct 22 '10 at 7:56
add comment

7 Answers

up vote 14 down vote accepted

Make the sshd block client IP's that have failed to supply correct login information "DenyHØsts" can do this job quite effectively. I have this installed on all my Linux boxes that are in some way reachable from the great outside.

This will make sure that brute force-attacks on the sshd wont be effective, but remember! this way you can end up locking your self out if you forget you password. This can be a problem on a remote server that you don't have access to.

share|improve this answer
    
Is there some option like 10 failed login attempts before banning the ip address? –  Bolt64 Feb 26 at 14:48
add comment

I would suggest using fail2ban to prevent brute force login attempts.

Disabling logging in as root via SSH. This means an attacker had to figure out both the username and the password making an attack more difficult.

Add PermitRootLogin no to your /etc/ssh/sshd_config

Limiting the users that can SSH to the server. Either by group or just specific users.

Add AllowGroups group1 group2 or AllowUsers user1 user2 to limit who can SSH to the server.

share|improve this answer
add comment

Use public/private key pairs for authentication instead of passwords.

  1. Generate a passphrase-protected SSH key for every computer that needs to access the server:

    ssh-keygen

  2. Permit public-key SSH access from the allowed computers:

    Copy the contents of ~/.ssh/id_rsa.pub from each computer into individual lines of ~/.ssh/authorized_keys on the server, or run ssh-copy-id [server IP address] on every computer to which you are granting access (you'll have to enter the server password at the prompt.)

  3. Disable password SSH access:

    Open /etc/ssh/sshd_config, find the line that says #PasswordAuthentication yes, and change it to PasswordAuthentication no. Restart the SSH server daemon to apply the change (sudo service ssh restart.)

Now, the only possible way to SSH into the server is to use a key that matches a line in ~/.ssh/authorized_keys. Using this method, I don't care about brute force attacks because even if they guess my password, it will be rejected. Brute-forcing a public/private key pair is impossible with today's technology.

share|improve this answer
1  
-1: Generally access is granted to individual not computers, creating a key for each potential client computer connecting to the server is unreasonable. Your last statement is not correct, per your sugestion and because you didn't suggest to set a passphrase for the private keys having access/compromising of any of the client systems would automatically grant access to the SSH server. SSH key authentication is recommended but the private keys must properly protected and it should be used on an individual basis, not in a distributed fashion as described. –  João Pinto Aug 14 '10 at 18:41
3  
"Generally access is granted to individual not computers, creating a key for each potential client computer connecting to the server is unreasonable" There are many options and I think describing how to securely transfer a private key to every client seems outside the scope of this question. I'm not presenting all options, just a simple one that I think people can understand. "... should be used on an individual basis, not in a distributed fashion as described" This seems to contradict your previous statement and I did not describe anything as distributed. –  Asa Ayers Aug 15 '10 at 3:17
2  
"impossible" is perhaps overdoing it a bit. –  Thorbjørn Ravn Andersen Aug 16 '10 at 15:46
1  
This is why I say "impossible". No one has computers this fast this small this many or that much time. "Imagine a computer that is the size of a grain of sand that can test keys against some encrypted data. Also imagine that it can test a key in the amount of time it takes light to cross it. Then consider a cluster of these computers, so many that if you covered the earth with them, they would cover the whole planet to the height of 1 meter. The cluster of computers would crack a 128-bit key on average in 1,000 years." –  Asa Ayers Aug 16 '10 at 16:22
add comment

If I want to have some additional security or need to access SSH servers deep inside some corporate network I setup a hidden service by using the anonymisation software Tor.

  1. Install Tor and setup the SSH server itself.
  2. Make sure sshd only listens at localhost.
  3. Open /etc/tor/torrc. Set HiddenServiceDir /var/lib/tor/ssh and HiddenServicePort 22 127.0.0.1:22.
  4. Look at var/lib/tor/ssh/hostname. There is a name like d6frsudqtx123vxf.onion. This is the address of the hidden service.
  5. Open $HOME/.ssh/config and add some lines:

    Host myhost
    HostName d6frsudqtx123vxf.onion
    ProxyCommand socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050

Furthermore I need Tor on my local host. If it is installed I can enter ssh myhost and SSH opens a connection via Tor. The SSH server on the other side opens its port only on localhost. So nobody can connect it via "normal internet".

share|improve this answer
    
Security by advanced obscurity, but very interesting. –  JoBo Aug 29 '13 at 9:25
add comment

Here's one easy thing to do: install ufw (the "uncomplicated firewall") and use it to rate limit incoming connections.

From a command prompt, type:

$ sudo ufw limit OpenSSH 

If ufw is not installed, do this and try again:

$ sudo aptitude install ufw 

Many attackers will try to use your SSH server to brute-force passwords. This will only allow 6 connections every 30 seconds from the same IP address.

share|improve this answer
    
+1 Using limit can be good. However should point out I have encountered issues when using the built in sftp server as it limits the connections for this as well. –  Mark Davidson Aug 15 '10 at 9:40
1  
@Mark - good point, but doesn't that sound like a poorly written SFTP client? Why would they keep reconnecting to the SSH port when they could just open more SSH channels? –  Mike Aug 24 '10 at 4:32
add comment

Other answers provide security, but there is one thing you can do which will make your logs quieter, and make it less likely that you'll be locked out of your account: Move the server port from 22 to another port. Either at your gateway, or on the server.

It doesn't increase the security, but does mean all the random internet scanners won't clutter up you log files.

share|improve this answer
1  
For those who belive in security by obscurity (en.wikipedia.org/wiki/Security_through_obscurity) it makes a lot of sense to use another port. I don't though.. –  Source Lab Aug 15 '10 at 10:19
4  
It's not about Security Through Obscurity (although the obscurity can have a marginal positive effect). It's about reducing the background noise of endless brute force attempts. You can't usefully audit your access failure logs if they're full of automated attacks; fail2ban doesn't reduce the volume enough given the number of attackers and the prevalence of distributed (botnet) and throttled attacks. With ssh on an unusual port, you know attacks you see in the logs come from a real attacker interested in your box. I strongly recommend it. –  bobince Oct 12 '10 at 0:19
add comment

There is a Debian Administration article on this topic. It covers basic SSH server configuration and also firewall rules. This could be of interest also to hardened an SSH server.

See there article: Keeping SSH access secure.

share|improve this answer
1  
Bit late, but please, when answering questions, copy the important parts from a link so that if the link decays the information is still here. –  umop aplsdn Aug 28 '12 at 4:54
1  
Good idea. Although I am through a period with much less time to participate. My answer is a "community wiki" so feel free to add the link information if you have the time. –  Huygens Sep 11 '12 at 19:42
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.