I added a note to the bottom about ownership/permissions issues sshd can give you when you're setting it to chroot. I followed this guide and ran into a problem where no matter what I seemed to do sshd would keep rejecting sftp connections. Turns out it won't allow you to chroot to directories that don't have what it considers secure permissions.
This is my first edit on this wiki btw. MaBeef 05:31, 18 December 2009 (EST)
- This is also my first blurb. I was also having problems logging in to sftp/chroot with an ssh key. Using OpenSSH_5.3p1 I tried a few things and finally got a configuration to work. In
sshd_config, I set:
AuthorizedKeysFile /etc/ssh/authorized_keys/%u Subsystem sftp internal-sftp Match Group ftponly ChrootDirectory /home/%u ForceCommand internal-sftp PubkeyAuthentication yes AllowTCPForwarding no X11Forwarding no
- Then for the IDs I wanted to give ssh key trust to, in this example
fbestert, created the directory specified in the
sshd_config. It said
ChrootDirectory /home/%uso put it in
/home/fbestert. This directory looks like:
drwxr-x---. 5 root ftponly 4096 Jan 21 17:09 fbestert
- THIS IS NOT fbestert's HOME DIRECTORY IN
/etc/password! The passwd file entry looks like this:
400is the GID for
ftponly, the group specified in sshd_config's
Match Groupvalue. This "home" directory looks like this:
"drwx------ 3 fbestert ftponly 4096 Jan 21 17:05 /etc/ssh/authorized_keys/fbestert"
- and it has the normal .ssh subdirectory underneath it with the
authorized_keysfile which contains the ssh public keys, as usual. —This unsigned comment is by Fbester (talk) 22:08, 22 January 2015. Please sign your posts with ~~~~!
Logging from chroot to journald
# mkdir /jail/dev # touch /jail/dev/log # mount --bind /run/systemd/journal/dev-log /jail/dev/log
# logger TEST --socket /jail/dev/log
"UsePam yes" and "/usr/bin/nologin" shell
I just tried to set up sftp access to my machine and I faced with the problem.
Default sshd_config has "UsePam yes" and default /etc/shells doesn't have "/usr/bin/nologin" entry. Consequently password authentication doesn't work for such users who have /usr/bin/nologin shell.
I believe it would be appropriate to mention that fact and suggest to either disable UsePAM or add /usr/bin/nologin to the /etc/shells.
And maybe it would be a good idea to add /usr/bin/nologin to the /etc/shells by default, but I don't know where is appropriate place to raise that question.