☰

尽管使用了正确的凭据，SSH 访问仍被拒绝

tag-icon • tag-icon ssh centos5
尽管使用了正确的凭据，SSH 访问仍被拒绝

我有一台远程 CentOS 服务器，我可以通过 SSH 访问它。今天，当我尝试通过 SSH 登录时，尽管我使用了正确的凭据，但还是被拒绝访问。我有 plesk 9 访问权限，因此重置了管理员密码，并尝试使用该密码进行 SSH，但无济于事。我甚至创建了一个具有 SSH 访问权限的新用户，并尝试以该用户的身份登录，但再次失败，访问被拒绝。我已经重新启动了。

有人能提供一些建议吗？除了 Web 域之外，Plesk 中没有其他文件管理器，所以我无法获取任何系统文件来查看发生了什么。

任何建议都值得赞赏。

编辑-------------Iain 要求的输出

OpenSSH_4.7p1 Debian-8ubuntu1.2, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to XXXXX [XXXXX] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1.2
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-g                                                                     roup-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1                                                                     28,arcfour256,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-c                                                                     tr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1                                                                     28,arcfour256,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-c                                                                     tr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160                                                                     ,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160                                                                     ,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-gro                                                                     up14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1                                                                     28,arcfour256,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-c                                                                     tr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1                                                                     28,arcfour256,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-c                                                                     tr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open                                                                     ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open                                                                     ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_setup: found hmac-md5
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
debug2: dh_gen_key: priv key bits set: 122/256
debug2: bits set: 507/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
debug2: no key of type 0 for host XXXXX
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts2
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts2
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
debug2: no key of type 2 for host XXXXX
The authenticity of host 'XXXXX (XXXXX)' can                                                                     't be established.
RSA key fingerprint is da:23:25:e5:e7:11:7f:73:f3:d2:be:a4:f8:b9:a7:21.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'XXXXX' (RSA) to the list                                                                      of known hosts.
debug2: bits set: 491/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /root/.ssh/identity ((nil))
debug2: key: /root/.ssh/id_rsa ((nil))
debug2: key: /root/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred gssapi-keyex,gssapi-with-mic,gssapi,publickey,keyboard-interac                                                                     tive,password
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: gssapi,publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
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


debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug3: no such identity: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug3: no such identity: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
root@XXXXX's password:
debug3: packet_send2: adding 48 (len 62 padlen 18 extra_pad 64)
debug2: we sent a password packet, wait for reply
Connection closed by XXXXX

答案1

这几乎让我想起了我曾经见过的一种情况，即空间不足并且无法分叉进程等。如果空间不是问题，那么您可能需要查看您的帐户是否被锁定。

如果您可以运行远程命令但看不到输出，则应尝试将输出通过管道传输到邮件程序以向您发送详细信息。例如：cat /etc/ssh/sshd_config | mail -s ssh_config [email protected]

答案2

有一个非常您的 sshd_config 很可能具有以下设置：

PermitRootLogin without-password

这意味着，Root 只能使用密钥进行身份验证。如果您从未提供过密钥，则很有可能需要请求数据中心将设备置于单用户模式并编辑该文件以允许您进入。

之后，制作私钥/公钥对并在服务器上获取您的公钥，以便您可以更安全地进行身份验证。

答案3

将 AllowUsers 检入 /etc/ssh/sshd_config。

答案4

除了已经给出的答案之外，特别是 Tim 关于 root 帐户特定设置的建议，让我添加几行关于快速诊断 ssh 连接问题的一般方法的基础知识。

在客户端上添加详细选项

ssh -vvv me@node

一个 v 表示详细，两个 v 表示更详细等等...

如果这还不够，在服务器上，如果您是唯一的用户（或者在凌晨 3 点 ;-) 停止 sshd 守护程序并使用完整的调试标志运行它。

sshd -ddd

同样，一个 d 代表调试（简洁），2 代表更多调试，等等...当公钥被交换时，这通常指向文件/文件夹权限问题。

相关内容