1

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.

1

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

  • Creating a folder .gnupg in chroot+home = /var/www/domain/html did not (!) help.
  • Creating a folder /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.

sudo /usr/sbin/sshd -d -p 3321

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.