Попытка выполнить ssh-аутентификацию с ключевыми файлами: сервер отклонил наш ключ

53

Я пытаюсь настроить ssh-аутентификацию с ключевыми файлами вместо имени пользователя / пароля. Клиент - это Windows-бокс с PuTTY, а сервер - сервер Ubuntu 12.04 LTS.

Я скачал puttygen.exe, и он сгенерировал пару ключей. У /etc/ssh/sshd_configменя есть эта строка:

AuthorizedKeysFile %h/.ssh/authorized_keys

и в файле открытого ключа моего клиента это говорит это:

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "my@email.address.com"
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIEAr3Qo6T5XU06ZigGOd3eKvfBhFLhg5kWv8lz6
qJ2G9XCbexlPQGanPhh+vcPkhor6+7OmB+WSdHeNO652kTofnauTKcTCbHjsT7cJ
GNrO8WVURRh4fabknUHPmauerWQZ6TgRPGaz0aucU+2C+DUo2SKVFDir1vb+4u83
AV1pKxs=my@email.address.com
---- END SSH2 PUBLIC KEY ----

Я скопировал часть из «ssh-rsa AAA» в «my@email.address.com» и поместил ее в файл ~/.ssh/authorized_keysна моем сервере (в моей домашней папке). В PuTTY под Connection> SSH> Auth я ввел путь к закрытому ключу, сгенерированному на моем клиенте, и сохранил настройки сеанса.

Я перезапустил сервер SSH с

sudo service ssh restart

Теперь, если я загружаю профиль в PuTTY (я проверил, что закрытый ключ все еще находится в Соединении> SSH> Auth и что путь правильный) и запустил профиль, он говорит

Server refused our key

Я попытался поместить открытый ключ в файл в каталоге, ./ssh/authorized_keys/ но это не помогло, поэтому я использовал его ./ssh/authorized_keysкак файл , вставив в него ключ. Я также попытался сгенерировать пару секретных / открытых ключей на сервере, вставить открытый ключ ./ssh/authorized_filesи загрузить закрытый ключ в PuTTY на моем клиенте. Перезагрузка сервера тоже не помогла.

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

Также попытался сгенерировать 4096-битный ключ, думая, что 1024 слишком короткая

Как я могу заставить это работать? Спасибо!

РЕДАКТИРОВАТЬ:

Хорошо, /var/log/auth.logсказал:

sshd: Authentication refused: bad ownership or modes for directory /home/vorkbaard/.ssh

Google говорит мне, что ~/.ssh/должно быть 700 и ~/.ssh/authorized_keysдолжно быть 600, поэтому я сделал это. Теперь /var/log/auth.logговорит:

sshd: error: key_read: uudecode AAAAB3N [etc etc etc until about 3/4 of my public key]
Вилобородый
источник

Ответы:

95

Хорошо, это исправлено, однако я не вижу, как это отличается от того, что я уже пробовал.

Что я сделал:

  • создать пару ключей с помощью puttygen.exe (длина: 1024 бита)
  • загрузить приватный ключ в профиле PuTTY
  • введите открытый ключ в ~/.ssh/authorized_keys одну строку (необходимо начать с ssh-rsa)
  • chmod 700 ~/.ssh
  • chmod 600 ~/.ssh/authorized_keys
  • chown $USER:$USER ~/.ssh -R
  • изменить, /etc/ssh/sshd_configчтобы он содержалAuthorizedKeysFile %h/.ssh/authorized_keys
  • sudo service ssh restart

Для устранения неисправностей делай # tail -f /var/log/auth.log.

Спасибо за вашу помощь!

