Debug1 authentications that can continue publickey password

[РЕШЕНО] ssh авторизация по ключу

Стоит проверить конфиг sshd ( /etc/ssh/sshd_config)на предмет :

RSAAuthentication yes
PubkeyAuthentication yes

Также в var/log/auth.log может осядут попытки неудачных авторизаций

Еще странно, что «No more authentication methods to try.» Пароль-то почему не спрашивает, по дефолту всяко должен. что в конфиге менялось еще?

debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred publickey
debug3: authmethod_lookup publickey
debug3: remaining preferred:
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/user/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /Users/user/.ssh/id_dsa
debug3: no such identity: /Users/user/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /Users/user/.ssh/id_ecdsa
debug3: no such identity: /Users/user/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /Users/user/.ssh/id_ed25519
debug3: no such identity: /Users/user/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,password,keyboard-interactive).

/home папка зашифрована, расшифровывается она когда запущена сессия. Есть какой-то принятый флоу для хранения ключей?

SSH авторизация по ключу

Делаю SSH авторизация по ключу. На клиенте сижу под пользователем candidate, захожу на сервер под пользователем tech. Настроил все по правилам, как доктор прописал.

debian посылает на все три буквы, как будто конфиг /etc/ssh/sshd_config вообще не при делах

debug1: Next authentication method: publickey

debug1: Offering public key: /home/candidate/.ssh/id_rsa

debug1: Authentications that can continue: publickey,password

debug1: Trying private key: /home/candidate/.ssh/identity

debug1: Trying private key: /home/candidate/.ssh/id_dsa

debug1: Next authentication method: password

Permission denied (publickey,keyboard-interactive).

Все работает, ты просто не правильно делаешь.

Ключи — dsa или rsa?

Надо попробовать смоделировать что-то подобное (правда, дебиана под рукой нет).

В том и дело, что правильно. Просто почему-то Ему на конфиг пофиг. Так, вопрос: почему он ищет ключи /home/candidate/.ssh/identity /home/candidate/.ssh/id_dsa когда я ему проставил явно RSA и authorized_keys?

Наверное, authorized_keys2 все-таки.

Хотя это не важно, наверное.

authorized_keys на сервере, конечно же, в /home/tech/.ssh
да?

Ага, только не РСА, а ДСА почему-то.

на всякий случай копировал все везда))

candidate@candidate:/$ dir /home/candidate/.ssh/ authorized_keys id_rsa id_rsa.pub known_hosts

]$ dir /home/tech/.ssh/ autorized_keys id_rsa.pub id_rsa_2009.pub identity known_hosts

что лежит в authorized_keys на сервере? надо чтобы там лежада строчка из id_rsa.pub

например, cat id_rsa.pub >> authorized_keys

Более детально: debug2: key: /home/candidate/.ssh/id_rsa (0xb7f15610)

debug2: key: /home/candidate/.ssh/identity ((nil))

debug2: key: /home/candidate/.ssh/id_dsa ((nil))

debug1: Authentications that can continue: publickey,password

debug3: start over, passed a different list publickey,password

debug3: preferred gssapi-keyex,gssapi-

debug3: authmethod_lookup publickey

debug3: remaining preferred: keyboard-interactive,password

debug3: authmethod_is_enabled publickey

debug1: Next authentication method: publickey

debug1: Offering public key: /home/candidate/.ssh/id_rsa

debug2: we sent a publickey packet, wait for reply

debug1: Authentications that can continue: publickey,password

debug1: Trying private key: /home/candidate/.ssh/identity

debug3: no such identity: /home/candidate/.ssh/identity

debug1: Trying private key: /home/candidate/.ssh/id_dsa

debug3: no such identity: /home/candidate/.ssh/id_dsa

debug2: we did not send a packet, disable method

debug3: authmethod_lookup password

debug3: authmethod_is_enabled password

debug1: Next authentication method: password

не глядя в конфиги, твой ssh хочет dsa ключи, так сделай ему их! 😉
у тебя же сейчас rsa.

Can’t get SSH public key authentication to work [closed]

This question does not appear to be about server, networking, or related infrastructure administration within the scope defined in the help center.

My server is running CentOS 5.3. I’m on a Mac running Leopard. I don’t know which is responsible for this:

I can log on to my server just fine via password authentication. I’ve gone through all of the steps for setting up PKA (as described at http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-ssh-beyondshell.html), but when I use SSH, it refuses to even attempt publickey verification. Using the command

followed by a prompt for my password. If I try to force the issue with

So, even though the server says it accepts the publickey authentication method, and my SSH client insists on it, I’m rebutted. (Note the conspicuous absence of an «Offering public key:» line above.) Any suggestions?

12 Answers 12

Check that your Centos machine has:

and ensure that you have proper permission on the centos machine’s

should do the trick.

/ if it isn’t so already.

1- check your /etc/ssh/sshd_config, ensure you have

2- check the secure log from remote machine, look-up the detail sshd daemon error log. e.g. in my Ubuntu

Then check the ownership and modes for directory /home/xxx, maybe you need run this

Double check that your permissions are correct and file structure (specifically spelling) are correct, for both local and remote machines. The URL you refer to states them all, but it’s worth checking that what you have matches. Normally permissions will throw a relevant error though.

Устранение неполадок 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»

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

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

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

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

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

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

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

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

Если вы не можете восстановить доступ к консоли, это может указывать на проблемы с файловой системой или конфигурацией в подсистеме 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 должен принадлежать текущему аккаунту.

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

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

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

Если вы забыли, какой закрытый ключ соответствует тому или иному открытому ключу, инструменты 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

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

Still getting a password prompt with ssh with public key authentication?

I tried everything mentioned in this solution Why am I still getting a password prompt with ssh with public key authentication?, but still getting prompt for password.

Remote machine file permission:

Content of id_rsa.pub of my local machine is there in the Remote machine

Content of /etc/ssh/sshd_config is same in both of the machine.

What might be the issue?

EDIT

Looks like file permission issue:

3 Answers 3

as noted in the post you linked in your question, where the accepted answer reads in part «Your home directory

/.ssh directory and the

/.ssh/authorized_keys file on the remote machine must be writable only by you»

You also don’t post the permissions on your home directory in the question; ensure that those are also not group- or other-writable.

I had the exact same problem on two servers: a Linux running Debian stretch and on a NAS (Synology DS715)

it turned out that in both cases, the home directory permissions on the server were wrong

the auth.log on the server was very helpful

Authentication refused: bad ownership or modes for directory /home/cyril

on the Linux, it had the write/group bit on (drwxrwxr—x), so I had to remove at least the write on group (chmod g-w

/) and then it worked

on the Synology, for whatever reason, there was a sticky bit

drwx—x—x+ 4 toto users 4096 Jan 6 12:11 /var/services/homes/toto

I had to change it with

and I could then connect without a password