![]() If you really do need direct root logins, change the PermitRootLogin directive. This setup does not allow direct root logins over SSH this forms an extra layer of security. Using /sbin/nologin may be helpful to stop them logging in via other ways (physical console, samba, etc) though. 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. Depending on your situation, ChrootDirectory /home might be a good alternative. Sadly, there are good reasons for this limitation. Yes, the user's home directory must be root-owned and unwritable to the user. It's OK for subdirectories of the home directory to be user-owned and/or writable. ![]() 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. If you do not want that, remove the ChrootDirectory %h directive. This configuration limits any sftponly user to their home directory. Alternatively, you can add another group (and Match Group stanza) to selectively grant users password-based logins. This will allow both pubkey and password auth for allowssh users. If you really don't want this, then also add PasswordAuthentication yes to the Match Group allowssh stanza. 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. Please note that this configuration does not allow password logins all accounts need to use public key authentication. 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). 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. 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). Users in the sftponly group cannot get a shell over SSH, only SFTP.It only allows (pubkey) login for users in the allowssh group.It always disables password-based logins (weak passwords are a big risk for servers running sshd).It always disables root logins, as an extra security measure.(don't forget to restart SSH after editing the file) Explanation In /etc/ssh/sshd_config, ensure that the following to settings are No: PermitRootLogin noĪnd at the end of /etc/ssh/sshd_config, add these two stanzas: Match Group allowssh Install software (optional but useful): yum install members # or apt install members ![]() Its key features are easily managing SSH rights through Unix group membership, having tightly defined permissions, and being secure by default. Security and ease of management is high on the list of my priorities. I like the following setup for managing SSH access, which I've used to manage a group of users on small fleets of servers.
0 Comments
Leave a Reply. |