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


256

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

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

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

Получено отключение от 111.222.33.44: 2: слишком много ошибок аутентификации для имени пользователя
rsync: соединение неожиданно закрыто (получено 0 байт) [отправитель]
Ошибка rsync: необъяснимая ошибка (код 255) в io.c (601) [отправитель = 3.0.7]

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

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

Какие-нибудь советы? Возможно, это что-то на стороне клиента, а не на стороне сервера.


В моем случае при генерации ключа произошла ошибка. Я сгенерировал ключ и не упомянул адрес источника и использовал имя пользователя в конце ключа.
репортер

Ответы:


416

Обычно это вызвано непреднамеренным предложением нескольких ключей 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/

5
мне не ясно, где поставить эту строку. На сервере, к которому я пытаюсь войти, .ssh / config имеет информацию только для других серверов. Вы имеете в виду, что это должно быть в файле .ssh / config на компьютере, с которого я пытаюсь выполнить ssh? Если это так, то это неясно, потому что ваш ответ гласит: «Как только вы снова
войдете в

2
Я должен поставить опцию в двойные кавычки, например так:ssh -i some_id_rsa -o "IdentitiesOnly yes" them@there:/path/
knb

1
Пользователи Windows, на которых запущен PAGENT (Putty Agent), убедитесь, что загружены только те ключи, которые вам нужны. Я столкнулся с этой проблемой после случайной загрузки ВСЕХ моих закрытых ключей.
Крис Раско

2
Остается вопрос: почему ssh«предлагать несколько ключей» (что-нибудь под ~/.ssh), даже если правило для хоста имеет явную IdentityFile /path/to/private_key_fileнастройку. Не должен ли этот явно указанный ключ (по крайней мере) предлагаться первым? Не является ли это ошибкой / ошибкой в ​​клиенте openssh?
Ариэль

2
Но не должен ли он использовать ключ, указанный в IdentityFileопции? Например, без IdentitiesOnlyопции он пытается использовать мой githubключ, когда я пытаюсь ssh gitlab.com. Это не имеет никакого смысла.
Юлиан Онофрей

188

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

ssh -o PubkeyAuthentication=no username@hostname.com

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

Ссылка


3
+1, хотелось бы дать тебе больше. Raspberry Pi - это единственное устройство, в которое я вхожу без открытого ключа. Было
получено

1
И использовать это с rsync:rsync -av -e 'ssh -o PubkeyAuthentication=no' 'user@host.com:~/remote_file' 'local_file'
Сиро Сантилли 新疆 改造 中心 法轮功 六四 事件

1
Вы также можете создать псевдоним, чтобы сделать его еще быстрее для аутентификации пароля. псевдоним sshp = 'ssh -o PubkeyAuthentication = no'
dhempler

26

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


В вашей последней строке у вас есть файлфирмы /home/YOU/.ssh/foo, но это должен быть файл идентификации (не на букву f)
Нин,

7

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

Host *
IdentitiesOnly yes

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


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

Это было именно то, что происходило со мной! Большое спасибо за объяснение;)
El Ninja Trepador

6

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

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

ssh -o PreferredAuthentications=password user@example.com

3

Говоря @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 с открытым ключом


2

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

Я был бы осторожен с этим без предупреждения. Разрешения ключей SSH обычно ограничены 400 для некоторых ключей, в частности для AWS. Попытка установить их выше приведет к тому, что ключ не будет принят, и это может заблокировать вашу учетную запись AWS.
Майкл Райан Сойло,

1

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

$ chmod 750 ~;chmod 700 ~/.ssh

0

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

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

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

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


0

У меня был открытый ключ .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

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

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

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

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

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

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


-1

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

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

vim /etc/passwd
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.