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
12  
Absolute impermeability requires turning the box off. –  Thorbjørn Ravn Andersen Aug 16 '10 at 15:44
    
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

10 Answers 10

I wrote a small tutorial on doing this recently. Basically, you need to be using PKI and my tutorial also shows how to use Two-Factor Authentication for even more security. Even if you use none of those things, there's also some tidbits about securing the server by removing weak cipher suites and other basics. https://joscor.com/2014/09/hardening-openssh-server-ubuntu-14-04/

share|improve this answer

I like Robie Basaks answer.

You might want to checkout the FreeOTP app from RedHat instead of using Google Authenticator. Sometimes when updating the app, they lock you out! ;-)

If you want to use other hardware tokens like a Yubikey or an eToken PASS or NG or if you have many users or many servers, you might want to use an opensource two factor authentication backend.

Lately I wrote a howto about this.

Kind regards

Cornelius

share|improve this answer

Enable two factor authentication with HOTP or TOTP. This is available from 13.10 onwards, so the current LTS release (14.04 Trusty Tahr) includes it.

This includes using public key authentication over password authentication as in another answer here, but also requires the user prove he holds his second-factor-device in addition to his private key.

Summary:

  1. sudo apt-get install libpam-google-authenticator

  2. Have each user run the google-authenticator command, which generates ~/.google-authenticator and helps them configure their two factor devices (eg. the Google Authenticator Android app).

  3. Edit /etc/ssh/sshd_config and set:

    ChallengeResponseAuthentication yes
    PasswordAuthentication no
    AuthenticationMethods publickey,keyboard-interactive
    
  4. Run sudo service ssh reload to pick up your changes to /etc/ssh/sshd_config.

  5. Edit /etc/pam.d/sshd and replace the line:

    @include common-auth
    

    with:

    auth required pam_google_authenticator.so
    

More details on different configuration options are my blog post from last year: Better two factor ssh authentication on Ubuntu.

share|improve this answer

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
2  
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

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
3  
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

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
5  
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

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

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
1  
Security by advanced obscurity, but very interesting. –  JoBo Aug 29 '13 at 9:25

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
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

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.