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

У меня есть учетная запись 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, и у меня было меньше проблем, чем с этими парнями.

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

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

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

ssh -o PubkeyAuthentication=no username@hostname.com

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

Ссылка

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

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

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

ssh -o PreferredAuthentications=password user@example.com

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

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

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

$ chmod 750 ~;chmod 700 ~/.ssh

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

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

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

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

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

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

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

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

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

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

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

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

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

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

vim /etc/passwd