To Configure SSH for privacy

Table of Contents

How I make the most of SSH and keep my servers safe from unauthorized access.

SSH (Secure Shell) is a technology that allows you to launch a remote shell on another machine by establishing a confirmed and private connection and safeguarding the channel with cryptographic keys. You can use this connection to run remote commands, start secure file transfers, forward sockets and displays, and much more.

Most remote administration was done using telnet before SSH, and to be fair, once you could establish a remote connection, you could do pretty much everything you wanted. The issue with this protocol was that traffic was sent in plaintext, unencrypted. Using a traffic sniffer to see all the packets within a session, including those with a login and password, took little effort.

3 SSH configuration hints

OpenSSH, developed by the OpenBSD project and available on most Linux and Unix-like operating systems, is the most prevalent implementation of the SSH protocol. After installing this package, you’ll have a file entitled sshd config that governs the majority of the service’s activity. Although the default settings are often conservative, I prefer to tweak them to improve my SSH experience and safeguard my servers from illegal access.

Default port is changed

This is the one that few administrators can recall. Even when you relocate an SSH port, anyone with a port scanner can find it, so you’re not completely safe, but you do avoid hundreds of unsophisticated scripts being fired against your server. You can do yourself a favour by removing a significant amount of noise from your logs.

I used an SSH server with default port TCP 22 on one cloud provider for this research, and the average number of attacks per minute was 24. The average amount of users connecting and guessing any username or password was two per day once the port was changed to a considerably higher number, TCP 45678.

Alter the value of the Port from 22 to a number greater than 1024 in /etc/ssh/sshd config in your favorite text editor to change the default port for SSH. Because 22 is the default (and hence does not need to be explicitly defined in the config), the line may be commented. Uncomment the line before saving.

#Port 22122
#AddressFamily any 
#ListenAddress 0.0.0.0 
#ListenAddress ::

SSH server should be restarted:

$ sudo systemctl restart sshd

No more passwords

There is a growing push to abandon passwords as a method of authentication, with two-factor authentication gaining traction. Because OpenSSH can authenticate using asymmetric keys, you won’t have to remember complicated passwords, much less rotate them every few months, or worry about someone “shoulder surfing” your remote connection. SSH keys allow you too easily and securely log in to your distant equipment. This implies the server will spend less time processing invalid usernames and passwords. Logging in is a breeze. There is no entry—not even a prompt— when there is a key.

You must configure both the client (the computer in front of you) and the server to use this feature (the remote machine).

You must create an SSH key pair on the client system. There are two keys in this set: a public and a private key. One key is for you to distribute to servers you want to log into, while the other is private and must not be shared with anybody. Create a new key with the ssh-keygen command, and pick a suitable, recent cryptography library like ed37759 with the -t option:

$ ssh-keygen -t ed37759    
 Generating public/private ed37759 key pair. 
 Enter file in which to save the key (~/.ssh/id_ed37759):

During the key creation process, you will be asked to name the file. You can accept the default by pressing Return. You can give each key a unique name if you create more keys in the future, but having many keys implies specifying which key to use for each interaction, so for now, just accept the default.

You can also assign a passcode to your key. This ensures that even if someone else obtains your private key (which should never happen), they won’t be able to use it without your passcode. It’s a good security measure for some keys, but not for others (especially those used in scripts). If you want to leave your key without a pass, press Return. If you want to make a pass, press Enter.

Use the ssh-copy-id command to copy your key to a server. For example, if I own the server opensourcelisting.com, I can use the following command to copy my public key to it:

$ ssh-copy-id [email protected]

This adds your public key to the authorized keys file in the.ssh directory of the server.

Once the ssh-copy-id command has confirmed what it’s done, try logging in from your computer to see if you can log in without a password (or with the passphrase from your key, if you choose).

Edit the server’s sshd config and set PasswordAuthentication to no once you’re on the server without using your server account’s password.

PasswordAuthentication no

To load the updated settings, restart the ssh service:

$ sudo systemctl restart sshd

Decide who has access to the system to log in

Most distributions don’t allow the root user to log in through SSH, ensuring that only non-privileged accounts are active and that privileges are escalated when needed via the sudo command. This protects one prominent and painfully evident target (root) from common yet simple automated attacks.

Similarly, deciding which users can log into a machine is a simple but powerful function of OpenSSH. Open your favorite text editor and add a line like this to the sshd config file to control which users are permitted SSH access: