SSH: В доступе отказано (publickey, gssapi-with-mic, пароль)

17

================================================== ==================

ОБНОВЛЕНИЕ: Оказалось, что конфигурация sshd не host2позволяет вводить пароль. Благодаря людям ответили на это.

================================================== ==================

Сценарий: работа с компанией для моего проекта колледжа. Мне нужно использовать PuTTy для SSH в host1первую очередь, а оттуда SSH в host2(см. Ниже). Мне дали имя пользователя и пароль на host2.

У меня нет доступа к host2 вообще, поэтому я не знаю его sshd_config.

Вот что случилось, когда я пытался войти в SSH host2из host1:

ff@host1:~$ ssh -v host2
OpenSSH_5.1p1 Debian-5, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /home/ff/.ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to host2 [192.*.*.*] port 22.
debug1: Connection established.
debug1: identity file /home/ff/.ssh/identity type -1
debug1: identity file /home/ff/.ssh/id_rsa type -1
debug1: identity file /home/ff/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-5
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'sd01' is known and matches the RSA host key.
debug1: Found key in /home/ff/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Next authentication method: publickey
debug1: Trying private key: /home/ff/.ssh/identity
debug1: Trying private key: /home/ff/.ssh/id_rsa
debug1: Trying private key: /home/ff/.ssh/id_dsa
debug1: Next authentication method: password
ff@sd01's password:
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
Permission denied, please try again.
ff@sd01's password:
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
Permission denied, please try again.
ff@sd01's password:
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-with-mic,password).

и мой /home/ff/.ssh/config:

Host *
#   ForwardAgent no
#   ForwardX11 no
#   ForwardX11Trusted yes
#   RhostsRSAAuthentication no
#   RSAAuthentication yes
#   HostbasedAuthentication no
    BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/identity
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   Port 22
#   Protocol 2,1
#   AuthorizedKeysFile .ssh/authorized_keys
#   Cipher 3des
#   Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials no

Интересно, что я могу сделать, прежде чем пойти в компанию?

корнишон
источник
правильно ли имя пользователя "ff" на хосте 2?
etagenklo
@etagenklo да, это то, что мне дали.
корнишон
Вы должны спросить администратора host2.
Jornane
Я была такая же проблема. Я думаю, причина в том, что я что-то неправильно настроил в папке $ HOME / .ssh пользователя. После mv $ HOME / .ssh $ HOME / .ssh.hide я мог войти, используя пароль ssh
JackBauer35

Ответы:

8

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

kasperd
источник
2
Как будто ты можешь быть еще глупее, у меня есть правильные пароли. А потом вы помните различные раскладки клавиатуры. Спасибо за то, что заставили меня вернуться :)
skyw00lker
@ skyw00lker Вот почему я лично использую буквенно-цифровые пароли.
Касперд
7

Первый

 chmod 700 .ssh

а потом :

 chmod 600 .ssh/authorized_keys

и проверить это:

restorecon -r -vv .ssh/authorized_keys
Али Земани
источник
2
Это работает. Спасибо!
NightKnight на Cloudinsidr.com
2

В моем случае это было вызвано шифрованием домашнего каталога. Я изменил расположение ключей SSH, и это решило проблему: (Web Archive copy) http://tweaktheserver.com/ssh-cant-connect-authentications-that-can-continue-publickeygssapi-keyexgssapi-with-micpassword/

user173141
источник
2
Пожалуйста, добавьте суть решения в ваш ответ. Ответы только на ссылки подвержены ссылочной гнили.
Охотник на оленей
Хотя это может теоретически ответить на вопрос, было бы предпочтительным включить сюда основные части ответа и предоставить ссылку для справки.
Марк Хендерсон
спасибо за ваши предложения. Я понимаю, что рабочая ссылка может стать «ошибкой 404» в будущем, и важно упомянуть пункты в самом ответе. Я также отредактировал свой ответ.
user173141
@DeerHunter был пророческим: связь сгнила
Riet
@Riet - редактировать предлагается. Еще не все потеряно. Тем временем вы можете посетить захваченную копию страницы .
Охотник на оленей
1

Аутентификация GSSAPI, кажется, включена в клиенте, но она терпит неудачу и возвращается к аутентификации по паролю. Если вы не можете войти с предоставленными логином и паролем, единственное разумное, что вам нужно сделать, - это связаться с кем-то, кто отвечает за управление сервером («компания»).

phoops
источник
1

У меня была та же проблема, но проблема для меня заключалась в том, что конфигурация операционной системы по умолчанию (CentOS 7) заключалась в шифровании пользовательского каталога, чтобы authorized_keysпомещенный файл ~/.ssh/не работал. Решение пришло отсюда, но в основном:

  1. в /etc/ssh/sshd_configсвойстве AuthorizedKeysFile установить что-то вне каталога пользователя ( /etc/ssh/authorized_keys)
  2. перезапустите службу sshd
Анатолий гейфман
источник
0

попробуйте:
ssh сервер -p порт -o PreferredAuthentications = publickey

Александр Владимирович
источник
пожалуйста, будьте немного подробнее о том, почему ОП должен использовать вашу команду и что она делает. Использование code stylingкоманд также считается хорошим стилем:``
Филипп-Зьян К Ли - Стокманн
-1

Мне нужно было дать /home/ec2-userразрешения 700:

chmod -R 700 /home/ec2-user/
duhaime
источник
Зачем голосовать за удаление?
Духайме
-1

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

Введите, ls -laчтобы увидеть, к какому пользователю принадлежит ваш ключ.

Вы можете изменить владельца:

sudo chown ubuntu:root myKey  //If you are using ubuntu.

Также убедитесь:

  • Вы используете правильный .pem ключ, если используете Linux (замазка отличается)
  • Вы установили правильные разрешения ключа: sudo chmod 400 mykey.pem
  • Вы используете правильное имя пользователя: ssh -i mykey user@instanceip
JPaulino
источник
-2

Можешь попробовать

ssh server -l user -o "PubkeyAuthentication=no"

ИЛИ в / etc / ssh / sshd_config, добавьте / измените свойство

PermitRootLogin yes
Адриано
источник
ssh server -l user -o "PubkeyAuthentication=no" равный ssh user@server -o "PubkeyAuthentication=no"
Адриано
-2

$ ssh Vagrant@192.168.33.11 -i .vagrant / machines / default / virtualbox / private_key

Это сработало для меня

Картик Бр
источник