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:

#ListenAddress ::

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

2 Answers 2


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

  • To clarify, if I set sshd up to listen on two ports, say 22 and 2222, I could have a Match sections set for port 2222 that could be specific for the Chrooted sftp? I only have one IP, so this currently appears to be my only option with same username.
    – jdmayfield
    Apr 21, 2022 at 23:57
  • You should have ample IPs available, even if you are currently only using one. If it says /56 in your list of ip assigned address, I believe that would be spelled quadrillion in English.
    – anx
    Apr 22, 2022 at 0:05
  • 1
    Whether you chose IPs or Ports, take care that you do not accidentally lift restrictions by then applying your restrictions to only one port and/or address. You may find your configuration to become more rebust if you create separate groups for "is allowed here" and "is allowed there".
    – anx
    Apr 22, 2022 at 0:08
  • I have one local Public IP allocated to my cloud server. It may be possible to acquire an addition Pub.IP, however it would likely be expensive, if allowed. This use-case does not (in-general) have regard for remote IP's; it needs to not rely on the client's address.
    – jdmayfield
    Apr 23, 2022 at 1:37
  • I did some experimentation with various combinations of Match-ing ports and user groups. This seems to work conveniently and securely. Tested thoroughly. 'sftp_users' group can only log in on one port, only via sftp, and are chrooted. Users not in that group can ssh or sftp to one port (say port A), no chroot, or they can sftp to the other to get the chroot (say port B). 'sftp_users' group have only one choice and get chrooted (only port B). All of this seems to be working as planned, except I was hoping I could match domain names with same IP. Thank you for clarifying.
    – jdmayfield
    Apr 23, 2022 at 1:40

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 .

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .