Открытый ключ SSH — нет поддерживаемых методов аутентификации (сервер отправил открытый ключ)

У меня есть настройка сервера 12.10 на виртуальной машине с установленным мостом в сети (по сути, это будет компьютер, подключенный к моему коммутатору).

Я установил opensshd через apt-get и смог соединиться с сервером, используя putty с моим именем пользователя и паролем.

Затем я попытался заставить его использовать аутентификацию с открытым / закрытым ключом. Я сделал следующее:

1. Сгенерировал ключи с помощью PuttyGen.
2. Открытый ключ перенесен в /etc/ssh/myusername/authorized_keys (я использую зашифрованные домашние каталоги).

Настроить sshd_config так:

Когда я подключаюсь, используя putty или WinSCP, я получаю сообщение об ошибке: «Нет поддерживаемых методов аутентификации (сервер отправил открытый ключ)».

Если я запускаю sshd в режиме отладки, я вижу:

Почему это происходит и как я могу это исправить?

Похоже, была проблема с моим файлом открытого ключа. PuttyGen создаст файл открытого ключа, который выглядит следующим образом:

Однако это не сработает, поэтому вам нужно открыть ключ в PuttyGen, а затем скопировать его оттуда (в результате ключ будет в правильном формате и в 1 строке):

Вставьте это в authorized_keys то, что должно работать.

1. Отредактируйте /etc/ssh/sshd_config файл.
2. Изменить PasswordAuthentication и ChallengeResponseAuthentication на yes .

3a. Перезапустите SSH /etc/init.d/ssh restart .
ИЛИ
3б. лучше вы используете service sshd restart

Надеюсь, это просто подсказка, которая может помочь кому-то еще с головными болями, которые у меня были F21 прав, что вам нужно скопировать ключ из окна PuTTYGen вместо сохранения файла, но после копирования способ вставки может оказать существенное влияние на то, будет ли работать ваш ключ или нет. Некоторые редакторы изменяют текст по мере вставки или делают что-то с символами новой строки или что-то, что делает файл author_keys недействительным.

То, что я нашел наименее вероятным, это сломать всю строку и перенаправить вывод в файл. Щелкните правой кнопкой мыши в PuTTY, чтобы вставить строку ключа в командную строку, это работает так (с примером, приведенным выше):

Вы закончите с этим:

Еще одним преимуществом этого метода является то, что вы можете добавить несколько ключей таким образом, используя >> для добавления вместо> для перезаписи, например:

disconnected: no supported authentication methods available (server sent: publickey, gssapi-with-mic)

I don’t know what is happening.

I have been able to connect to the server for a couple of days without problems and suddendly I got a frozen window using putty. After that, each time I try to connect, I receive this message:

I am using putty and puttyagent for private key. I already have uploaded the public key to the server and I was able to connect half an hour ago.

How can I check why it is failing? I haven’t change the user or password or anything.

8 Answers 8

I had the same issue after creating a Centos 7 vm using Vagrant. In the sshd_config file it said «PasswordAuthentication no». Changing that to «PasswordAuthentication yes» and a restart of sshd solved it for me.

I had a similar issue:

• in putty console, I got the message saying «Server refused our key»
• windows error message was: «PuTTY Fatal Error» — «No supported authentication methods available (server sent: public key,gssapi-keyex,gssapi-with-mic)»

I was able to connect to EC2 via PowerShell successfully (with .pem file) so I realized that .ppk file was wrong.

Googled for about an hour and find that when you generate the .ppk with PuTTYgen for the first time you’ll see the key comment filed something like «rsa-key-20191006» and what should be there is «imported-openssh-key».

After I loaded the same .pem file, as for the first time (but DID NOT CLICK on Generate) and clicked Save Private Key and used this private key for Auth, everything worked as expected.

PuTTY fatal error: “No supported authentication methods available”

PuTTY fatal error:

When I tried to login into the production server, I am getting above error. Could anyone help me to fix this?

7 Answers 7

Set PasswordAuthentication yes

