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

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

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

/etc/ssh/sshd_config

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

LogLevel DEBUG3

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

/var/log/secure

у него будут ошибки, которые вы ищете.

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

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

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

или, если на то пошло, любая папка, в которую вложен ваш файл "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-файл должен находиться в одном каталоге для подключения к работе.

в моем случае дом на 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 в последний. Примечание: не удалить== в последнем и вы должны изменить "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

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