For SFTP access to my server, I have created a sftp user that is limited to a working directory by chroot
.
Match User sftp-user
AuthorizedKeysFile /home/sftp-user/.ssh/authorized_keys
ChrootDirectory /var/www/domain
ForceCommand internal-sftp
AllowTcpForwarding no
X11Forwarding no
And this entry in /etc/passwd
sftp-user:x:1003:1003::/html:/usr/sbin/nologin
There were some issues with the key file, but setting an absolute path for that solved the issue. The SFTP login worked fine until - I do not exactly know - the nagios server monitoring was installed on the server (a VPS) and/or updates have been run, and the system has been rebooted.
Now, connection fails and the syslog
shows this error:
systemd[7590]: gpgconf: running /usr/bin/gpg-agent failed (exitcode=2): General error
systemd[7590]: gpgconf: fatal error (exit status 1)
This error occurs no matter if the login is done via key file or password. So I have tried following the question gpg-agent says agent exists, but gpg says agent doesn't exist? to narrow down the problem.
$ gpg-agent --version
gpg-agent (GnuPG) 2.2.4
libgcrypt 1.8.1
When I started gpg-agent
as user (not the sftp user), it creates a file in the home directory on the first run:
$ gpg -d demo-file.asc
gpg: keybox '/home/username/.gnupg/pubring.kbx' created
When I disable the chroot
in /etc/ssh/sshd_config
, the login works properly. So I assume, that some access fails in the chroot session. As the sftp user is not allowed to use a shell, I did not bind
any directories into the sftp-user's home directory.
It actually was the
.gnupg
directory that could not be created. The home directory specified in/etc/passwd
(/html
) is relative during the SFTP session, but understood as absolute path during the login. Therefore....gnupg
in chroot+home =/var/www/domain/html
did not (!) help./html/.gnupg
(.gnupg
owned by sftp-user) removed the error message from/syslog
.To take care of further problems (of course, it did not work immediately), I started another
sshd
daemon in verbose mode and connected to this port .... but that would lead off topic here.