Join Log in
Score:0
jdmayfield avatar Server

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

cn flag
jdmayfield

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
71
0 + 0
ssh
Score:1
anx avatar Server
fr flag
anx

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

0 + 0
jdmayfield avatar
cn flag
jdmayfield
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.
0
Reply
anx avatar
fr flag
anx
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.
0
Reply
anx avatar
fr flag
anx
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".
1
Reply
jdmayfield avatar
cn flag
jdmayfield
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.
0
Reply
jdmayfield avatar
cn flag
jdmayfield
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.
0
Reply
jdmayfield avatar
cn flag
jdmayfield
Comments on the linked question did not address my use case, nor provide an answer on how to accomplish this task. Clearly the users in 'sftp_users' group are to be locked down to only the sftp chroot, no ssh. Users not in that group are assumed to be privilaged and allowed ssh, normal sftp (without chroot), and chroot for convenience, not additional security. Otherwise I wouldn't be asking the question, as there are a plethora of very simple examples on chrooting a single group. There are a number of use-cases for this.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.