Слишком много сбоев аутентификации для *имя пользователя*

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

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

Для предотвращения предложения неактуальных ключей, вы должны явно указать это в каждой записи хоста в файле ~/.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/

Note: параметр ‘IdentitiesOnly yes’ должен быть между quotes.

или

&00001.

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

ssh -o PubkeyAuthentication=no username@hostname.com

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

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

Я добавил в ~/.ssh/config следующее:

Host *
IdentitiesOnly yes

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

Если вы получите следующую ошибку 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

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

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

ssh -o PreferredAuthentications=password user@example.com

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

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

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

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

$ chmod 750 ~;chmod 700 ~/.ssh

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

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

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

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

• Добавить -v, чтобы увидеть, если это так (вы используете слишком много идентификаторов).

• Список добавленных идентификаторов по ssh-add -l.

• Удалить неудачную идентификацию с агента по: ssh-add -d.

• Вы также можете удалить все идентификационные данные по ssh-add -D и заново добавить только нужную.

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

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

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

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

После того, как я сделал то, что предложил “John T”, я получил эту ошибку:

Разрешение отказано (publickey).

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

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

Сначала убедитесь, что пользователь находится в списке:

vim /etc/passwd