☰

ssh никогда не запрашивает пароль

tag-icon • tag-icon ssh password
ssh никогда не запрашивает пароль

Почему-то мой SSH никогда не хочет спрашивать у меня пароль.

Итак, я настроил VPS на каком-то случайном сервере где-то в мире и хочу подключиться к нему по SSH.

Я могу настроить ключ, но когда я делаю это:

ssh -l some-user IP

Я получаю ошибку:

Received disconnect from ##.##.##.##: 2: Too many authentication failures for some-user

Когда я смотрю на подробности, я вижу, что пароль — это один из вариантов:

debug1: Offering RSA public key: some-user@computer
debug1: Authentications that can continue: publickey,password

Но SSH никогда не спрашивает у меня пароль. Он пытается 5 раз, как я подозреваю, с помощью метода publickey, а затем терпит неудачу. Почему бы ssh не попробовать с паролем?!

На всякий случай, мой файл ssh_config имеет:

PasswordAuthentication yes

Полный журнал

ssh -v -l root ##.##.##.##
OpenSSH_6.1p1 Debian-4, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /home/someuser/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to ##.##.##.## [##.##.##.##] port 22.
debug1: Connection established.
debug1: identity file /home/someuser/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/someuser/.ssh/id_rsa-cert type -1
debug1: identity file /home/someuser/.ssh/id_dsa type -1
debug1: identity file /home/someuser/.ssh/id_dsa-cert type -1
debug1: identity file /home/someuser/.ssh/id_ecdsa type -1
debug1: identity file /home/someuser/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.2p2 Ubuntu-6
debug1: match: OpenSSH_6.2p2 Ubuntu-6 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.1p1 Debian-4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA XX:XX:...:XX:XX
debug1: Host '##.##.##.##' is known and matches the ECDSA host key.
debug1: Found key in /home/someuser/.ssh/known_hosts:38
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/someuser/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: someuser@computer
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: someuser@computer
debug1: Authentications that can continue: publickey,password
debug1: Offering DSA public key: someuser@computer
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: someuser@computer
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: someuser@computer
Received disconnect from ##.##.##.##: 2: Too many authentication failures for root

решение1

Попробуйте войти в систему с отключенной аутентификацией с открытым ключом, используя

ssh -o PubkeyAuthentication=no root@newserver

решение2

identityfileСкорее всего, в вашем файле более одной строки .ssh/config.

Даже если у вас есть identityfileпод hostконфигурацией, он применяется глобально. Это означает, что он sshпробует каждый файл идентификации (т. е. открытый ключ) на каждом хосте, прежде чем запросит пароль с сервера.

Вы можете это исправить

  1. Удаление всех identityfileстрок, кроме одной, или
  2. Добавление PubkeyAuthentication noк .ssh/config, или
  3. Выполнение ssh с -o PubkeyAuthentication=noпараметром.

От man 5 ssh_config:

PubkeyAuthentication
    Specifies whether to try public key authentication.  The argument to this
    keyword must be “yes” or “no”.  The default is “yes”.  This option applies 
    to protocol version 2 only.

IdentityFile
    ...
    It is possible to have multiple identity files specified in configuration
    files; all these identities will be tried in sequence.  Multiple 
    IdentityFile directives will add to the list of identities tried (this 
    behaviour differs from that of other configuration directives).

Некоторые общие инструкции по работе с открытыми ключами:

  1. В общем случае вам следует иметь только один закрытый ключ на клиента (рабочую станцию) и поместить соответствующий открытый ключ на все серверы, к которым клиент должен иметь доступ. Другими словами, разделяйте открытый ключ между серверами и никогда не используйте один и тот же закрытый ключ на нескольких устройствах.
  2. Всегда генерируйте пару ключей на вашем устройстве и передавайте только открытый ключ. Таким образом, даже если сервер будет скомпрометирован, ваш закрытый ключ останется в безопасности. Это может произойти неожиданными способами — например, через резервное копирование.
  3. Если кто-то другой администрирует сервер,тыдолжны предоставить им открытый ключ; они должнынетсгенерировать пару ключей и отправить вам закрытый ключ. Таким образом, они не смогут выдать себя за вас с вашим ключом (конечно, обычно они могут делать все, что захотят). Кроме того, с открытым ключом должна быть защищена только целостность (т. е. никто не изменил открытый ключ); с закрытым ключом должна быть сохранена конфиденциальность (т. е. никто другой не получил ключ), и невозможно быть абсолютно уверенным, что он не был скомпрометирован.
  4. Взлом сервера не ставит под угрозу другие серверы, даже если вы используете один и тот же закрытый ключ для подключения к нескольким серверам (за исключением случаев, когда вы передали этот закрытый ключ на сервер. Никогда так не делайте).
  5. Взлом вашей рабочей станции в любом случае раскроет ваши закрытые ключи. Наличие нескольких закрытых ключей не поможет в этом (за исключением случаев, когда у вас есть разные, надежные парольные фразы, и не все из них доступны злоумышленнику).

Есть некоторые исключения, но их не так уж много.

решение3

Ваш локальный ssh ​​не должен спрашивать у вас пароль, а вот ssh-сервер на другом конце должен. Вероятно, сервер настроен так, чтобы не принимать аутентификацию по паролю. Мой тоже не будет спрашивать у вас пароль.

решение4

Я нашел еще одну причину. У меня было:

Host *
   PreferredAuthentications publickey

в ~/.ssh/config(скопировано у другого пользователя, думая, что это "предпочтение"). На самом деле PreferredAuthenticationsуказывает "разрешенные" методы и порядок.

Либо удалите PreferredAuthenticationsстроку, либо добавьтеpassword

Host *
   PreferredAuthentications publickey,password

Примечание: после запятой пробел не ставится!

Связанный контент