Вилобородый
источник
1
Хм, так что же случилось с этой sshd: error: key_read: uudecode AAAAB3Nошибкой auth.log?
Алаа Али
Понятия не имею, Алаа. Возможно, я сделал ошибку при вставке предыдущей ключевой строки. Auth.log больше не получает записей, и аутентификация на основе ключей работает безупречно. Моя главная проблема заключалась в том , что я не был уверен насчет того, что должно было быть сделано, делая , как , что гораздо сложнее. Так что я не знаю почему, но это работает. Еще раз спасибо за вашу помощь :)
Forkbeard
Потрясающие!!! Я почесал голову в течение 2 дней. Этот ответ спасает день!
Нака
Шаг 3 был уловкой для меня. Я не поместил открытый ключ в authorized_keysфайл, я просто вставил свой mykey.pubфайл в ~/.sshпапку и подумал, что он его заберет. Вместо этого, в конечном счете, мне нужно было запустить это или отредактировать и вставить ниже других ключей, которые могут быть там. cat mykey.pub >> authorized_keys, Теперь это кажется простым, но извлеченный урок состоит в том, что все открытые ключи должны храниться authorized_keysне только в ~/.ssh/каталоге. Кто-то, пожалуйста, сообщите, если это не правильное утверждение.
timbrown
если шаги не помогли, проверьте также: 1. вы скопировали сохраненный открытый ключ PuTTY в author_keys, а не OpenSSH 2. если вы скопировали с помощью копирования / вставки из PuTTYgen (что вам следует сделать), возможно, вы разбили открытый ключ в несколько строк; это должна быть одна строка; убедитесь, что вы не добавили начальные или конечные пробелы при копировании благодаря r_hartman centos.org/forums/viewtopic.php?t=990
mvladk
23

Я только что столкнулся с этой проблемой. Несмотря на то, что конфиг установлен правильно, как уже упоминалось в этой теме (права доступа на author_keys и т. Д.), Оказалось, что у меня был открытый ключ в неправильном формате. Это было в форме:

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "imported-openssh-key"
AAAAB3NzaC1yc2EAAAADAQABAAABAQDUoj0N3vuLpeviGvZTasGQ...
... lPmTrOfVTxI9wjax2JvKcyE0fiNMzXO7qiHJsQM9G9ZB4Lkf71kT
---- END SSH2 PUBLIC KEY ----

Который не работал. Но все заработало, имея форму:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDU.....j0N3vuLpeviGvZTasGQa1rcJiPXQMW7v3uurb+n94B9MQaaWR0odsg5DJQL92TNenOda5BO1nd08y6+sdLQmHXExTz6X8FzgoVsAkEl3RscxcxHUksiKA9JfTo38vQvG/bPxIHMCuSumCQVA1laf3rO/uOrkcB7iMWhaoi1/z6AbFtPzeh7xjGfInMWwtBI0CsHSRF73VWIxT26w0P+KjafCjSn/7vDO1bT8QHujSQelU/GqaVEvbbvPl1a7POVjKgHLNekolwRKfNeVEewcnmZaoqfHgOKlPmTrOfVTxI9wjax2JvKcyE0fiNMzXO7qiHJsQM9G9ZB4Lkf71kT UserName@HOSTNAME
kuraara
источник
14
Вы можете использовать ssh-keygen -i -f filenameofwindowsformpub.keyдля преобразования открытого ключа в формат, понятный вашему серверу OpenSSH.
черный
Да, это сработало для меня! Это должно быть в одной строке. Не могу поверить, что это было только это!
adelriosantiago
1
HI kuraara Я считаю, что приведенная выше инструкция @Black должна быть заметна в ответе.
ekerner
Могу ли я добавить комментарий к формату сервера OpenSSH? Для человека трудно сказать, на каком компьютере изображен этот ключ.
user1700890
Когда я следую предложению @Black, в конце строки нет имени пользователя @ HOSTNAME. Я не знаю, имеет ли значение эта часть.
arnoldbird
9

проблема в том, что windows использует новую строку, отличную от linux, поэтому при копировании ключа из windows в linux в конце строки есть \ n, который вы не можете увидеть в linux в редакторе.

Если вы подключите /var/log/auth.log и попытаетесь войти в систему, ошибка будет такой:

sshd: ошибка: key_read: uudecode AAAAB3N [....] == \ n

Если вы измените свой ключ в Windows так, чтобы он был в одной строке без новой строки в конце, а затем скопировал его в linux, он должен работать (сделал свое дело для меня).

Mischa
источник
это была моя проблема, но я не видел ничего в auth.log, чтобы предположить, что это так. расстраивает ...
Энтони
8

Я должен был изменить разрешения на домашний каталог

