SSH Keys Authentication продолжает запрашивать пароль

Я пытаюсь установить доступ от ServerA(SunOS) к ServerB(некоторые пользовательские Linux с клавиатурным интерактивным входом в систему) с помощью ключей SSH. В качестве доказательства концепции я смог сделать это между 2 виртуальными машинами. Теперь в моем реальном сценарии жизни это не работает.

Я создал ключи в ServerA, скопировал их в папки ServerB, chmod'd .ssh в 700 на обоих серверах A,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, как я не мог. Вставьте первую строку вашего ключа в ваш файл author_keys "ServerB" БЕЗ последних 2 символов, затем введите пропущенные символы из строки 1 и первый из строки 2, это предотвратит добавление "новой строки" между первым и вторая строка ключа. Повторите с 3-й линией.

Источник

8 ответов

Решение

Я не думаю, что ваши ключи были правильно скопированы, если у вас есть 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'
Источник

Вы должны проверить разрешение файлов на удаленной машине, используя 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

Источник

Эти проблемы (которые обычно связаны с разрешениями) гораздо легче отлаживать со стороны сервера. Я рекомендую вам запустить другой sshd в режиме отладки с помощью: /usr/sbin/sshd -d -p 2222 который запустит другой sshd на порт 2222, затем запустит ssh -p 2222 user@sshserver на стороне клиента. Посмотрите, что выходит из sshd, когда ваш клиент пытается аутентифицироваться.

Проблемы с разрешениями не должны быть просто /home/$USER/.ssh, это также может быть проблемой с /, /home, или же /home/$USER, Если какой-либо из них доступен для записи в группе, это может быть проблемой.

Другая распространенная проблема заключается в том, что вы неправильно вставили и поместили разрывы строк в середине ключа в файле авторизованных_ключей

Источник

Ваш журнал отладки показывает, что сервер не принял ни один из ваших личных ключей RSA. Вы должны либо указать конкретный правильный файл ключа, либо проверить, что на сервере есть правильный файл открытого ключа.

Как сказал @Fredrik, права доступа к файлам также могут сыграть свою роль. SSH откажется использовать записи открытого ключа, в которые могут писать другие, и записи закрытого ключа, которые могут читать другие.

Источник

Самый простой способ настроить ключи - запустить

ssh-copy-id <remotehost>

на компьютере, который будет подключаться (например, на вашей рабочей станции)

Он должен запросить ваш пароль, а затем скопировать ключ и настроить разрешения соответствующим образом.

Источник

Исходя из вышеизложенного, я не могу сказать, в чем проблема. Тем не менее, чаще всего я сталкивался с этой причиной, потому что для ключей были установлены права на чтение слишком (например, для группы или другого пользователя, а не только для пользователя). Вот где я бы начал искать.

Источник

Не забудьте иметь это в~/.ssh/config

      Host *
ForwardAgent yes
# Or
Host yourhost
ForwardAgent yes
Источник

В моем случае я настроилStrictModesотyesкno.

sudo vim /etc/ssh/sshd_config

      StrictModes no
Источник
Другие вопросы по тегам