Skip to main content

Beyond Passwords: 5 Ways To Prevent Unauthorized Logins

security ssh sysadmin

Hard-to-guess passwords are important to securing your network from intrusion. But think about it from the perspective of someone (or their robot app) trying to break in. They need to also pick the right user name and point of entry, and have enough opportunity and patience to repetitively guess until they hit on the right combination. You’ll quickly see that other measures are just as significant – and easier to implement on your OpenSSH server.

Of course, these steps won’t make your site bulletproof. They will make it less appetizing to hackers than sites with an open door policy. That’s a competition you should keep in mind. There’s a joke where two backpackers are pursued by a grizzily bear. In the middle of flight, one suddenly sits down and calmly starts changing from hiking boots into track shoes. His partner yells, “What are you doing? You know you can’t outrun a grizzily.” The man replies,“I don’t have to outrun him. I just have to outrun you.”

1. Restrict SSH Users and Privileges
#

Some of your users only need to transfer files. Why risk giving them SSH accounts, which could be hijacked to run commands on your server? Assign the people who really need ssh access to a group, say “ssh”. (This group is already created for you in Ubuntu installs.) Then edit your OpenSSH config file /etc/ssh/sshd_config and add these lines:

AllowGroups ssh

Now only members of the ssh group will be allowed remote access. To restrict local access as well, see my post on RSSH.

2. Change the SSH port.
#

Security through obscurity. Every kiddie script is going to check port 22 first. Choose another port at a much higher number, and add a line to your sshd_config file, for example:

Port 13072

This measure will greatly reduce the number of failed login attempts in your system logs. It won’t stop the more serious attempts, which scan the higher port ranges.

3. Fail2Ban
#

Fail2Ban is an ingenious app that counts failed login attempts. After a few consecutive failures, it modifies your iptables settings to drop all packets from that IP for a specified period of time (default is 10 minutes). With fail2ban, you don’t have to fear brute force attacks as much. It would take weeks to try a few thousand combinations. Moreover, because packets are dropped, the attacker gets no feedback on what happened. For all they know, you’re running an expensive hardware router that just kicked into high gear. They might try again later; chance are they’ll move on to other sites, in search of easier prey.

Installation is as easy as:

sudo apt-get install fail2ban

Then edit /etc/fail2ban/jail.conf. Here, I’ve changed the defaults in the [ssh] section to allow 4 retries before lockout, and not monitor logins from localhost and another IP address (replace www.xxx.yyy.zzz with your workplace IP). I also changed the SSH port to match my OpenSSH config from above.

[ssh]
#ignroeip = 127.0.0.1
ignoreip = 127.0.0.1 www.xxx.yyy.zzz
#maxretry = 3
maxretry = 4
#port	= ssh
port	= 13072

4. SSH key exchange
#

The methods discussed above don’t change the fact that we’re using traditional password authentication. The user can log in from any computer, anywhere in the world. That means anyone can try to impersonate you by guessing your username and password. A popular way to restrict access to certain computers is SSH key exchange. You generate a pair of cryptographic keys, public and private, on the client, then copy the public key to the OpenSSH server.

ssh-keygen -t rsa
ssh-copy-id -i ~/.ssh/id_rsa.pub username@server.mydomain.com

You’ll be prompted for a passphrase (optional) when you run ssh-keygen. The ssh-copy-id command is a shortcut that copies and appends the key to the user’s list of authorized keys. If it doesn’t work, you can accomplish it in two steps. On the client, copy the file over:

scp ~/.ssh/id_rsa.pub username@server.mydomain.com:~/my_remote_id_rsa.pub

On the server, append the key:

cat ~/my_remote_id_rsa.pub >> ~/.ssh/authorized_keys

Now when you login with ssh username@server.mydomain.com, the host should no longer prompt you for a password. It “knows” that it’s you because two things happened invisibly during authentication, First, you sent it your public key again, and it confirmed that it matched the one in authorized_keys. Second, your computer sent an encrypted message using its private key, and the message was successfully decrypted by the server using its copy of the public key– something that could only happen if you also possessed the correct private key. An additional benefit of using keys: your password was never typed in, exposing it to theft by another computer.

So far, we’ve made login more convenient, using public key authentication in lieu of passwords. The server still accepts traditional logins from any computer. You can instruct OpenSSH to only allow access from authorized keys, by modifying /etc/sshd_config.

PasswordAuthentication no
ChallengeResponseAuthentication no

If we stop here, we probably have made our server too secure. What happens if we misconfigured OpenSSH, lose our key, or have to do an occasional login from an unauthorized computer? We’d be locked out -completely – a real problem if our server isn’t located nearby, and we can’t walk over to login locally from the keyboard. Let’s add some exceptions to the policy, for cases where we’re logged in as ourselves from our private network, or from a trusted remote computer.

Match Address 192.168.0.0/24 User paul
  PasswordAuthentication yes
Match Host my_ddns_hostname.dyndns.org User paul
  PasswordAuthentication yes
# Uncomment these lines to allow your login from any computer.
# Match User paul
# PasswordAuthentication yes

Again, unless you have physical access to your server, I recommend that you give yourself a back door. Enable PasswordAuthentication for your own user account as shown above. Or create another account with a hard-to-guess name and a strong password. Restart the server with your new configuration (/etc/init.d/ssh reload) and test.

5. One Time Passwords
#

While SSH key exchange works well, it has to be installed in advance and carried with you. There are times when it’s not available to you. You may need to access your server from someone else’s computer, say at a hotel or kiosk. You’re worried about password theft, perhaps by malware like a [key logger] ( http://en.wikipedia.org/wiki/Keystroke_logging). For these situations, an alternative to SSH key exchange is One Time Passwords, aka OPIE. This involves setting up an application on the server to pre-generate a list of passphrases. Each consists of six words and is good for a single login only. Even if some rogue application records the password, they can’t re-use it. The idea is that you’ll carry a list of passwords with you and use them, one at a time.

I haven’t tried OPIE, and it doesn’t seem to have many adopters. Perhaps it’s seen as inconvenient or unnecessary in an age where people carry computers in their pockets. However, if you’re traveling and forced to login with someone else’s device, it seems like a good choice.

Resources
#

Related

RSSH: A More Secure Way To Share Files
security ssh sysadmin
You’ve set up a server and your users are happily transferring files with apps like Filezilla or Cyberduck.
Relay Mail With Postfix and Stunnel
server apps mail sysadmin
Let’s say you’ve just installed your own virtual server running Postfix.
Installing a Local DNS Server Behind a Hardware Router
networking router dns hardware sysadmin
There’s not much work to installing and using a typical hardware router.