it-swarm-ru.tech

Слишком много ошибок аутентификации для * username *

У меня есть учетная запись hostgator с включенным доступом ssh и при попытке загрузить сгенерированный файл ключа .pub с помощью этой команды:

 rsync -av -e "ssh -p2222" /home/user/.ssh/key.pub [email protected]: .ssh/authorized_keys 

Я продолжаю получать:

[.__ (код 255) на io.c (601) [отправитель = 3.0.7] 

Ранее я играл с ssh, пока не получил ошибку аутентификации. Но теперь кажется, что счетчик ошибок аутентификации не сбрасывается (ожидание более 12 часов, служба технической поддержки «предполагает», что он сбрасывается через 30 минут - 1 час, и другой парень сказал мне «он сбрасывается каждый раз, когда вы пытаетесь войти с помощью имя пользователя ", боже).

Это сводит меня с ума. Я даже настроил это на пользовательском сервере Slicehost, и у меня было меньше проблем, чем с этими парнями. Любой совет? Возможно, это что-то на стороне клиента, а не на стороне сервера.

248
Gabriel A. Zorrilla

Обычно это вызвано непреднамеренным предложением нескольких ключей ssh ​​серверу. Сервер отклонит любой ключ после того, как было предложено слишком много ключей.

Вы можете убедиться в этом сами, добавив флаг -v к своей команде ssh, чтобы получить подробный вывод. Вы увидите, что предлагается несколько ключей, пока сервер не отклонит соединение, говоря: «Слишком много ошибок аутентификации для [пользователя]». Без подробного режима вы увидите только неоднозначное сообщение «Сброс соединения по пиру».

Чтобы не предлагать нерелевантные ключи, вы должны явно указать это в каждой записи Host в файле ~/.ssh/config (на клиентском компьютере), добавив IdentitiesOnly следующим образом:

Host www.somehost.com
  IdentityFile ~/.ssh/key_for_somehost_rsa
  IdentitiesOnly yes
  Port 22

Если вы используете ssh-agent, это поможет запустить ssh-add -D для очистки идентификаторов.

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

ssh -i some_id_rsa -o 'IdentitiesOnly yes' [email protected]:/path/

Примечание: параметр 'IdentitiesOnly yes' должен быть в кавычках.

или же

ssh -i some_id_rsa -o IdentitiesOnly=yes [email protected]:/path/
406
John T

Я нашел более простой способ сделать это (при использовании аутентификации по паролю):

ssh -o PubkeyAuthentication=no [email protected]

Это вызывает неключевую аутентификацию. Я смог войти в систему сразу.

Ссылка

179
Ben West

Я тоже получил эту ошибку и обнаружил, что это происходит, потому что сервер был настроен на прием до 6 попыток:

/etc/ssh/sshd_config
...
...
#MaxAuthTries 6

В дополнение к настройке IdentitiesOnly yes в вашем файле ~/.ssh/config у вас есть несколько других опций.

  1. Увеличьте MaxAuthTries (на сервере ssh)
  2. удалите некоторые пары ключей, которые вы имеете в своем каталоге ~/.ssh/, и запустите ssh-add -D
  3. явно связать ключ с данным хостом в вашем файле ~/.ssh/config

Вот так:

Host foo
hostname foo.example.com
IdentityFile /home/YOU/.ssh/foo
  1. Вероятно, это не очень хороший способ, поскольку он немного ослабляет ваш ssh-сервер, поскольку теперь он будет принимать больше ключей при данной попытке подключения. Думайте векторы атаки грубой силы здесь.

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

  3. И подход установки IdentitiesOnly, вероятно, является предпочтительным способом решения этой проблемы!

24
slm

Я добавил в ~/.ssh/config это:

Host *
IdentitiesOnly yes

Он включает опцию IdentitiesOnly = yes по умолчанию. Если вам нужно подключиться с закрытым ключом, вы должны указать его с опцией -i

7

Если у вас есть пароль, и вы хотите просто использовать пароль для входа, вот как вы это делаете.

Чтобы использовать ТОЛЬКО аутентификацию по паролю и НЕ использовать открытый ключ, а НЕ использовать вводящее в заблуждение «клавиатурно-интерактивный» (который является надмножеством, включающим пароль), вы можете сделать это из командной строки:

ssh -o PreferredAuthentications=password [email protected]
6
Greg Rundlett

Если вы получаете следующую ошибку SSH:

$ Received disconnect from Host: 2: Too many authentication failures for root

Это может произойти, если у вас (по умолчанию в моей системе) пять или более файлов идентификаторов DSA/RSA, хранящихся в вашем каталоге .ssh, и если в командной строке не указан параметр -i.

Клиент ssh сначала попытается войти в систему, используя каждый идентификатор (закрытый ключ), а затем запросить аутентификацию по паролю. Тем не менее, sshd сбрасывает соединение после пяти неудачных попыток входа в систему (опять-таки по умолчанию может отличаться).

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

Например:

$ ssh -o PubkeyAuthentication=no [email protected]
5
Will Verna

Говоря @David, просто добавьте этот IdentitiesOnly yes в ваш .ssh/config, он делает то же самое, что ssh -o PubkeyAuthentication=no.

После входа удалите .ssh/authorized_keys. Теперь вернитесь на локальный компьютер и введите следующее

cat ~/.ssh/id_rsa.pub | ssh -o PubkeyAuthentication=no [email protected]_ADDR 'cat >> .ssh/authorized_keys'. Это должно снова включить ваш SSH с открытым ключом

3
Alan Dong

Я знаю, что это старый поток, но я просто хотел добавить сюда, что я столкнулся с тем же сообщением об ошибке, но оно было вызвано тем, что владелец папки .ssh является пользователем root, а не пользователь, который использовал ключ. Я исправил проблему, выполнив следующие команды:

Sudo chown -R user:user /home/user/.ssh

Я также удостоверился, что разрешения были правильными для папки .ssh:

Sudo chmod 700 /home/user/.ssh

Файлы в каталоге .ssh должны иметь разрешение 600:

Sudo chmod 600 /home/user/.ssh/authorized_keys
2
Adam

В моем случае проблема была в разрешениях на каталог. Это исправило это для меня:

$ chmod 750 ~;chmod 700 ~/.ssh
1
tbc0

В моем случае это происходило потому, что я использовал имя пользователя «ubuntu», но имя пользователя в этом случае было «ec2-user»

После того, как я сделал то, что предложил «Джон Т», я получил эту ошибку:

В доступе отказано (publickey).

Затем я нашел решение (т.е. изменил имя пользователя на «ec2-user») в этом ответе: https://stackoverflow.com/questions/1454629/aws-ssh-access-permission-denied-publickey-issue

0
Deepak Joy

Слишком много ошибок аутентификации

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

Вот несколько предложений:

  • Добавьте -v, чтобы увидеть, так ли это (вы используете слишком много идентификаторов).
  • Список добавленных идентификаторов по ssh-add -l.
  • Удалите ошибочную идентификацию из агента с помощью: ssh-add -d.
  • Вы также можете удалить все идентификаторы с помощью ssh-add -D и повторно добавить только релевантные.
  • Если у вас есть доступ к SSH-серверу, отметьте опцию MaxAuthTries (см .: man sshd_config ).

    Связанный пост: Какое соединение для ограничения sshd_config 'MaxAuthTries'?

  • Если ничего из этого не помогло, убедитесь, что вы используете правильные учетные данные или файл.

0
kenorb

У меня был открытый ключ в .ssh/authorized_keys2, но сервер был настроен на чтение только .ssh/authorized_keys:

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile .ssh/authorized_keys

После перемещения моего файла в .ssh/authorized_keys я могу успешно войти в систему с моим ключом.

0
Benedikt Köppel