Group-based secure-by-default SSH setup
I like the following setup for managing SSH access, which I've used to manage a group of users on small fleets of servers. Security and ease of management is high on the list of my priorities.
Its key features are easily managing SSH rights through Unix group membership, having tightly defined permissions, and being secure by default.
Setting up
Install software (optional but useful):
yum install members # or apt install members
Add groups:
addgroup --system allowssh
addgroup --system sftponly
Add a new file /etc/ssh/sshd_config.d/strict.conf
(you can replace strict
with a better name), with the following contents:
PermitRootLogin no
PubkeyAuthentication no
PasswordAuthentication no
Match Group allowssh
PubkeyAuthentication yes
Match Group sftponly
ChrootDirectory %h
DisableForwarding yes
ForceCommand internal-sftp
This assumes that your OpenSSH setup includes sshd_config.d/*.conf
to override the main config. Check your SSH documentation, or verify that the main sshd_config
has an appropriate Include
directive. If your setup does not support this, you could edit sshd_config
directly instead.
Also, don't forget to restart the SSH service after modifying the configuration.
Rationale
So, what does all this do?
- It always disables root logins, as an extra security measure.
- It always disables password-based logins (weak passwords are a big risk for servers running sshd).
- It only allows (pubkey) login for users in the
allowssh
group.
- Users in the
sftponly
group cannot get a shell over SSH, only SFTP.
Managing who has access is then simply done by managing group membership (group membership changes take effect immediately, no SSH restart required; but note that existing sessions are not affected). members allowssh
will show all users that are allowed to log in over SSH, and members sftponly
will show all users that are limited to SFTP.
# adduser marcelm allowssh
# members allowssh
marcelm
# deluser marcelm allowssh
# members allowssh
#
Note that your sftp users need to be members of both sftponly
(to ensure they won't get a shell), and of allowssh
(to allow login in the first place).
Further information
Please note that this configuration does not allow password logins; all accounts need to use public key authentication. This is probably the single biggest security win you can get with SSH, so I argue it's worth the effort even if you have to start now.
If you really don't want this, then also add PasswordAuthentication yes
to the Match Group allowssh
stanza. This will allow both pubkey and password auth for allowssh
users. Alternatively, you can add another group (and Match Group
stanza) to selectively grant users password-based logins.
This configuration limits any sftponly
user to their home directory. If you do not want that, remove the ChrootDirectory %h
directive.
If you do want the chrooting to work, it's important that the user's home directory (and any directory above it) is owned by root:root
and not writable by group/other. It's OK for subdirectories of the home directory to be user-owned and/or writable.
Yes, the user's home directory must be root-owned and unwritable to the user. Sadly, there are good reasons for this limitation. Depending on your situation, ChrootDirectory /home
might be a good alternative.
Setting the shell of the sftponly
users to /sbin/nologin
is neither necessary nor harmful for this solution, because SSH's ForceCommand internal-sftp
overrides the user's shell.
Using /sbin/nologin
may be helpful to stop them logging in via other ways (physical console, samba, etc) though, so it's still recommended.
This setup does not allow direct root
logins over SSH; this forms an extra layer of security. If you really do need direct root logins, change the PermitRootLogin
directive to forced-commands-only
, to allow only key-based forced commands through /root/.ssh/authorized_keys
. As a last resort, you can use prohibit-password
to allow full key-based logins. Avoid yes
.
For bonus points, have a look at restricting who can su
to root; add a system group called wheel
, and add/enable auth required pam_wheel.so
in /etc/pam.d/su
.