Что означает эта ошибка SSH?

9

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

Вот в чем дело: я скопировал свой закрытый ключ с машины № 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?

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

Ответы:

7

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

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

Файловые права

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

Проблемы с авторизованными ключами

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

  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.

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

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

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

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

Ансгар Эстерманн
источник
-3

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

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

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