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

13

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

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

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

ssh -l some-user IP

Я получаю сообщение об ошибке:

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

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

debug1: Offering RSA public key: [email protected]
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: [email protected]
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: [email protected]
debug1: Authentications that can continue: publickey,password
debug1: Offering DSA public key: [email protected]
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: [email protected]
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: [email protected]
Received disconnect from ##.##.##.##: 2: Too many authentication failures for root
    
задан Alexis Wilke 11.02.2014 в 17:58
источник

3 ответа

17

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

ssh -o PubkeyAuthentication=no [email protected]
    
ответ дан Klaus-Dieter Warzecha 11.02.2014 в 18:21
источник
16

Скорее всего, вы имеете более одного 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. Всегда создавайте keypair на вашем устройстве и передавайте только открытый ключ. Таким образом, даже если сервер взломан, ваш личный ключ по-прежнему безопасен и безопасен. Это может произойти неожиданными способами - например, с помощью резервных копий.
  3. Если кто-то другой управляет сервером, вы должны предоставить для них открытый ключ; они должны не генерировать keypair и отправлять вам секретный ключ. Таким образом, они не могут олицетворять вас своим ключом (конечно, обычно они могут делать все, что захотят). Кроме того, с открытым ключом должна быть защищена только целостность (т. Е. Кто-то не изменил открытый ключ); с закрытым ключом, конфиденциальность (т. е. никто другой не получил ключ) должен быть сохранен, и невозможно быть абсолютно уверенным, что он не был скомпрометирован.
  4. Компрометация сервера не ставит под угрозу другие серверы, даже если вы используете один и тот же закрытый ключ для подключения к нескольким серверам (за исключением того, что вы передали этот закрытый ключ на сервер. Никогда не делайте этого.)
  5. В любом случае, компрометация вашей рабочей станции будет разоблачать ваши личные ключи. Наличие нескольких закрытых ключей не помогает с этим (кроме случаев, когда у вас разные, сильные фразы, и не все они доступны для злоумышленника).

Есть несколько исключений из этого, но не слишком много.

    
ответ дан Olli 11.02.2014 в 18:25
4

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

    
ответ дан Marc 11.02.2014 в 18:03