Safer SSH…

Assuming you’re using a Debian or Ubuntu based Linux.

While the SSH daemon is secure enough for most people, some may wish to further enhance their security by changing certain sshd settings. As there are tools out there (such as the ones found in Backtrack and ArchPwn Linux) that can attempt to guess your password, either doing damage by succeeding or starting a DoS attack (bombard your server so much that it stops doing its job as it becomes overwhelmed) All changes, unless otherwise stated, are made in the /etc/ssh/sshd_config file. Lines with a pound sign (#) are commented and not read.

To edit this file from a terminal:

sudo nano /etc/ssh/sshd_config

Please remember, after making any changes, sshd must be restarted, which can be done from the terminal with this command:

sudo /etc/init.d/ssh restart

SSH Root Login

By default, the SSH daemon ships with remote root logins enabled. Normally Ubuntu does not allow direct access to the root user, so this setting is unimportant. If you have set a password on the root account, this setting can be a potential security risk, and should be disabled. To disable root login, edit the /etc/ssh/sshd_config file and replace the following line:

PermitRootLogin yes

with this line:

PermitRootLogin no

Sometimes it is necessary to allow root logins when doing automated tasks such as backups. To disallow normal logins but allow forced commands, you can use:

PermitRootLogin forced-commands-only

See man (5) sshd_config for details.

SSH Login Grace Time

The login grace time is a period of time where a user may be connected and not begin the authentication process. By default, sshd will allow a connected user to wait for 120 seconds (2 minutes) before starting to authenticate. This could be used to conduct a Denial of Service (DoS) or a brute force attack against a running SSH daemon. One solution is lowering this to 20 seconds. This should be used in combination with iptables rules to reduce the number of SSH connection attempts, otherwise a DoS can be launched well within the login timeout. To change this, replace this line:

LoginGraceTime 120

with this line:

LoginGraceTime 20

SSH Welcome Banner

The SSH daemon will allow a message to be displayed to users attempting to log in to the SSH server. To enable login messages, remove the pound sign from this line:

#Banner /etc/issue.net

so it looks like this:

Banner /etc/issue.net

Now, edit /etc/issue.net and place a warning to unauthorized users. The following is taken from the Advanced OpenSSH page and is modified from a U.S. Department of Defense warning banner.

***************************************************************************
                            NOTICE TO USERS

This computer system is the private property of its owner, whether
individual, corporate or government.  It is for authorized use only.
Users (authorized or unauthorized) have no explicit or implicit
expectation of privacy.

Any or all uses of this system and all files on this system may be
intercepted, monitored, recorded, copied, audited, inspected, and
disclosed to your employer, to authorized site, government, and law
enforcement personnel, as well as authorized officials of government
agencies, both domestic and foreign.

By using this system, the user consents to such interception, monitoring,
recording, copying, auditing, inspection, and disclosure at the
discretion of such personnel or officials.  Unauthorized or improper use
of this system may result in civil and criminal penalties and
administrative or disciplinary action, as appropriate. By continuing to
use this system you indicate your awareness of and consent to these terms
and conditions of use. LOG OFF IMMEDIATELY if you do not agree to the
conditions stated in this warning.

****************************************************************************

Once this is in place, restart sshd and all users will see this warning before they get the login prompt. This will obviously not dissuade automated SSH attacks, and will potentially worsen DoS effects, but it may tip off a human attacker that the system is being looked after closely, and that they should move on to some other system on the network.

SSH Allowed Users

By default, SSH will permit every user with an account to attempt to log in. PAM (the authentication system under SSH) already does not allow attackers to guess user accounts. However, if you have a set of users you want to never allow SSH access to, you can use the AllowUsersdirective. To do this, add a line like this in your sshd configuration file:

AllowUsers jsmith tallen

Or to limit access to a specific user from a specific ip address, use something like:

AllowUsers jsmith@192.168.0.2 tallen

The AllowUsers directive is the list of all users that are allowed to log in through SSH. If you have a large number of users, or you intend to have a changing list of users, you can also use the AllowGroups directive and create a group specifically for users allowed to log in through SSH. You can add a group for this purpose with this command:

sudo addgroup sshlogin

Using the example name of ‘sshlogin’, you would then add this line to your sshd configuration file:

AllowGroups sshlogin

After you restart sshd, only users in the AllowUsers list (or users who are members of the ‘sshlogin’ group if you chose that method instead) will be allowed to log in through SSH. See man (5) sshd_config for details.

Disable Password Authentication

One may also tighten security by forcing public key authentication and disabling password authentication entirely. While this greatly enhances security and completely defeats brute-force attacks, it will lock you out of the machine if you lose your private key. Use with caution.

On the client, generate a key pair with a strong passphrase using:

$ ssh-keygen -t rsa -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/<username>/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/<username>/.ssh/id_rsa.
Your public key has been saved in /home/<username>/.ssh/id_rsa.pub.
The key fingerprint is:
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx <username>@<client-hostname>

Next, copy the above key to the machine you’d like to login to (this puts the key in /home/<username>/.ssh/authorized_keys on the server):

$ ssh-copy-id -i /home//.ssh/id_rsa.pub @

Verify you can login to the server with your new key:

$ ssh <username>@<server-hostname>
Enter passphrase for key '/home//.ssh/id_rsa':
<username>@<server-hostname>:~$

Once you have verified you can login to the server with your new key pair, update /etc/ssh/sshd_config on the server to have:

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes
PasswordAuthentication no

See man (5) sshd_config and man (1) ssh-keygen for more details.

Use SFTP instead of FTP

Suppose you want to give some users the ability to upload and download files from their home directories (or ~/public_html), but not a full shell account. In Ubuntu 8.10 (Intrepid) and later, this is simple to achieve with OpenSSH’s SFTP component.

In /etc/ssh/sshd_config, change

Subsystem sftp /usr/lib/openssh/sftp-server

to

Subsystem sftp internal-sftp

Add a stanza like the following to the *bottom* of the same file. It must be at the bottom, because Match groups are only terminated by the end of the file (or another Match stanza).

Match User alice
  ChrootDirectory %h/public_html
  X11Forwarding no
  AllowAgentForwarding no
  AllowTcpForwarding no
  ForceCommand internal-sftp

Now alice can use SFTP to read from and write to her ~/public_html/ directory, but can’t use OpenSSH to get a shell, nor even to read files outside of ~/public_html.

If you have many such users, you can change User alice to `Groupsftponly, and add users to the sftponly group using usermod(8)`.

Chrooting SFTP was considerably more tedious in Ubuntu 8.04 (Hardy) and earlier, where ChrootDirectory was not available. For FTP on such systems, consider vsftpd: it is more security-conscious than other FTP implementations.

SSH Security Software

You should be running a firewall on your server. IPTables comes with most Linux distos and you can use the UFW (Uncomplicated FireWall) program to easily manage it from terminal. Once you have the firewall up and running (post soon to come) you can install sshguard, a Linux daemon that watches the SSH logs and temperately bans IP addresses that repeatedly guess incorrect passwords. A must if you ask me!

Change the Port

You may also want to consider changing the incoming port on your router, if your router supports this. (e.g. “ssh john@EXTERNAL-IP -p 1337” would send you to LOCAL-IP:22) or you can change the default SSH port from 22 to something else altogether in the /etc/ssh/sshd_config and restarting the SSH server, remembering to update the port number on your firewalls (if you used UFW and specified the port by service name or protocol name as opposed to the actual port number you may not need to update it.) and on your router.

Safer SSH…

3 thoughts on “Safer SSH…

Leave a Reply

Your email address will not be published. Required fields are marked *