Я настроил небольшой Linux-бокс несколько месяцев назад и настроил беспарольный вход по ssh как для моего личного идентификатора пользователя, так и для идентификатора учетной записи службы. Это работает нормально для обоих. Я сохранил файлы закрытого/открытого ключа для учетной записи службы в том же месте, где я сохранил ключи для моего личного идентификатора пользователя, на клиентском боксе.
В качестве основного руководства я использую следующее:http://www.tecmint.com/ssh-passwordless-login-using-ssh-keygen-in-5-easy-steps/.
Сегодня я настроил второй ящик, намереваясь настроить его таким же образом. У меня не возникло проблем с тем, чтобы он заработал для моего личного идентификатора пользователя. Однако он все еще не работает для учетной записи службы, и я не понимаю, почему. Когда я пытаюсь подключиться по ssh с учетной записью службы ко второму ящику, он запрашивает у меня пароль, а затем впускает меня.
Я проверил, что открытый ключ для учетной записи службы вставлен в файл ~/.ssh/authorized_keys на обоих устройствах, и значение ключа одинаково на обоих устройствах.
Я проверил, что ~/.ssh имеет права доступа 700, а ~/.ssh/authorized_keys — 600 (я также тестировал с 640, что, как я прочитал, является рекомендуемым значением). Я проверил это на обоих компьютерах в домашнем каталоге для учетной записи службы.
Обратите внимание, что числовой идентификатор пользователя для учетной записи сервиса отличается на двух ящиках. Я бы не думал, что это будет иметь какое-либо значение.
Я также заметил, что после того, как я подключаюсь по ssh к любому из компьютеров с помощью учетной записи службы, если я затем пытаюсь подключиться по ssh к ДРУГОМУ компьютеру с этой учетной записи службы, у меня запрашивается пароль.
Нужно ли мне что-то делать с «known_hosts» или что-то еще?
Обновлять:
Как и было рекомендовано, я попробовал запустить ssh с параметром «-v» и проверить вывод попытки ssh.
Вот вывод с некоторыми исключениями:
% ssh -v [email protected]
OpenSSH_7.2p2, OpenSSL 1.0.2h 3 May 2016
debug1: Reading configuration data /home/myuserid/.ssh/config
debug1: /home/myuserid/.ssh/config line 2: Applying options for *
debug1: Connecting to targethost.com [...] port 22.
debug1: Connection established.
debug1: identity file /home/myuserid/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug1: Authenticating to targethost.com:22 as 'serviceaccountid'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:...
debug1: Host 'targethost.com' is known and matches the ECDSA host key.
debug1: Found key in /home/myuserid/.ssh/known_hosts:18
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/myuserid/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/myuserid/.ssh/id_dsa
debug1: Trying private key: /home/myuserid/.ssh/id_ecdsa
debug1: Trying private key: /home/myuserid/.ssh/id_ed25519
debug1: Next authentication method: password
[email protected]'s password:
Мне кажется любопытным, что в последних нескольких строках, после "Следующий метод аутентификации: publickey", ссылки на пути к файлам указывают на "/home/myuserid", а не на "/home/serviceaccountid". Это похоже на большую подсказку.
решение1
Я не могу добавлять комментарии с помощью своей учетной записи, но это всего лишь моя попытка узнать больше, чтобы помочь устранить неполадки.
Похоже, у вас три компьютера, один локальный и два удаленных. И на каждом из них есть две учетные записи, с которыми вы работаете?
Если у вас есть личная и служебная учетные записи на локальном компьютере и вы работаете ssh service@remote-2с личной учетной записи на локальном компьютере, то будут найдены только ключи SSH для вашей локальной личной учетной записи, а не для служебной учетной записи. Это не должно иметь значения, если вы добавили локальный личный открытый ключ в файл авторизованных ключей удаленной служебной учетной записи.
Мне кажется любопытным, что в последних нескольких строках, после "Следующий метод аутентификации: publickey", ссылки на пути к файлам указывают на "/home/myuserid", а не на "/home/serviceaccountid". Это похоже на большую подсказку.
Это ssh ищет ключи в локальной учетной записи. Это должен быть домашний каталог любой учетной записи, из которой вы вызываете ssh. Если вы ожидаете, что этот путь будет домашним каталогом учетной записи службы, то вам нужно войти в учетную запись службы изатемзапустить ssh.