Для доступа по SFTP к моему серверу я создал пользователя sftp, который ограничен рабочим каталогом chroot
].
Match User sftp-user
AuthorizedKeysFile /home/sftp-user/.ssh/authorized_keys
ChrootDirectory /var/www/domain
ForceCommand internal-sftp
AllowTcpForwarding no
X11Forwarding no
И эта запись в / etc / passwd
sftp-user:x:1003:1003::/html:/usr/sbin/nologin
Были некоторые проблемы с файлом ключей, но установка абсолютного пути для этого решила проблему. Вход по SFTP работал нормально до тех пор, пока - я точно не знаю - мониторинг сервера nagios не был установлен на сервере (VPS) и / или были запущены обновления, а система была перезагружена.
Теперь соединение не работает и syslog
показывает следующую ошибку:
systemd[7590]: gpgconf: running /usr/bin/gpg-agent failed (exitcode=2): General error
systemd[7590]: gpgconf: fatal error (exit status 1)
Эта ошибка возникает независимо от того, был ли выполнен вход через файл ключей или пароль. Поэтому я попытался ответить на вопрос gpg-agent говорит, что агент существует, но gpg говорит, что агент не существует? , чтобы сузить проблему.
$ gpg-agent --version
gpg-agent (GnuPG) 2.2.4
libgcrypt 1.8.1
Когда я запустил gpg-agent
как пользователь (не пользователь sftp), он создает файл в домашнем каталоге при первом запуске:
$ gpg -d demo-file.asc
gpg: keybox '/home/username/.gnupg/pubring.kbx' created
Когда я отключаю chroot
в / etc / ssh / sshd_config
, логин работает правильно. Поэтому я предполагаю, что какой-то доступ в сеансе chroot не работает. Поскольку пользователю sftp не разрешено использовать оболочку, я не привязывал
какие-либо каталоги к домашнему каталогу пользователя sftp.
На самом деле не удалось создать каталог .gnupg
. Домашний каталог, указанный в / etc / passwd
( / html
), является относительным во время сеанса SFTP, но воспринимается как абсолютный путь во время входа в систему. Следовательно ...
.gnupg
в chroot + home = / var / www / domain / html
не (!) Помогло. /html/.gnupg
( .gnupg
принадлежит sftp-user) удалил сообщение об ошибке из / syslog
. Чтобы решить дальнейшие проблемы ( конечно, это сработало не сразу), я запустил другой демон sshd
в подробном режиме и подключился к этому порту .... но здесь это не по теме.
sudo /usr/sbin/sshd -d -p 3321