3

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.

BurninLeo
  • 860
  • 2
  • 11
  • 28

1 Answers1

4

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
BurninLeo
  • 860
  • 2
  • 11
  • 28