How-to – Protect sshd

0
1322

Below some methods for increase ssh protection

1) Configure public/provate keys
2) Disable Password Authentication
3) Disable root login
4) Restricting Users/Groups/Hosts
5) Restricting Access and Commands

Disabling Password Authentication

Once key-based logins are working, disable password authentication. Find your SSH server’s configuration file. This is usually in /etc/ssh/sshd_config. Find the line that says:

PasswordAuthentication yes

and change it to

PasswordAuthentication no

You should also disable challenge-response authentication, in case your version of OpenSSH is using PAM to authenticate (see below for an explanation):

ChallengeResponseAuthentication no

Disabling Root-Logins

Finally, disable root logins. Kudos go to NetBSD and FreeBSD, whose default configurations do not allow root logins, so there will be nothing to do for you to do in this step if you are using a recent version of either one. OpenBSD and most Linux distributions allow root logins by default. Again in /etc/ssh/sshd_config, find the line that reads

PermitRootLogin yes

and change it to

PermitRootLogin no

Reload your SSH server’s configuration with /etc/init.d/ssh reload (Debian Linux-based), service sshd reload (Red Hat Linux-based), /etc/rc.d/sshd reload (NetBSD/FreeBSD) or just send sshd a HUP signal, usually with something like kill -HUP pid, where pid is the process ID of the SSH server, you can get it quickly on any Unix platform by running something like ps ax | grep sshd.

Restricting Users and Hosts

OpenSSH allows you to restrict users and groups by host or IP address. There are four different directives you can use in your sshd_config file (they are evaluated in this order):

DenyUsers
AllowUsers
DenyGroups
AllowGroups

The format for all of them will be the same – a space-separated list of users or group names, with optional host names. Here is an example:

AllowUsers [email protected] [email protected] sidious [email protected]*.evillitleman.net AllowGroups wheel staff

This tells sshd to only allow connections from the user vader and only from the IP address 10.0.0.1. The user maul is also allowed, but only from the host sproing.evillittleman.net. User sidious is allowed from anywhere, and the user tyranus is also allowed, from any host in the evillittleman.net domain (the asterisk matches zero or more characters).

The AllowGroups line allows login only from users whose primary group name or supplementary group list match one of ‘wheel’ or ‘staff’.

Keep in mind that using AllowUsers or AllowGroups means that anyone not matching one of the supplied patterns will be denied access by default. Also, in order for sshd to allow access based on full or partial hostnames, it needs to do a DNS lookup on the incoming IP address. That means the connecting IP address must have a PTR (reverse) entry that maps back to a real hostname. These aren’t hard to get if you have a static IP address, usually your ISP or server hosting provider can do this for you on request.

In addition to the asterisk in hostname or group patterns, you can use a question-mark to mean exactly one character, and an exclamation point to negate the sense of a match:

* – Matches zero or more characters
? – Matches exactly one character
! – Negates the host pattern match

Note: In my tests, using ! to negate the sense of the hostname match did not work with the AllowUsers directive. It only seems to work when used with authorized_keys file restrictions (see below).

Restricting Access and Commands

SSH has the concept of authorized keys. The user accounts on the SSH server will have an authorized_keys file (which is by default in the ~/.ssh directory of whatever user account you are logging into). This file lists the public keys, one per line, that are authorized for access to that account. Apart from just specifying which public keys are allowed access, there are a some more options that you can use to further restrict SSH sessions. Here are the most useful ones:

from=’hostname1,hostname2,” – Restricts access from the specified IP or hostname patterns
command=’command’ – Runs the specified command after authentication
no-pty – Does not allocate a pty (does not allow interactive login)
no-port-forwarding – Does not allow port forwarding

Here is an example showing part of an authorized_keys file:

from="deathstar.example.com,!jedi.example.com,10.0.0.?" ssh-rsa AAAAB5...2BQ== [email protected] from="pitofdespair.example.com",command="ls",no-pty,no-port-forwarding ssh-dss AAAAZ7...22Q== [email protected]

The first line allows login with the specified RSA key from deathstar.example.com, from any host with IP address in 10.0.0.[0-9], but not from the host jedi.example.com. The second line merely runs the ‘ls’ command whenever the specified DSA key is used – it does not allow any other commands to be run, does not allow interactive login, and does not allow port-forwarding. It also restricts the source of that key to the host pitofdespair.example.com.

 

This article references Five Minutes to an Even More Secure SSH, with some changes.