Я пытаюсь установить доступ с ServerA (SunOS) на ServerB (некоторые пользовательские Linux с интерактивным входом с клавиатуры) с помощью ключей SSH. В качестве доказательства концепции мне удалось сделать это между двумя виртуальными машинами. В моем реальном жизненном сценарии это не работает.
Я создал ключи в ServerA, скопировал их на ServerB, настроил папки .ssh на 700 на обоих ServerA и B.
Вот журнал того, что я получил.
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: Peer sent proposed langtags, ctos:
debug1: Peer sent proposed langtags, stoc:
debug1: We proposed langtags, ctos: en-US
debug1: We proposed langtags, stoc: en-US
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv key bits set: 125/256
debug1: bits set: 1039/2048
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'XXX.XXX.XXX.XXX' is known and matches the RSA host key.
debug1: Found key in /XXX/.ssh/known_hosts:1
debug1: bits set: 1061/2048
debug1: ssh_rsa_verify: signature correct
debug1: newkeys: mode 1
debug1: set_newkeys: setting new keys for 'out' mode
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: set_newkeys: setting new keys for 'in' mode
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /XXXX/.ssh/identity
debug1: Trying public key: /xxx/.ssh/id_rsa
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Trying private key: /xxx/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
Password:
Password:
ServerB имеет довольно ограниченные действия, так как это собственный собственный Linux.
Что могло случиться?
РЕДАКТИРОВАТЬ С ОТВЕТОМ:
Проблема заключалась в том, что у меня не были включены эти настройки в sshd_config (см. Принятый ответ) И что при вставке ключа с ServerA на ServerB он будет интерпретировать ключ как 3 отдельные строки.
Что я сделал, так это на случай, если вы не можете использовать ssh-copy-id, как я. Вставьте первую строку своего ключа в файл authorized_keys «ServerB» БЕЗ последних двух символов, затем введите недостающие символы из строки 1 и первый из строки 2, это предотвратит добавление «новой строки» между первой и вторая строка ключа. Повторите то же самое с 3-й линией.
Я не думаю, что ваши ключи были правильно скопированы, если у вас есть ssh-copy-id доступно, я бы порекомендовал вам использовать это.
$ ssh-copy-id user@remote_server
Password:
После того, как вы введете пароль, ваш SSH-ключ будет скопирован, и вы сможете просто использовать ssh без повторного ввода пароля.
Также проверьте конфигурацию SSH на ServerB и проверьте пару вещей.
$ vi /etc/ssh/sshd_config
Другое дело проверить эти настройки:
RSAAuthentication yes
PubKeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys
Значение AuthorizedKeysFile здесь вам нужно вставить свой открытый ключ ssh.
Вы можете получить информацию о своем SSH-ключе, используя: ssh-add -L
Обновлено
когда ssh-copy-id не существует, вы можете поступить по-старому:
$ cat ~/.ssh/id_rsa.pub | ssh user@remote_host 'cat >> /home/user/.ssh/authorized_keys'
Ваш журнал отладки показывает, что сервер не принял ни одного из ваших личных ключей RSA. Вы должны либо указать конкретный правильный ключевой файл, либо проверить, что на сервере есть правильный файл открытого ключа.
Как сказал @Fredrik, разрешения на файлы также могут играть роль. SSH откажется использовать записи открытого ключа, которые другие могут записывать, и записи закрытого ключа, которые другие могут читать.
Эти проблемы (которые являются обычно связанные с разрешениями) намного легче отлаживать со стороны сервера. Я рекомендую вам запустить еще один sshd в режиме отладки с помощью: /usr/sbin/sshd -d -p 2222 который запустит другой sshd на порт 2222, затем запустите ssh -p 2222 user@sshserver на стороне клиента. Посмотрите, что выходит из sshd, когда ваш клиент пытается пройти аутентификацию.
Проблемы с разрешениями не должны быть просто /home/$USER/.ssh. это также может быть проблема с /, /home, или /home/$USER. Если какой-либо из них доступен для групповой записи, это может быть проблемой.
Другая распространенная проблема заключается в том, что вы неправильно вставляете и помещаете разрывы строк в середине вашего ключа в файле authorized_keys
Исходя из вышесказанного, не могу сказать, в чем проблема. Однако в большинстве случаев я сталкивался с этим, причина заключалась в том, что для ключей были установлены права, которые были слишком удобочитаемыми (как в случае, когда они доступны для чтения для группы или другого, а не только для пользователя). Вот где я бы начал искать.
Вы должны проверить разрешение файлов на удаленном компьютере, используя ls -l ~/.sshи настройте разрешение:
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/<private_key> Пример: chmod 600 ~/.ssh/id_rsa
chmod 700 ~/.ssh/<public_key> Пример: chmod 700 ~/.ssh/id_rsa.pub
chmod 700 /home/vmirea/.ssh
Самый простой способ настроить ключи - запустить
ssh-copy-id <remotehost>
на машине, которая будет подключаться (например, на вашей рабочей станции)
Он должен запросить ваш пароль, а затем скопировать ваш ключ и соответствующим образом настроить разрешения.