Then restart server

I think your private key file format is not compatible with putty for putty uses its’ native format instead.

Do you still have access to the server (maybe an open shell?) Check /var/log/messages for more details. This could have something to do with your PAM configuration.

Did you change folder permissions? i met this question in this week, so i find the error that is cause to me change the folder(name is ec2-user) permission.

1.Edit the /etc/ssh/sshd_config file. 2.Change PasswordAuthentication and ChallengeResponseAuthentication to yes. 3a. Restart ssh /etc/init.d/ssh restart. OR 3b. better you use service sshd restart

It worked for me after I did the following steps :

2- Open PUttyGen and then Load the private key from :

3- save the new private key with a new name.

4- Open Putty, go to Connection > SSH > Auth > and add the new private key

SSH Public Key — No supported authentication methods available (server sent public key)

I have a 12.10 server setup in a virtual machine with its network set to bridged (essentially will be seen as a computer connected to my switch).

I installed opensshd via apt-get and was able to connect to the server using putty with my username and password.

I then set about trying to get it to use public/private key authentication. I did the following:

1. Generated the keys using PuttyGen.
2. Moved the public key to /etc/ssh/myusername/authorized_keys (I am using encrypted home directories).

Set up sshd_config like so:

When I connect using putty or WinSCP, I get an error saying No supported authentication methods available (server sent public key).

If I run sshd in debug mode, I see:

Why is this happening and how can I fix this?

6 Answers 6

Looks like there was a problem with my public key file. PuttyGen will create a public key file that looks like:

However, this will not work, so what you need to do is to open the key in PuttyGen, and then copy it from there (this results in the key being in the right format and in 1 line):

Paste this into authorized_keys then it should work.

1. Edit the /etc/ssh/sshd_config file.
2. Change PasswordAuthentication and ChallengeResponseAuthentication to yes .

3a. Restart ssh /etc/init.d/ssh restart .
OR
3b. better you use service sshd restart

Just a tip I hope may help someone else with the headaches I had. F21 is right that you need to copy the key out of the PuTTYGen window instead of saving the file, but after copying, the way you paste may have significant impact on whether your key will work or not. Some editors will alter the text as you paste, or do something with newlines or something that makes the authorized_keys file invalid.

What I have found to be the least likely to break is to echo the full string and redirect the output to the file. Right-clicking in PuTTY to paste the key string to the commandline, it works out like this (with the example given above):

You’ll end up with this:

Another advantage of this method is that you can add multiple keys this way by using >> to append instead of > to overwrite, eg:

Устранение неполадок SSH: ошибки аутентификации

В первой статье этой серии вы узнали о том, как и в каких ситуациях вы можете попробовать исправить ошибки SSH. Остальные статьи расскажут, как определить и устранить ошибки:

• Проблемы с подключением к серверу: здесь вы узнаете, как исправить ошибки подключения к серверу.
• Ошибки протокола: в этой статье вы узнаете, что делать, если сбрасываются клиентские соединения, клиент жалуется на шифрование или возникают проблемы с неизвестным или измененным удаленным хостом.
• Ошибки оболочки: это руководство поможет исправить ошибки ветвления процессов, валидации оболочки и доступа к домашнему каталогу.

После установления соединения и инициирования протокола система может проверить подключение пользователя к системе. SSH поддерживает множество механизмов аутентификации. В этом руководстве рассмотрены два наиболее распространенных механизма: парольная аутентификация и аутентификация на основе SSH-ключей.

Требования

• Убедитесь, что можете подключиться к виртуальному серверу через консоль.
• Проверьте панель на предмет текущих проблем, влияющих на работу и состояние сервера и гипервизора.

Основные ошибки

Отказ в доступе (парольная аутентификация)

Примечание: Если вы настроили на сервере SSH-ключи и отключили PasswordAuthentication, сервер не поддерживает паролей. Используйте SSH-ключ, чтобы подключиться к серверу.

Клиенты PuTTY и OpenSSH выдают такое сообщение:

