OpenSSH – sshd_config – Allow sftp-chroot AND normal ssh login with same user

sftpssh

Hopefully not a dup, but can't find an answer to this one… I found this, which on the surface seems to be the same, but is very old and the only answer in it does not answer the actual question: Set Users as chrooted for sftp, but allow user to login in SSH

I have successfully setup a working ChrootDirectory environment via sftp for users in group 'sftp_users'. It works well, all the proper perms and such, restricting access to only sftp, and they can rw in their subdirectory(s) inside the ChrootDirectory. This is great for non-privelaged users, disallowing ssh access and only allowing rw inside their subfolder(s) within the ChrootDirectory.

I would like to have slightly more privelaged users who are still able to use ssh normally, however when logging in via sftp will then have the ChrootDirectory environment. This is less of a security issue, as they are considered privelaged and obvi can surf around the file-system in ssh within their normal user permissions. Problem is, I am not seeing a way to Chroot them when they login under sftp without preventing ssh login. This is more for standardization and convienience than anything else, so when they sftp they just arrive at their Chrooted location like the sftp-only users.

I thought this would work if I left their shell as the default (not /bin/false or nologin). Unfortunately, when they are in the sftp_only group, it will not allow them to ssh in at all, only sftp. Is there a workaround for this, other than having two separate accounts– one added to 'sftp_users' and one not in that group? So far, all I can find is documentation on restricting the sftp Chroot and simultaneously disallowing ssh if they are in that group.

Example user is 'test'. 'test' is in the sftp_users group, and can therefore login via sftp and be Chrooted to his specified folder ('/sftp/test') and read or write to his home folder bind-mounted at '/sftp/test/home'. This all works. But even if his shell is still set in /etc/passwd to /bin/bash, 'test' cannot login via ssh if added to the sftp_users group. Remove membership in that group and he can do both, but then not Chrooted under sftp.

Users not in the group 'sftp_users' can still login via ssh or sftp, but are not Chrooted under sftp.

Is there a way to Match which protocol is used, and/or maybe set an additional Match for a different group? I'm only looking for the chroot when they login via sftp. The non-chroot via ssh is fine for these users.

Following is my sshd_config:

Port XXXX
#ListenAddress ::
#ListenAddress 0.0.0.0

Protocol 2

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

SyslogFacility AUTH
LogLevel INFO

LoginGraceTime 120
PermitRootLogin no
StrictModes yes

PubkeyAuthentication yes

IgnoreRhosts yes
HostbasedAuthentication no

PermitEmptyPasswords no

ChallengeResponseAuthentication no

X11Forwarding yes
X11DisplayOffset 10
PrintMotd yes
PrintLastLog yes

ClientAliveCountMax 10
ClientAliveInterval 3600
TCPKeepAlive no

#Banner /etc/issue.net

AcceptEnv LANG LC_*

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

UsePAM yes
PasswordAuthentication yes



Match Group sftp_users
  ChrootDirectory /sftp/%u
  ForceCommand internal-sftp -u 0027
  X11Forwarding no
  AllowTcpForwarding no
  PasswordAuthentication yes

Best Answer

OpenSSH does not support overriding global keywords based on the submitted command. You have to differentiate on some (combination of) criteria OpenSSH offers for the Match statement.

The available criteria are User, Group, Host, LocalAddress, LocalPort, RDomain, and Address (with RDomain representing the rdomain(4) on which the connection was received)

-- man 5 sshd_config

A common choice is offering intentionally restricted services on alternate IPs reached through alternate domains, such as snapshot.backup.example and sftp.backup.example.

The comments on the linked question spell out the problem clearly, though.

If you think you want sftp access chrooted for privileged users, you are likely mangling different roles into identical users, and that is inviting security risks. Most often auditing and privilege separation concerns are better served by using a different user for whatever made you consider setting up chroot settings even for users who are not limited by that. If there are two different tasks, even if executed by the same person, and one is more safely done if intentionally restricted, then by all means setup a new system user (e.g. have user person and person-task share most restrictions and authentication methods, and only restrict one of them in ssh).

Related Topic