3

I am trying to set up my Openssh server to allow for chrooted sftp-only users as well as for non-chrooted sftp and ssh users. My condensed (comments and blank lines removed) /etc/ssh/sshd_config looks like this:

Port 22
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 768
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
AcceptEnv LANG LC_*
#Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem sftp intenal-sftp
UsePAM yes
Match Group sftpusers
        ChrootDirectory /var/sftp/%u
        ForceCommand internal-sftp

What I have achieved by this:

  • Users in the sftupsers group can sftp their files into their directories, but can't log in. Check.
  • Users, who are not in sftpusers can login via ssh. Check.
  • Users, who are not in sfttpusers can not sftp files. Oops.

If I change the Subsystem sftp-line to the commented out version, the "privileged" users can sftp and ssh, but the chrooted users can no longer sftp.

With the above config-file I get the error message Connection closed by server with exitcode 127 from FileZilla and Fatal: Received unexpected end-of-file from SFTP server from psftp.

Any idea how to fix this?

Improve this question

2 Answers 2

Reset to default
2 
Subsystem sftp intenal-sftp

Should be "internal".

Improve this answer
2
  • Ouch! Yes indeed it should. It does now and everything works as expected. It's a bit of a mystery that the chrooted sftp worked at all with the typo.
    – fpet
    Apr 24, 2015 at 15:11
  • Thinking about it, it's no mystery: Due to the ForceCommand internal-sftp for the users in the sftpusers group, sshd didn't have to look at the Subsystem sftp entry. It had to use internal-sftp.
    – fpet
    Apr 24, 2015 at 15:20
0

You do NOT have to ALWAYS put Subsystem sftp internal-sftp. That's big misunderstanding!

What does Subsystem define? Let's check sshd_config(5):

 Subsystem
         Configures an external subsystem (e.g. file transfer daemon).
         Arguments should be a subsystem name and a command (with optional
         arguments) to execute upon subsystem request.

         The command sftp-server implements the SFTP file transfer
         subsystem.

         Alternately the name internal-sftp implements an in-process SFTP
         server.  This may simplify configurations using ChrootDirectory
         to force a different filesystem root on clients.

         By default no subsystems are defined.

Changing sftp subsystem to internal-sftp is ONLY required if you do NOT want to setup all files in the chroot (ie. ChrootDirectory).

An example - if you want to have your own wrapper which would do anything special and "force" users to sftp, you CANNOT have Subsystem sftp internal-sftp because you cannot call/exec internal-sftp as command, its internal OpenSSH magic. For real case scenario - you want to automatically mirror all uploaded files via SFTP with rsync in the end of SFTP session - thus you cannot use internal-sftp but you should use defaults for sftp subsystem, populate chroot manually and just call /usr/libexec/sftp-server (or any other path) and rsync after end of sftp-server run.

People should read manpages to understand what's going on in the background and not just follow blidly any recommendation.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.