chmod 700 ~
Михал Змуда
источник
2
Это сработало и для меня (хотя в AIX).
stevepastelan
У меня тоже работал на CentOS
Jaywalker
Работал для меня на Redhat! Групповой доступ к записи, кажется, является специфической проблемой. По-прежнему работает для меня, если я оставлю права на групповое чтение на месте: "chmod 740 ~".
Пол
6

Мне пришлось изменить разрешения каталога ~ / .ssh с 770 до 700, а разрешения файла ~ / .ssh / authorized_keys с 660 до 600.

По какой-то причине удаление групповых разрешений исправило эту проблему для меня.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
dopple
источник
5

~/.ssh/authorized_keysФайл требует ключей , чтобы быть на одной линии. Если вы добавили его в несколько строк, как описано выше, попробуйте соединить строки.

Павел
источник
Спасибо, это имеет смысл, и теперь я понимаю, почему это файл, а не каталог. Однако это не помогло.
Forkbeard
3
для любого, кого это может смущать, он имеет в виду, что каждый ключ должен быть в одной строке, но разные ключи должны быть в разных строках.
Энтони
2

Вот что сработало для меня:

Через puttygen, после того, как вы сгенерировали свои ключи, убедитесь, что вы скопировали и вставили информацию из верхнего поля, чтобы перейти в свой файл author_keys. Если вы сохраните свой открытый ключ на своем клиентском компьютере, а затем откроете его, текст будет отличаться от текста в верхней части puttygenэкрана. Опять же, убедитесь, что вы копируете и вставляете текст из верхней части puttygenэкрана (после того, как вы создали свои ключи) в ваш файл author_keys, который должен находиться в ~/.ssh.

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

В дополнение ко всем приведенным выше ответам, убедитесь, что вы puttygenправильно скопировали и вставили ключ !

Если вы просто дважды щелкнете по массе ключевой строки, чтобы выбрать ее, вы можете не получить всю строку, потому что текстовое поле разбивает строки на некоторые символы, например +, так, что вы не выделяете текст после +символа ( что вы не можете видеть, потому что текстовое поле слишком мало). Не забудьте выбрать всю строку вручную, от ssh-rsaсамого конца текстового поля.

Марк Лаката
источник
1

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

echo 'the content of the public key' > /root/.ssh/authorized_keys
DAV
источник
1

для меня проблема была в том, что я создал ~/.ssh/authorized_keysс использованием root, так что root принадлежал. Я должен был chown sshuser:sshuser ~/.ssh/authorized_keysтогда работать

PeanutPower
источник
1

Я тоже столкнулся с этой ошибкой и решил ее, изменив права доступа для файла author_keys 600.

chmod 600 ~/.ssh/authorized_keys
Калима
источник
1

Распространенной ошибкой является то, что люди используют текстовый редактор (например, Vim) и вставляют скопированный текст перед активацией «вставки» (нажмите + i в Vim перед вставкой)

hakabe
источник
0

На самом деле, я изменил authorized_keysразрешение 644, затем проблема решена.

chmod 644 ~/.ssh/authorized_keys
Питер Лян
источник
0

для отладки open ssh можно использовать:

sudo `which sshd` -p 2020 -Dd

он запускает sshd на другом порту 2020. он запускает sshd как текущую программу, поэтому вывод выводится на экран. если закрыто, то закрыто.

затем попробуйте подключиться.

объяснение:

  • `which sshd` - находит адрес sshd, попробуйте выполнить, какой sshd увидит, что он печатает. при использовании обратных кавычек он выполняется и возвращает результат на месте.
  • -p 2020 - указывает порт
  • -D - войти в файл
  • -d - войти на экран

https://www.attachmate.com/documentation/rsit-unix-802/rsit-unix-guide/data/sshd_options_ap.htm

Шимон Дудкин
источник
Не могли бы вы расширить этот ответ? Что влекут за собой аргументы? Что делает команда (для кого-то неопытного)?
Ззач ...
-1

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

Смена владельца этих файлов на пользователя, которого вы хотите, не будет хорошей практикой, поэтому я пересмотрел свои шаги и убедился, что вошел в систему как пользователь, с которым я хотел использовать SSH, и снова создал .ssh и authorized_keys.

Указания по подключению Win7 к серверу Xubuntu 15.04: как создать SSH-ключи с Putty для подключения к VPS

Лео Фишер
источник