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

Question

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

rsync -av -e "ssh -p2222" /home/user/.ssh/key.pub username@111.222.33.44:.ssh/authorized_keys

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

Received disconnect from 111.222.33.44: 2: Too many authentication failures for username
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(601) [sender=3.0.7]

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

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

Answer 1

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

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

Чтобы не предлагать нерелевантные ключи, вы должны явно указать это в каждой записи хоста в файле ~/.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' them@there:/path/

Примечание: параметр «IdentitiesOnly yes» должен находиться между кавычками.

или же

ssh -i some_id_rsa -o IdentitiesOnly=yes them@there:/path/

Answer 2

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

ssh -o PubkeyAuthentication=no username@hostname.com

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

Ссылка

Answer 3

Я тоже получил эту ошибку и обнаружил, что это происходит, потому что сервер был настроен на прием до 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, вероятно, является предпочтительным способом решения этой проблемы!

Answer 4

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

Host *
IdentitiesOnly yes

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

Answer 5

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

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

ssh -o PreferredAuthentications=password user@example.com

Answer 6

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

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

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

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

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

Например:

$ ssh -o PubkeyAuthentication=no root@host

Answer 7

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

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

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

Answer 8

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

Answer 9

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

$ chmod 750 ~;chmod 700 ~/.ssh

Answer 10

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

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

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

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

Answer 11

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

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

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

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

• Если у вас есть доступ к SSH-серверу, проверьте параметр MaxAuthTries (см. man sshd_config).

  ^{Похожие темы: Что такое подключение к пределу sshd_config «s„MaxAuthTries“?}

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

Answer 12

У меня был открытый ключ в .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 я могу успешно войти в систему с моим ключом.

Answer 13

Это сообщение может появиться, если не введено правильное имя пользователя и пароль.

Сначала проверьте, что пользователь указан в списке:

vim /etc/passwd