Не удается войти через удаленный SSH с правильным паролем

Question

На сервере cPanel, где вчера работал SSH, я неожиданно не могу войти через SSH. Я получаю «Доступ запрещен».

Я проверил, что логины с паролями включены в /etc/ssh/sshd_config и они есть. Я попытался войти в систему как root через KVM, затем SSH'ing к localhost , все работает.

Я перепробовал несколько учетных записей, даже создав новую учетную запись, но она не будет работать, и я уверен, что пароли верны, потому что я несколько раз сбрасывал их и даже копировал их в Putty, не говоря уже о том, что они работают через KVM.

Я не знаю ничего, что могло бы изменить это в одночасье.

Я также проверил sshd_config для директив AllowUser которые позволяют вам ограничить доступ к определенному IP, но он не имеет никакого.

И еще один момент, я только что проверил его на 4G моего телефона, и он работает там, но не на моем DSL.

В прошлом соединение с моим DSL было медленным и поддельным для моего сервера. Даже после переезда на другой хост в другой стране. В то время любой другой сайт, который я пробую, работает нормально. Не уверен, если это уместно.

Вот вывод команды ssh -v с использованием SSH Git для Windows.

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

В прошлом соединение с моим DSL было медленным и поддельным для моего сервера. Даже после переезда на другой хост в другой стране. В то время любой другой сайт, который я пробую, работает нормально. Не уверен, если это уместно.

Основываясь на результатах отладки ssh -v вы показываете - и ваш комментарий выше, который я считаю уместным - я бы порекомендовал настроить sshd_config на вашем сервере следующим образом; обратите внимание, что мне нравится использовать nano но вы можете свободно использовать любой текстовый редактор, который вы предпочитаете.

Сначала откройте файл ssh_config следующим образом:

sudo nano /etc/ssh/sshd_config

Должна быть область конфигурации под названием «Опции GSSAPI», которая выглядит следующим образом:

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

Измените это, чтобы раскомментировать строку, которая гласит «GSSAPIAuthentication no»:

# GSSAPI options
GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

Наконец, сохраните этот файл и перезапустите демон сервера SSH следующим образом. Чтобы перезапустить SSH в системе на базе RedHat/CentOS, сделайте следующее:

sudo service sshd restart

Чтобы перезапустить SSH в системе на основе Debian/Ubuntu, сделайте следующее:

sudo service ssh restart

Теперь попробуйте войти снова. Я все еще рекомендую ssh -v для целей отладки, но я верю, что это прояснит ситуацию.

Answer 2

Я переустановил пакет openssh-server , и, похоже, пока он работает. Файл sshd_config не изменился по сравнению с тем, как он был у меня последний раз, так что это очень странно.