================================================== ==================
ОБНОВЛЕНИЕ: Оказалось конфиг 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
Интересно, могу ли я что-нибудь сделать, прежде чем пойти в компанию.
Имя пользователя и пароль, которые вы пытаетесь использовать, не принимаются хостом. Это означает, что либо вы подключаетесь не к тому серверу, либо имя пользователя или пароль неверны. Вы должны попросить администратора проверить логи на host2, это должно сказать вам, какой из трех случаев.
Первый
chmod 700 .ssh
а потом :
chmod 600 .ssh/authorized_keys
и проверьте это:
restorecon -r -vv .ssh/authorized_keys
В моем случае это было вызвано шифрованием домашнего каталога. Я изменил расположение ключей ssh, и проблема была решена: (копия веб-архива) http://tweaktheserver.com/ssh-cant-connect-authentications-that-can-continue-publickeygssapi-keyexgssapi-with-micpassword/
Кажется, что на клиенте включена аутентификация GSSAPI, но она не работает и возвращается к аутентификации по паролю. Если вы не можете войти в систему с предоставленными логином и паролем, то единственное, что можно сделать, это связаться с кем-то, кто отвечает за управление сервером («компания»).
У меня была та же проблема, но для меня проблема заключалась в том, что конфигурация операционной системы по умолчанию (CentOS 7) заключалась в шифровании каталога пользователя, так что authorized_keys файл помещен в ~/.ssh/ не будет работать. Решение пришло из Вот но в основном:
/etc/ssh/sshd_config установите для свойства AuthorizedKeysFile значение вне каталога пользователя (/etc/ssh/authorized_keys)Мне нужно было дать /home/ec2-user разрешения 700:
chmod -R 700 /home/ec2-user/
Позвольте мне добавить, что вы должны убедиться, что ключ принадлежит вашему пользователю.
Тип ls -la чтобы узнать, какому пользователю принадлежит ваш ключ.
Вы можете сменить владельца:
sudo chown ubuntu:root myKey //If you are using ubuntu.
Также убедитесь:
.pem ключ при использовании linux (шпатлевка другая)sudo chmod 400 mykey.pemssh -i mykey user@instanceipпытаться:
ssh-сервер -p порт -o PreferredAuthentication = publickey
Можешь попробовать
ssh server -l user -o "PubkeyAuthentication=no"
ИЛИ в / etc / ssh / sshd_config добавьте / измените свойство
PermitRootLogin yes
$ ssh Vagrant@192.168.33.11 -i .vagrant / machines / default / virtualbox / private_key
Это сработало для меня