Попытка сделать аутентификацию SSH с файлами ключей: сервер отказался от нашего ключа
Я пытаюсь установить аутентификацию SSH с файлами ключей в земельном участке имени пользователя/пароля. Клиент является выполнением поля Windows, PuTTY и сервер являются сервером LTS Ubuntu 12.04.
Я загрузил 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 на моем сервере (в моем собственном homefolder). В PuTTY при Соединении> SSH> Автор я ввел путь к закрытому ключу, который это генерировало на моем клиенте и сохранило настройки сессии.
Я перезапустил ssh сервер с
sudo service ssh restart
Теперь, если я загружаю профиль в PuTTY (я проверил, что закрытый ключ находится все еще в Соединении> SSH> Автор и что путь корректен), и выполните профиль, говорит это
Server refused our key
Я пытался поместить открытый ключ в файл в соответствии с каталогом ./ssh/authorized_keys/ но это не помогло так, я использовал ./ssh/authorized_keys как файл, вставляя ключ в нем. Я также пытался генерировать частную/с открытым ключом пару на сервере, вставляя открытый ключ ./ssh/authorized_files и загрузка частной в PuTTY на моем клиенте. Перезагрузка сервера не помогла также.
Я нашел, что ошибка может быть решена путем помещения ключа в месте вне домашней папки пользователя, но это только полезно, если домашняя папка шифруется, который этот не.
Также испытанная генерация ключа на 4 096 битов, думая, возможно, 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]
17 ответов
Хорошо, это исправлено, однако я не вижу, как это отличается от того, что я уже пробовал.
Что я сделал:
- сгенерировали пару ключей с помощью 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.
Спасибо за вашу помощь!
Я создавал файлы .ssh и authorized_keys, когда входил в систему как пользователь root, что давало неправильные разрешения. Он также поместил все файлы в корневой каталог. Я считаю, что это корень многих проблем с «ключом отказано сервером».
Смена владельца этих файлов на пользователя, которого вы хотите, не будет хорошей практикой, поэтому я пересмотрел свои шаги и убедился, что вошел в систему как пользователь, с которым я хотел использовать SSH, и снова создал .ssh и authorized_keys. Ошибка.
Указания по подключению Win7 к серверу Xubuntu 15.04: Как создать SSH-ключи с Putty для подключения к VPS
для отладки open ssh можно использовать:
sudo `which sshd` -p 2020 -Dd
он запускает sshd на другом порту 2020. Он запускает sshd как текущую программу, поэтому вывод выводится на экран. если закрыто, то закрыто.
Затем попытайтесь подключиться.
объяснение:
- `which sshd` - находит адрес sshd, попробуйте выполнить, какой sshd увидит, что он печатает. при использовании обратных кавычек он выполняется и возвращает результат на месте.
- -p 2020 - указывает порт
- -D - запись в файл
- -d - запись в экран
Фактически, я изменил разрешение authorized_keys на 644, тогда проблема решена.
chmod 644 ~/.ssh/authorized_keys
Распространенная ошибка заключается в том, что люди используют текстовый редактор (например, Vim) и вставляют скопированный текст перед активацией «вставки» (нажмите + i в Vim перед вставкой)
Вот что сработало для меня:
В puttygen, после того, как вы сгенерировали свои ключи, убедитесь, что вы скопировали и вставили информацию из верхнего поля, чтобы перейти в свой файл author_keys. Если вы сохраните свой открытый ключ на своем клиентском компьютере, а затем откроете его, текст будет отличаться от текста в верхней части экрана puttygen. Опять же, убедитесь, что вы копируете и вставляете текст из ВЕРХа экрана puttygen (после того, как вы создали свои ключи) в ваш файл author_keys, который должен находиться в ~/.ssh.
Я тоже столкнулся с этой ошибкой и решил ее, изменив права доступа файла author_keys на 600.
chmod 600 ~/.ssh/authorized_keys
для меня проблема заключалась в том, что я создал ~/.ssh/authorized_keys, используя root, которым владеет root. Мне пришлось chown sshuser:sshuser ~/.ssh/authorized_keys, потом он начал работать
В дополнение ко всем приведенным выше ответам, убедитесь, что вы правильно скопировали и вставили ключ из puttygen!
Если вы просто дважды щелкнете по массе ключевой строки, чтобы выделить ее, вы можете не получить всю строку, потому что текстовое поле разбивает строки на некоторые символы, такие как +, так что вы не можете не выбирайте текст после символа + (который вы не видите, потому что текстовое поле слишком маленькое). Не забудьте выбрать всю строку вручную, от ssh-rsa до самого конца текстового поля.
Файл ~/.ssh/authorized_keys требует, чтобы ключи были все в одной строке. Если вы добавили его в несколько строк, как описано выше, попробуйте соединить строки.
Мне пришлось изменить разрешения каталога ~ / .ssh с 770 до 700, а разрешения файла ~ / .ssh / authorized_keys с 660 до 600.
По какой-то причине удаление групповых разрешений исправило эту проблему для меня.
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
Мне пришлось изменить права доступа к домашнему каталогу
chmod 700 ~
Проблема в том, что в Windows используется новая новая строка , чем в Linux, поэтому при копировании ключа из Windows в Linux в конце строки появляется \ n , что Вы не можете увидеть на Linux в редакторе.
Если вы подключите /var/log/auth.log и попытаетесь войти в систему, ошибка будет выглядеть следующим образом:
sshd: ошибка: key_read: uudecode AAAAB3N [....] == \ n
Если вы измените свой ключ в Windows, чтобы он был в одной строке без новой строки в конце, а затем скопировали его в linux, он должен работать (сделал трюк для меня).
Я только что столкнулся с этой проблемой. Несмотря на то, что конфиг установлен правильно, как уже упоминалось в этой теме (права доступа на 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
Иногда это может быть проблемой, связанной с наличием открытого ключа в одной строке, этот подход, кажется, решает ее
echo 'the content of the public key' > /root/.ssh/authorized_keys
У меня была эта проблема в экземпляре AWS, где я переместил /home с корневого диска на новый отдельный диск в xvdf из-за свободного места.
В логах ничего не было ни под авторизацией, ни под защитой, ни сообщениями.
В конце концов я предположил, что SELinux был виновником, и некоторые поисковые запросы привели меня к audit2allow -w -a, который показал полезную ошибку при открытии файла author_keys пользователя.
Исправление состояло в том, чтобы запустить restorecon -R -v /home, который переименовал вещи на новом диске, а затем selinux был рад использовать пользовательский файл .ssh/authorized_keys.
Если вы пробовали много способов внутри .ssh и все потерпели неудачу, есть вероятность, что вам может понадобиться chmod g-w ~, если вы работаете в многопользовательской среде.