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.
Install software (optional but useful):
yum install members # or apt install members
addgroup --system allowssh
addgroup --system sftponly
/etc/ssh/sshd_config, ensure that the following to settings are
And at the end of
/etc/ssh/sshd_config, add these two stanzas:
Match Group allowssh
Match Group sftponly
(don't forget to restart SSH after editing the file)
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
- 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
# 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).
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.
/sbin/nologin may be helpful to stop them logging in via other ways (physical console, samba, etc) though.
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. Consider setting it to
prohibit-password, and (as a last resort)
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