SSH: Permissão negada (publickey, gssapi-with-mic, password)

Question

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

ATUALIZAÇÃO: Acontece que a configuração do sshd em host2 não permite a senha entrar. Graças às pessoas responderam isso.

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

cenário: Trabalhando com uma empresa para o meu projeto de faculdade. Eu preciso usar PuTTy para SSH em host1 primeiro, e de lá SSH em host2 (veja abaixo). Recebi um nome de usuário e senha no host2.

Eu não tenho acesso ao host2, então não tenho conhecimento do sshd_config .

Foi o que aconteceu quando eu estava tentando SSH em host2 de 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).

e meu /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

Eu me pergunto se há algo que eu possa fazer antes de ir para a empresa.

    

Answer 1

O nome de usuário e a senha que você está tentando não são aceitos pelo host. Isso significa que você está se conectando ao servidor errado ou o nome de usuário ou a senha estão incorretos. Você deve pedir ao administrador para verificar os registros em host2 , que devem informar qual dos três é o caso.

    

Answer 2

Primeiro

 chmod 700 .ssh

e depois:

 chmod 600 .ssh/authorized_keys

e teste isso:

restorecon -r -vv .ssh/authorized_keys

    

Answer 3

No meu caso, isso foi causado pela criptografia do diretório inicial. Alterei a localização das chaves ssh e resolvi o problema: (cópia do arquivo da Web) link

    

Answer 4

A autenticação GSSAPI parece estar ativada no cliente, mas falha e retorna à autenticação de senha. Se você não conseguir logar com login e senha fornecidos, então a única coisa sensata a fazer é entrar em contato com alguém responsável pelo gerenciamento do servidor (a "empresa").

    

Answer 5

Eu tive o mesmo problema, mas o problema para mim era que a configuração padrão do sistema operacional (CentOS 7) era criptografar o diretório do usuário, para que o arquivo authorized_keys colocado em ~/.ssh/ não funcionasse. A solução veio de aqui mas basicamente:

1. em /etc/ssh/sshd_config defina a propriedade AuthorizedKeysFile como algo fora do diretório do usuário ( /etc/ssh/authorized_keys )
2. reinicie o serviço sshd

Answer 6

Você pode tentar

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

OR em / etc / ssh / sshd_config, adicione / modifique a propriedade

PermitRootLogin yes

    

Answer 7

Eu precisava fornecer /home/ec2-user permissions 700:

chmod -R 700 /home/ec2-user/

    

Answer 8

Deixe-me acrescentar que você deve garantir que a chave pertença ao seu usuário.

Digite ls -la para ver a qual usuário sua chave pertence.

Você pode alterar a propriedade:

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

Assegure-se também:

• Você está usando a chave .pem correta se estiver usando o linux (o putty é diferente)
• Você definiu as permissões de chave corretas: sudo chmod 400 mykey.pem
• Você está usando o nome de usuário correto: ssh -i mykey user@instanceip