Вопрос: Что означает эта ошибка ssh?


Это мое последнее средство. Я пытался выяснить проблему здесь часами.

Вот сделка: я скопировал свой секретный ключ с машины №1 на машину №2. Машина № 1 может подключаться через ssh к серверу с открытым ключом, но машина # 2 дает следующий вывод при попытке подключения к серверу:

$ ssh -vvv -i /home/kevin/.ssh/kev_rsa user@192.168.1.244 -p 22312
OpenSSH_5.3p1 Debian-3ubuntu6, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.1.244 [192.168.1.244] port 22312.
debug1: Connection established.
debug3: Not a RSA1 key file /home/kevin/.ssh/kev_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace

...


Permission denied (publickey).

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

У меня также было подозрение, что это связано с тем, как я скопировал его с машины №1 на машину №2. Я копирую / вставляю текст из закрытого ключа на флешку. Это может быть проблемой, однако, когда я дублировал этот метод на другом рабочем файле закрытого ключа и делал разницу с оригиналом, в скопированную / вставленную, они идентичны.

Я боролся с этим. Если бы я мог получить немного больше информации о том, почему мне не нравится мой ключ, я могу это исправить, я уверен. У кого-нибудь есть идеи по этому поводу? Есть ли какие-то метаданные где-то, где ssh сообщает, что файл на самом деле является ключом RSA?


9
2017-08-09 00:26


Источник


И что /var/log/auth.log на сервере говорят? - womble♦
Для выяснения, открытый ключ от машины 1 подключается к серверу. Закрытый ключ от машины 1, работающий на машине 2, не будет подключен к серверу? - Dru
У меня есть одна и та же пара ключей на обеих машинах, и открытый ключ находится на сервере. Я скопировал вставные ключи с клиентского компьютера 1, у которого нет проблем с подключением к серверу, здесь, на моем домашнем компьютере (машина 2), который испытывает эту проблему аутентификации. - kevin
@womble, к сожалению, я не могу получить доступ к серверу, если я смогу понять это, я смогу ssh прямо в .. Ahh, ирония ...;) - kevin
Каковы операционные системы на двух клиентских машинах? Может ли передача закрытого ключа отбросить окончания строки или ввести текст (возможно, пустые строки или пробелы) до строки открытия? - Stobor


Ответы:


По моему опыту, две наиболее распространенные ошибки аутентификации на основе ключа

  1. Недопустимо широкие разрешения на $HOME/.ssh каталог
  2. Ошибка при копировании открытого ключа в удаленную систему

Разрешения для файлов

OpenSSH многое делает для того, чтобы защитить вас от вас самих. Самый влиятельный способ воздействия на пользователя - это принудительное ограничение доступа к локальной папке ssh. Вы действительно хотите, чтобы вы и только вы, чтобы получить доступ к каталогу. Ну и кто-нибудь с uid = 0, но нет хорошего пути. Так что вам нужно просто изменить свои разрешения: chmod -R go-rwx ~/.ssh Это приведет к удалению прав на чтение, запись и выполнение любых файлов под каталогом .ssh от всех пользователей, кроме владельца, т. Е. вы,

Авторизованные ключи

Файл, содержащий ваш открытый ключ, обычно $HOME/.ssh/authorized_keys должен соответствовать очень конкретной форме для SSH, чтобы понять, как принимать закрытый ключ. Каждый ключ должен состоять, по крайней мере, из двух полей

  1. Тип используемого ключа (RSA, DSA, RSA1 и т. Д.)
  2. ключ

Каждый ключ вместе со всеми его параметрами и составными частями должен быть указан по одному в строке в этом файле. Поскольку ключи имеют тенденцию быть очень длинными, они часто будут обертываться и отображаться как две строки на вашем терминале. Это иногда может привести к хаосу при попытке копирования / вставки, поскольку иногда одна или несколько строк новой строки будут вставлены туда, где ключ обертывается на вашем экране. Устранение этой проблемы Можно быть немного сложнее для начинающих оболочек.

Попробуйте запустить
wc -l ~/.ssh/authorized_keys
Это напечатает количество строк в файле. Сравните это число с количеством ключей, которые вы ожидаете в файле. Если вы принимаете только один ключ, вы также можете просто сделать копию файла открытого ключа, так как это тот же формат, что и ваш файл авторизованных ключей. Что-то вроде
scp -p ~/.ssh/kev_rsa.pub remotehost:~/.ssh/authorized_keys
или, если у вас есть открытый ключ в той же системе, вы можете сделать
cat ~/.ssh/kev_rsa.pub >> ~/.ssh/authorized_keys

Кроме того, загляните в файл журнала на удаленном хосте и посмотрите, не сообщаются ли там какие-либо ошибки. Файлы, скорее всего, будут либо /var/log/secure.log или /var/log/auth,


7
2017-08-09 01:16



Привет, Спасибо за ваше усилие здесь. Я ценю это. Это определенно не проблема с разрешениями. Я проверял разрешения правильно. (Я должен был добавить это как предостережение). Кроме того, хотя я не могу получить доступ к исходным ключам прямо сейчас, я продублировал процесс, который я использовал для копирования ключа, который я использую. Я даже сделал md5sum, чтобы проверить, что файлы идентичны. Имеют смысл? - kevin
И снова я не могу получить доступ к серверу. Вид всей проблемы здесь ...;) - kevin
@Scott: make a copy of the private key file должно быть открытый ключ (как показано в ваших примерах) - mlp


Хотя вам, вероятно, придется создать новую пару ключей для машины 2 для подключения к серверу. Часто открытый ключ будет отображать имя пользователя и машины тех, кто их создал. Это должно быть очевидно в файле authorized_keys на сервере.


0
2017-08-09 01:00



Я был под впечатлением, что он игнорирует те, что они просто комментарии, чтобы помочь вам идентифицировать их при просмотре authorized_keys. И вообще, опять же, я просто копировал / вставлял ключи. Таким образом, они идентичны. Я серьезно сомневаюсь, что он проверяет ваше имя хоста. Если бы это было так, я мог бы легко это изменить. Что, черт возьми, я все равно попробую ... - kevin


Отладочные сообщения, которые вы указываете, означают, что файл закрытого ключа читается с предположением, что он фактически является файлом открытого ключа / уполномоченного хоста. Это может быть не фатальная ошибка (я получаю такие сообщения даже для рабочих подключений). Скажет ли он что-нибудь о «Предложение» или «Мы отправили»?


0
2018-01-23 09:44





Попробуйте сравнить файлы конфигурации ssh между двумя серверами.

то есть. что-то вроде cat / etc / sshd_config


-3
2017-08-09 00:34



Я должен был быть более ясным. Есть два клиента, один сервер. Я не могу получить доступ к серверу или другому клиентскому компьютеру. Я смогу получить доступ к серверу, как только этот проклятый ключ будет аутентифицироваться;) - kevin