root@111.111.111.111’s password:
Permission denied (publickey,password).
PuTTY Error output
root@111.111.111.111’s password:
Access denied
Server sent disconnect message
type 2 (protocol error):
«Too many authentication failures for root»

Это значит, что аутентификация прошла неудачно. Ошибка может быть вызвана рядом проблем. Вот несколько советов по устранению этой ошибки:

• Убедитесь, что вы используете правильное имя пользователя. В CoreOS используйте пользователя core. В FreeBSD используйте аккаунт пользователя freebsd.
• Парольная аутентификация пользователя может быть нарушена. Проверьте, поддерживает ли парольную аутентификацию веб-консоль сервера. Если она не поддерживает пароли, вам придется попытаться сбросить пароль или обратиться за помощью к службе поддержки, чтобы восстановить доступ.
• Убедитесь, что сервер поддерживает парольную аутентификацию.

Отказ в доступе (аутентификация на основе SSH-ключей)

Этот метод использует криптографические ключи для аутентификации пользователя.

Читайте также:

Вы можете получить такую ошибку:

Permission denied (publickey).
PuTTY Error output
Disconnected: No supported authentication methods available (server sent: publickey)

Многие наиболее распространенные проблемы, связанные с аутентификацией на основе ключей, вызваны неправильными правами доступа к файлам или правами собственности. Чтобы устранить проблему, попробуйте сделать следующее:

• Убедитесь, что файл authorized_keys и сам закрытый ключ имеют правильные права доступа и собственности.
• Убедитесь, что сервер поддерживает аутентификацию на основе ключей SSH.
• Убедитесь, что клиент SSH может получить закрытый ключ. Если вы используете PuTTY, убедитесь, что ключи SSH правильно настроены в сессии. Если вы используете OpenSSH, убедитесь, что у закрытого ключа SSH есть соответствующие привилегии.
• Убедитесь, что файл authorized_keys содержит правильный открытый ключ, и что открытый ключ добавлен на сервер.
• Возможно, вы используете закрытый ключ, который больше не поддерживается сервисом OpenSSH. Эта ошибка обычно затрагивает серверы OpenSSH 7+ при использовании закрытого DSA-ключа SSH. Обновите конфигурацию сервера.

Консоль не поддерживает пароли

Если вы не можете восстановить доступ к консоли, это может указывать на проблемы с файловой системой или конфигурацией в подсистеме PAM, которые влияют на механизм аутентификации. Эта ошибка также повлияет на попытки сбросить пароль root и войти в систему через консоль.

В консоли появляется форма аутентификации:

Ubuntu 14.04.4 LTS server tty1
server Login:
Password:

Но после ввода пароля появляется ошибка:

После сброса пароля вы получите:

You are required to change your password immediately (root enforced)
Changing password for root.
(Current) UNIX Password:

Повторно введите текущий пароль. Если соединение закроется, возможно, вы допустили ошибку, повторно вводя пароль. Повторите попытку.

При успешном завершении вам будет предложено дважды ввести новый пароль:

Enter new UNIX password:
Retype new UNIX password:

Однако если после повторного ввода правильного нового пароля сессия перезапустится (т.е. снова вернется форма для входа в систему) или появится сообщение об ошибке, это означает, что проблема в одном из файлов, в котором хранятся данные аутентификации.

В таком случае рекомендуется обратиться за помощью в службу поддержки хостинг-провайдера, подготовить сервер к повторному развёртыванию или исправить ошибки в настройках PAM.

Устранение неполадок

Проверка доступных методов аутентификации

Если вы используете подробный вывод или следите за логами SSH-клиента, убедитесь, что в сообщении, описывающем методы аутентификации, указаны password и/или publickey.

debug1: Authentications that can continue: publickey,password

Если вы не нашли в списке метод аутентификации, который хотите использовать, откройте файл /etc/ssh/sshd_config. В нём часто допускается ошибка: PasswordAuthentication имеет значение yes, а PermitRootLogin – no или without-password для пользователя root.

