Putty: получение сервера отказано в нашей ключевой ошибке
Я создал пару ключей, используя puttygen.exe
(клиент-windows 8). На сервере (Ubuntu 12.04.3 LTS) я поместил свой открытый ключ в ~/.ssh/authorized_keys
. Открытый ключ таков:
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAopfM6RHOgnuc4Aftn3t4k5UIAT3StCAbn/vg/IMbphbXadshC+79sIlRq3P4zGzMjFTP4hKnzu6ehLV5lmj/qorq3SKT+bPO5Qrac3VbIlrGvuBFDDjP82I2Hwg3HzlsFTstqk++KToapaTYZ7jENEYyPl2wnzITJnt//+4U1o6juoXTKgdNE02hHnRZyHOV/bnkZyJJCEwJv5U0eXSThQnhmXtUxGT8U0HQNFiXfqIIVllhWiCnyrhhIaKz/CIJNAd2VmzyJzQtJtTQX8aWSNVrZju6Sv2/RncTNvsACdNgjjh/FH8PQXaep00jlJ3MOdsC8vz6VSPFbh6iKy1oLQ== rsa-key-20131231
так что это правильно (одна строка, без комментариев, начинается с ssh-rsa и т. д.)
.ssh
уровень разрешений dir составляет 700, разрешение файла authorized_keys-600. И каталог, и файл принадлежат фактическому пользователю, который я пытаюсь войти в систему.
когда я пытаюсь подключиться, я получаю 'server refused our key'
и сервер запрашивает пароль. Вот и все. Ничего не регистрируется в /var/log/auth.log
при попытке войти в систему с ключом.
Я искал везде, и все статьи и советы упоминают настройку chmod 600 и 700 для файла/каталога и правильное форматирование ключа. Я сделал все это, все еще получая ошибку "отказался от нашего ключа", и у меня закончились идеи.
23 ответов
хорошо, в моем ключе была небольшая опечатка. По-видимому, при вставке в файл первая буква была отрезана, и она началась с sh-rsa вместо ssh-rsa.
nrathathaus-ваш ответ был очень полезен, большое спасибо, этот ответ приписывают вам :) я сделал, как вы сказали, и установить это в sshd_conf:
LogLevel DEBUG3
глядя на журналы, я понял, что sshd читает ключ правильно, но отклоняет его из-за неправильного идентификатора.
добавление нескольких мыслей, поскольку другие ответы помогли,но не были точными.
прежде всего, как указано в принятом ответе, edit
/etc/ssh/sshd_config
и установите уровень журнала:
LogLevel DEBUG3
затем попробуйте аутентифицировать, и когда это не удается, найдите файл журнала:
/var/log/secure
у него будут ошибки, которые вы ищете.
Я добавляю этот ответ, чтобы помочь любому, как я, кто потратил часы, прочесывая Интернет без успеха.
ВАША ДОМАШНЯЯ ПАПКА МОЖЕТ БЫТЬ ЗАШИФРОВАНА.
или, если на то пошло, любая папка, в которую вложен ваш файл "authorized_keys". Блин, это сэкономило бы мне кучу времени. Чтобы проверить, go perform
ls -A
в каталоге, статус шифрования которого вы хотите определить. Если папка содержит папку с именем ".encryptfs", ответ-да, эта папка зашифрована. Это затруднит доступ к файлу "authorized_keys", содержащему открытый ssh-ключ, необходимый для проверки.
чтобы исправить это, поместите файл" authorized_key " в дерево каталогов, которое не содержит шифрования.
простым решением, которое я нашел, было переместить authorized_keys
файл от скрытого .каталог ssh и поместите его в системный каталог ssh:
/etc/ssh/keys/authorized_keys
Как только я это сделал, он работал без проблем.
имея ту же проблему в windows server 2008 r2 и исследовал много, чтобы решить, наконец, сделал это, следуя:
открыть C:\Program файлы (x86)\OpenSSH\etc\sshd_config с textpad или любым другим текстовым редактором
снимите комментарий со следующей строки, после удаления они должны выглядеть следующим образом:
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
сохраните его и попробуйте войти в систему с закрытым ключом теперь. повеселись.
в моем случае это проблема с разрешением.
я изменил уровень журнала DEBUG3
и /var/log/secure
Я вижу эту строку:
Authentication refused: bad ownership or modes for directory
Googled и я нашел этот пост:
https://www.daveperrett.com/articles/2010/09/14/ssh-authentication-refused/
chmod g-w /home/your_user chmod 700 /home/your_user/.ssh chmod 600 /home/your_user/.ssh/authorized_keys
в основном, он говорит мне:
- избавиться от группы
w
разрешение вашего пользователя home dir - изменить разрешите
700
на.ssh
dir - изменить разрешения для
600
на .
и это работает.
другое дело, что даже я включил root login, я не могу получить root
на работу. Лучше использовать другого пользователя.
благодаря nrathaus и /var/log/auth.log
расследование на уровне отладки происходит следующее.
еще одна причина заключается в том, что ваш домашний каталог может иметь разрешения, отличные от 755.
спасибо!
спасибо LogLevel DEBUG3
(в моем случае CentOS 7
лог в /var/log/secure
)
получается мой .ssh/authorized_keys
режим 644
, а не 600
и sshd
чувствовал, что в одиночку было не-идти, который я, наконец, обнаружил, читая этот файл журнала!
в моем случае мне пришлось отключить SELinux на Centos6.6, чтобы заставить его работать:)
Edit/etc/selinux / config и установите следующее, а затем перезагрузите хост.
selinux=disabled
кстати...забыл упомянуть, что мне пришлось установить LogLevel=DEBUG3, чтобы определить проблему.
у меня была такая же ошибка на solaris, но найдена в /var/adm / splunk-auth.входить следующее:
sshd: [auth.debug] debug1: PAM conv function returns PAM_SUCCESS
sshd: [auth.notice] Excessive (3) login failures for weblogic: locking account.
sshd: [auth.debug] ldap pam_sm_authenticate(sshd-kbdint weblogic), flags = 1
sshd: [auth.info] Keyboard-interactive (PAM) userauth failed[9] while authenticating: Authentication failed
в /etc / shadow учетная запись была заблокирована:
weblogic:*LK*UP:16447::::::3
удалена часть " *LK*":
weblogic:UP:16447::::::3
и я мог бы использовать SSH с authorized_keys как обычно.
В моем случае это было вызвано (/etc/ssh/sshd_config
):
PermitRootLogin no
изменено на yes
, перезапустил службу и вошел нормально.
Я столкнулся с этой проблемой сегодня, и моя проблема заключалась в том, что при копировании открытого ключа из файла также включаются новые символы строки. Вы можете использовать ": set list " в vim, чтобы увидеть все скрытые новые строки и удалить все новые строки, кроме последней. Кроме того, мой ключ отсутствовал "ssh-rsa" в начале. Убедитесь, что у вас есть и это.
для тех, кто получает эту ошибку от Windows Server, я получил эту же ошибку, и это была проблема учетной записи пользователя. Во многих организациях групповая политика для администраторов может не разрешать настройку SSH-сервера и соединений. При таком типе настройки это должно быть сделано из локальной учетной записи администратора. Возможно, стоит изучить, если вы подтвердили, что в открытом ключе нет опечаток.
Я использую файл PUTTYgen с psftp, и я столкнулся с этой проблемой на моем сервере Windows, когда нам потребовалось создать новые ключи для клиента. The private_key_name.ppk файл и open_ssh.txt-файл должен находиться в одном каталоге для подключения к работе.
я решил эту проблему, puttygen-это стороннее программное обеспечение, ssh-ключ, который генерируется им, не используется напрямую, поэтому вы должны внести некоторые изменения. Например, это выглядит так
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20170502"
AAAAB3NzaC1yc2EAAAABJQAAAQEAr4Ffd3LD1pa7KVSBDU+lq0M7vNvLp6TewkP7
*******C4eq1cdJACBPyjqUCoz00r+LqkGA6sIFGooeVuUXTOxbYULuNQ==
---- END SSH2 PUBLIC KEY ----
я опускаю некоторые из алфавитов в середине, замененный*, если нет, StackOverflow сказал мне, что формат кода неправильно, не позволяйте мне опубликовать。
это мой ssh-ключ, сгенерированный puttygen, вы должны изменить на это
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAr4Ffd3LD1pa7KVSBDU+lq0M7vNvLp6TewkP7wfvKGWWR7wxA8GEXJsM01FQw5hYWbNF0CDI7nCMXDUEDOzO1xKtNoaidlLA0qGl67bHaF5t+0mE+dZBGqK7jG9L8/KU/b66/tuZnqFqBjLkT+lS8MDo1okJOScuLSilk9oT5ZiqxsD24sdEcUE62S8Qwu7roVEAWU3hHNpnMK+1szlPBCVpbjcQTdiv1MjsOHJXY2PWx6DAIBii+/N+IdGzoFdhq+Yo/RGWdr1Zw/LSwqKDq1SmrpToW9uWVdAxeC4eq1cdJACBPyjqUCoz00r+LqkGA6sIFGooeVuUXTOxbYULuNQ== yourname@hostname
в моем случае, у меня удалены некоторые комментарии, такие как
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20170502"
---- END SSH2 PUBLIC KEY ----
и добавить ssh-rsa
в начале,
добавить yourname@hostname
в последний.
Примечание: не удалить==
в последнем и вы должны изменить "yourname" и "hostname" для вас, в моем случае, это uaskh@mycomputer
, yourname - это то, что вы хотите войти в свой vps .когда все эти вещи сделали, вы могли бы загрузить открытый ключ к дому уасха~/.ssh/authorized_keys
by cat public-key >> ~/.ssh/authorized_keys
затем sudo chmod 700 ~/.ssh
sudo chmod 600 ~/.ssh/authorized_keys
тогда вы должны изменить /etc/ssh / sshd_config, RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
моя операционная система CentOS 7, это мой первый раз к вопросу anwser ,я попробую мои усилия сделать, Спасибо!
у меня есть эта проблема, где sshd только читает из authorized_keys2
.
копирование или переименование файла исправили проблему для меня.
cd ~/.ssh
sudo cat authorized_keys >> authorized_keys2
P. S. Я с помощью Putty из Windows и использовать PuTTyKeygen для генерации пары ключей.
Я столкнулся с аналогичной проблемой при попытке входа в систему через Mobaxterm. Закрытый ключ был сгенерирован через puttygen. Регенерация ключа помогла в моем случае.
при использовании Cpanel вы можете проверить, авторизован ли ключ в
SSH-доступ > > открытые ключи > > управление > > авторизация или Деавторизация.
если вы получите эту ошибку в /var/log/secure
ошибка: key_read: key_from_blob AA
AAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwx04nfg+rKz93l7em1BsUBzjHPMsswD
это означает, что ваш ключ имеет пространство, если вы создали ключ через puttgen при просмотре .ppk
файл, он будет выглядеть так:
AAAAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG+rKz93l7em1BsUBzjHPMsswD
al74MLaJyhQD0pE23NS1izahbo1sJGnSJu2VJ//zxidSsba6xa6OvmeiKTwCz0E5
GMefdGVdpdbTlv99qjBl1+Nw1tDnHIC0+v9XmeZERQfCds9Kp1UivfReoYImntBC
gLtNyqRYrSu8csJCt7E1oY8QK6WP1vfYgAQ2taGyS9+g7FHyyf5VY2vH3oWzzbqz
xjsSLAv3zEQSm1LzSw9Pvc8iwasFyUMBOPj31CKQYTXyX8KpJTr0Zb7oqMauBE5L
VwxZhlcJHbj0FsMbF/+GRjvgexymCi3bHmwGQ6FEADNd0RkhdQ==
и когда вы попытаетесь вставить его, вы получите ошибку при чтении ключа, поэтому попробуйте отредактировать ключ и сделать его одной строкой и попробуйте
это должно выглядеть как-то
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG+rKz93l7em1BsUBzjHPMsswDal74MLaJyhQD0pE23NS1izahbo1sJGnSJu2VJ//zxidSsba6xa6OvmeiKTwCz0E5GMefdGVdpdbTlv99qjBl1+Nw1tDnHIC0+v9XmeZERQfCds9Kp1UivfReoYImntBCgLtNyqRYrSu8csJCt7E1oY8QK6WP1vfYgAQ2taGyS9+g7FHyyf5VY2vH3oWzzbqzxjsSLAv3zEQSm1LzSw9Pvc8iwasFyUMBOPj31CKQYTXyX8KpJTr0Zb7oqMauBE5LVwxZhlcJHbj0FsMbF/+GRjvgexymCi3bHmwGQ6FEADNd0RkhdQ== username@domainname
что работает для меня, так это:
- остановил экземпляр ec2
- снимите объемом
- прикрепите том со старым экземпляром, используя тот же ключ, и смог SSH
- установите том в некоторую временную папку
- проверил файл в каталоге mount_point/home/ec2-user/.ssh/authorized_keys
- В идеале, этот файл должен иметь нашу ключевую информацию, но для меня этот файл был пусто
- скопировал старый экземпляр файла authorized_keys во вновь смонтированный том
- отключить устройства
- reattach к исходному экземпляру ec2
- запустите его и дайте ему пройти проверку здоровья
на этот раз это работает для меня. Но я не знаю, почему у него нет информации о моем ключевом файле сначала, когда экземпляр был запущен. Проверить эту ссылку https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html#TroubleshootingInstancesConnectingMindTerm