Проблемы с работой двунаправленного SSH между Ubuntu 14 и Ubuntu 18
Старая (и устаревшая) установка Ubuntu 16, используемая для подключения к еще более старому и более устаревшему облачному серверу через ssh без пароля и наоборот. Это необходимо для сценариев автоматизации для синхронизации папок с удаленного сервера в облако.
Облачный сервер не используется, поэтому мы настраиваем новый облачный сервер, переходя с Ubuntu 14 на Ubuntu 18. Мы начали с новой установки 18.04.3 и просто скопировали наши данные.
Версии ssh:
Ubuntu Server 16.04.4 LTS OpenSSH_7.2p2 Ubuntu-4ubuntu2.4, OpenSSL 1.0.2g 1 марта 2016 г. и Ubuntu Server 18.04.3 LTS OpenSSH_7.6p1 Ubuntu-4ubuntu0 .3, OpenSSL 1.0.2n 7 дек. 2017 г.
Я не могу получить учетную запись на старой удаленной машине для входа на новую облачную машину как другой пользователь без запроса пароля. Но работает противоположное.
Я использовал ssh-copy-id для обновления пользователя в файле author_keys облачного сервера. Странно то, что он всегда обновляется, хотя в файле уже есть ключ. Если я снова и снова запускаю команду copy-id, она продолжает добавлять ключ к авторизованному ключу. Интересно, связано ли это с тем, что домашние каталоги не находятся в /home.
Я попытался установить разрешения для каталога .ssh облачного сервера равным 700, а для файла author_keys - 600. Я создал файл authorized_keys2, который соответствует author_keys.
Когда пользователь удаленной системы пытается выполнить ssh для пользователя облачного сервера, он все равно запрашивает пароль.
У кого-нибудь есть идеи?
Большое спасибо.
Обновление ssh -v имеет это в конце ...
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/USER/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/USER/.ssh/id_dsa
debug1: Trying private key: /home/USER/.ssh/id_ecdsa
debug1: Trying private key: /home/USER/.ssh/id_ed25519
debug1: Next authentication method: password
1 ответ
Я нашел проблему. Это было связано с корневыми каталогами, как я думал.
Проблема: пользовательская группа корневого каталога должна совпасть с владельцем. Я изменил его, чтобы включить пользователям к rsync к каталогам друг друга. Это нет не для sshd openssh.
Вот сообщение об ошибке, я вошел в /var/log/auth.log:
Authentication refused: bad ownership or modes for directory /wtecData/sjprod