Home / server / Questions / 1099081
Accepted
jdmayfield
Asked: 2022-04-21 17:38:10 +0800 CST

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

  • 772

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
ssh sftp

1 Answers

  1. 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).

    • 1

  2. I was also confused by this problem, when I setup chroot sftp for users they cannot login by ssh. My scenario is slight different, I need to provide a limited shell environment for users, whilst users still need sftp & scp to access their home directory for RW, as well as a designated public directory, e.g. /home/public for RDONLY.

    Firstly I developed a jailed shell, I wished this shell can cooperate with openssh internal-sftp to achieve my requirement. Then I found it failed because openssh will not allow users ssh login together with the chroot internal-sftp being enabled.

    So I had to modified the jailed shell to support the home jailed sftp and scp. It's a little bit tricky that I used ptrace syscalls to implement the jailed sftp. If this information is useful to you, you can refer to https://github.com/diggerwoo/jsh .

    • 0