Putty: получение сервера отказано в нашей ключевой ошибке

добавление нескольких мыслей, как другие ответы помогли, но не были точно подходят.

прежде всего, как указано в принятом ответе, edit

/etc/ssh/sshd_config

и установите уровень журнала:

LogLevel DEBUG3

затем попробуйте аутентифицировать, и когда это не удается, найдите файл журнала:

/var/log/secure

Она будет иметь ошибки, которые вы ищете.

в моем случае мне пришлось изменить разрешения /home / user с 0755 на 0700.

Я добавляю этот ответ, чтобы помочь всем, кто, как и я, часами рыскал по интернету без успеха.

ВАША ДОМАШНЯЯ ПАПКА МОЖЕТ БЫТЬ ЗАШИФРОВАНА.

или, если на то пошло, любая папка, в которую вложен ваш файл "authorized_keys". Блин, это сэкономило бы мне кучу времени. Чтобы проверить, перейдите выполнить

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

погуглил и нашел этот пост:

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 реж
• изменить разрешения для 600 на .

и это работает.

другое дело, что даже я включил корневой логин, я не могу получить 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, когда нам потребовалось создать новые ключи для клиента. Элемент private_key_name.файл ppk и open_ssh.txt-файл должен быть в том же каталоге для подключения к работе.

в моем случае дом на nfs был 777, должен был быть 750. Это исправило проблему.

я решил эту проблему, 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 в последний. Примечание: не удалить== в прошлом, и вы должны изменить "Ваше имя" и "имя" для вас, в моем случае это uaskh@mycomputer, ваше имя - это то, что вы хотите войти в свой vps .когда все это будет сделано, вы можете загрузить открытый ключ в дом uaskh~/.ssh/authorized_keys by cat public-key >> ~/.ssh/authorized_keys затем sudo chmod 700 ~/.sshsudo chmod 600 ~/.ssh/authorized_keys затем вы должны изменить /etc / ssh/sshd_config,RSAAuthentication yesPubkeyAuthentication 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
Aab3nzac1yc2eaaaaabjqaaaqeaoo3pfwx04nfg+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 на новый смонтированный том
• отключить устройства
• присоединить к исходному экземпляру ec2
• запустите его и дайте ему пройти проверку здоровья

на этот раз это работает для меня. Но я не знаю, почему у него нет информации о моем ключевом файле сначала, когда экземпляр был запущен. Проверьте эту ссылку тоже https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html#TroubleshootingInstancesConnectingMindTerm

другая причина может быть UTF-8 BOM на .