tested on slackware current (Jan 2021)
assuming you got SSHD up and running already
eventhough you might not use a password at all, it’s a prefered way to unlock the account by defining an unused password.
groupadd -g 922 scponly useradd -u 922 -g scponly -m -s /sbin/nologin SCP-USER passwd SCP-USER
fix the chroot homedir to some folder
vipw SCP-USER --> /data/www/nethence.com/smtp
containing user-editable sub-folders e.g.
chown SCP-USER:scponly /data/www/nethence.com/smtp/stats/
chroot has its own authorized keys file
mkdir /etc/ssh/authorized/ vi /etc/ssh/authorized/SCP-USER PUBLIC KEYS HERE vi /etc/ssh/sshd_config AuthorizedKeysFile /etc/ssh/authorized/%u .ssh/authorized_keys Match Group scponly ChrootDirectory %h ForceCommand internal-sftp AllowTcpForwarding no X11Forwarding no PasswordAuthentication no /etc/rc.d/rc.sshd restart
First, check that this specific authorized keys file(s) did not mess-up the whole authentication. For example, temporarily disable some public key and try login some normal user of yours. You should NOT get a shell even though your public key is defined for the chroot.
Second, try to get to the chroot within a shell instead of SCP/SCFP
ssh SSH-SERVER -l SCP-USER -p 2222 This service allows sftp connections only.
scp -oPort=2222 SOME-FILE SCP-USER@SSH-SERVER:/stats/
–or– using SFTP
sftp -oPort=2222 SCP-USER@SSH-SERVER:/stats/ ls -l rm ... put ...
fatal: bad ownership or modes for chroot directory
==> from the
ChrootDirectory wants root ownership
unused as this was not providing a chroot
sbopkg -i rssh which rssh chsh SCP-USER vi /etc/rssh.conf logfacility = LOG_USER allowscp allowsftp umask = 022