Não é possível fazer login através do SSH remoto com a senha correta

Question

Em um servidor cPanel, onde o SSH funcionou ontem, de repente, não consigo fazer login com o SSH. Eu recebo "Acesso negado".

Eu verifiquei se logins com senhas estão habilitados em /etc/ssh/sshd_config e eles estão. Tentei fazer o login como root por meio do KVM e depois do SSH para localhost , funciona.

Eu tentei várias contas, até mesmo criando uma nova conta, mas não funciona e tenho certeza de que as senhas estão corretas, porque eu as redefinii várias vezes e até copiei-as em Putty, para não mencionar eles trabalham via KVM.

Não sei de nada que tenha acontecido que pudesse causar alterações durante a noite.

Também verifiquei as diretivas sshd_config para AllowUser , que permitem restringir o acesso a um determinado IP, mas ele não tem nenhum.

E outro ponto, eu só verifiquei no 4G do meu telefone e ele funciona lá, só que não no meu DSL.

No passado, a conexão na minha DSL era lenta e falsa para o meu servidor. Mesmo depois de se mudar para um host diferente em um país diferente. Nesses momentos, todos os outros sites que eu tento funcionam bem. Não tenho certeza se for relevante.

Aqui está a saída de ssh -v usando o Git for Windows 'SSH.

OpenSSH_6.6.1, OpenSSL 1.0.1i 6 Aug 2014
debug1: Connecting to <host> [<IP>] port 22.
debug1: Connection established.
debug1: identity file /.ssh/id_rsa type -1
debug1: identity file /.ssh/id_rsa-cert type -1
debug1: identity file /.ssh/id_dsa type -1
debug1: identity file /.ssh/id_dsa-cert type -1
debug1: identity file /.ssh/id_ecdsa type -1
debug1: identity file /.ssh/id_ecdsa-cert type -1
debug1: identity file /.ssh/id_ed25519 type -1
debug1: identity file /.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<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: Server host key: RSA <key>
The authenticity of host '<host> (<IP>)' can't be established.
RSA key fingerprint is <key>.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '<host>,<IP>' (RSA) to the list of known hosts.
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Trying private key: /.ssh/id_rsa
debug1: Trying private key: /.ssh/id_dsa
debug1: Trying private key: /.ssh/id_ecdsa
debug1: Trying private key: /.ssh/id_ed25519
debug1: Next authentication method: password
<user>@<host>'s password:
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
Permission denied, please try again.
<user>@<host>'s password:

    

Answer 1

In the past the connection on my DSL has been slow and spurious to my server. Even after moving to a different host in a different country. At those times every other site I try works fine. Not sure if relevant.

Com base na saída de depuração de ssh -v que você está mostrando, e seu comentário acima do que considero relevante, recomendo que você ajuste o sshd_config em seu servidor dessa maneira; note que eu gosto de usar nano , mas fique à vontade para usar qualquer editor de texto que você preferir usar.

Primeiro, abra o arquivo ssh_config da seguinte forma:

sudo nano /etc/ssh/sshd_config

Deve haver uma área de configuração chamada "opções GSSAPI" que se parece com isso:

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

Altere isso para descomentar a linha que diz “GSSAPIAuthentication no”:

# GSSAPI options
GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

Por fim, salve esse arquivo e reinicie o daemon do servidor SSH desta forma. Para reiniciar o SSH em um sistema baseado em RedHat / CentOS, faça o seguinte:

sudo service sshd restart

Para reiniciar o SSH em um sistema baseado em Debian / Ubuntu, faça o seguinte:

sudo service ssh restart

Agora tente fazer login novamente. Eu ainda recomendaria ssh -v para fins de depuração, mas acredito que isso vai esclarecer as coisas.

    

Answer 2

Eu reinstalei o pacote openssh-server e parece ter funcionado, por enquanto. O arquivo sshd_config não mudou desde a última vez, então é muito estranho.