Исправьте эту ошибку, перезапустите сервис.

Настройка прав доступа и собственности

Сервер и клиент OpenSSH имеют строгие требования к привилегиям и правам собственности на файлы ключей.

Сервер и клиент OpenSSH должны иметь следующие права:

./ssh должен принадлежать текущему аккаунту.

/.ssh/authorized_keys должен принадлежать текущему аккаунту.

Кроме того, клиент должен также иметь такие права:

/ .ssh / config – 600.

Эти изменения можно внести с помощью консоли.

Проверка открытого и закрытого ключа

Если вы забыли, какой закрытый ключ соответствует тому или иному открытому ключу, инструменты OpenSSH и PuTTY помогут вам сгенерировать открытый ключ на основе зарытого ключа. Полученный результат вы можете сравнить с файлом

Чтобы восстановить открытый ключ на основе закрытого ключа в среде OpenSSH, используйте ssh-keygen и укажите путь к закрытому ключу.

/.ssh/id_rsa
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfBiMwCU1xoVVp0VbSYV3gTDV/jB57IHdILQ8kJ2622//Lmi4gDPlxA6HXVKq8odkGD/5MjqUw85X2rwEbhoBul74+LCToYJvvvBaDPCgg5z1icCKIJ1m/LJBrGNqPKCgqFWu0EH4/EFP2XIQqWqX1BZtJu/2YWrTr+xFOE/umoYmOd+t3dzQqMsv/2Aw+WmA/x/B9h+41WrobDgCExYNLPYcD0PO7fpsa8CcrZCo+TUWCe7MgQQCSM6WD4+PuYFpUWGw3ILTT51bOxoUhAo19U8B2QqxbMwZomzL1vIBhbUlbzyP/xgePTUhEXROTiTFx8W9yetDYLkfrQI8Q05+f

В среде PuTTY команда PuTTYgen.exe загружает интерфейс, в котором можно использовать опцию Load и импортировать закрытый ключ. PuTTY хранит такие файлы в формате .ppk (нужно знать место хранения файла).

Импортировав ключ, вы увидите окно с разделом Public key for pasting into OpenSSH authorized_keys file. В нём и будет искомый открытый ключ. Выделите текст и вставьте его в файл. Он сгенерирует открытый ключ.

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfBiMwCU1xoVVp0VbSYV3gTDV/jB57IHdILQ8kJ2622//Lmi4gDPlxA6HXVKq8odkGD/5MjqUw85X2rwEbhoBul74+LCToYJvvvBaDPCgg5z1icCKIJ1m/LJBrGNqPKCgqFWu0EH4/EFP2XIQqWqX1BZtJu/2YWrTr+xFOE/umoYmOd+t3dzQqMsv/2Aw+WmA/x/B9h+41WrobDgCExYNLPYcD0PO7fpsa8CcrZCo+TUWCe7MgQQCSM6WD4+PuYFpUWGw3ILTT51bOxoUhAo19U8B2QqxbMwZomzL1vIBhbUlbzyP/xgePTUhEXROTiTFx8W9yetDYLkfrQI8Q05+f imported-openssh-key

Можно проигнорировать комментарий после открытого ключа (imported-openssh-key).

В любом случае этот открытый ключ нужно добавить в файл

OpenSSH 7 и устаревшие ключевые алгоритмы

В системах с OpenSSH 7 (FreeBSD и CoreOS по умолчанию) старые ключи DSA не поддерживаются.

Ключи ssh-dss считаются слабыми, вместо них рекомендуют использовать более надёжные современные алгоритмы.

Следовательно, в данном случае лучшим решением будет создать новые ключи и добавить их на хосты.

Однако в качестве обходного пути вы можете установить в PubkeyAcceptedKeyTypes значение +ssh-dss в файле /etc/ssh/sshd_config.

Заключение

Если у вас не получается самостоятельно настроить аутентификацию SSH, вы можете обратиться за помощью к службе поддержки своего хостинг-провайдера.