linux - CentOS 6.x 中 ssh 的意外行为

Question

我有一个 CentOS 虚拟机作为 ec2 实例运行，我最初将此虚拟机导入到 Amazon(这是我稍后需要导出它的原因)。

我已经启用了使用 ssh key 登录并禁用了密码身份验证，直到昨天它突然开始要求我输入密码，它一直运行良好。我有密码，因此我不会被锁定在虚拟机之外。

我的问题是，我尝试通过 ssh key 登录，但它不起作用，我得到了

Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

我没有调试 sshd 的经验，所以我做了基本测试来查看日志，所以我停止了 sshd 并将其作为守护进程在端口 22 上运行

/usr/sbin/sshd -d -p 22

然后，当我尝试使用 ssh key 连接到虚拟机时，它成功了!我停止了它并启动 sshd 作为服务，我收到了上面相同的“权限被拒绝”消息。

当我启动 sshd 作为守护进程时，我在使用 ssh key 登录时得到了这个(sshd 日志)

debug1: sshd version OpenSSH_5.3p1
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: rexec_argv[2]='-p'
debug1: rexec_argv[3]='22'
Set /proc/self/oom_score_adj from 0 to -1000
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from 46.xx.xx.xx port 60823
debug1: Client protocol version 2.0; client software version OpenSSH_6.2
debug1: match: OpenSSH_6.2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: permanently_set_uid: 74/74
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user root service ssh-connection method none
debug1: attempt 0 failures 0
debug1: PAM: initializing for "root"
debug1: PAM: setting PAM_RHOST to "46.xx.xx.xx"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 1 failures 0
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
debug1: matching key found: file /root/.ssh/authorized_keys, line 1
Found matching RSA key: 01:03:92:98:97:af:7e:2b:45:bd:02:f7:0d:13:45:40
debug1: restore_uid: 0/0
Postponed publickey for root from 46.xx.xx.xx port 60823 ssh2
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 2 failures 0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
debug1: matching key found: file /root/.ssh/authorized_keys, line 1
Found matching RSA key: 01:03:92:98:97:af:7e:2b:45:bd:02:f7:0d:13:45:40
debug1: restore_uid: 0/0
debug1: ssh_rsa_verify: signature correct
debug1: do_pam_account: called
Accepted publickey for root from 46.248.215.245 port 60823 ssh2
debug1: monitor_child_preauth: root has been authenticated by privileged process
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: ssh_gssapi_storecreds: Not a GSSAPI mechanism
debug1: restore_uid: 0/0
debug1: SELinux support enabled
debug1: PAM: establishing credentials
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: ssh_gssapi_storecreds: Not a GSSAPI mechanism
debug1: restore_uid: 0/0
debug1: Entering interactive session for SSH2.
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 1048576 max 16384
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_global_request: rtype no-more-sessions@openssh.com want_reply 0
debug1: server_input_channel_req: channel 0 request pty-req reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req pty-req
debug1: Allocating pty.
debug1: session_pty_req: session 0 alloc /dev/pts/1
debug1: Ignoring unsupported tty mode opcode 11 (0xb)
debug1: Ignoring unsupported tty mode opcode 17 (0x11)
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request shell reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req shell
debug1: Setting controlling tty using TIOCSCTTY.

和客户端(我的机器日志):

Ahmads-MacBook-Pro:brivolabs-sam-cs elkhawajah$ ssh -i ~/.ssh/id_rsa root@xx.xx.xx.xx
Last login: Sat Feb  1 07:43:37 2014 from xx.xx.xx.xx
debug1: PAM: reinitializing credentials
debug1: permanently_set_uid: 0/0
Environment:
  LC_CTYPE=UTF-8
  USER=root
  LOGNAME=root
  HOME=/root
  PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
  MAIL=/var/mail/root
  SHELL=/bin/bash
  SSH_CLIENT=46.xx.xx.xx 60823 22
  SSH_CONNECTION=46.xx.xx.xx 60823 10.166.3.28 22
  SSH_TTY=/dev/pts/1
  TERM=xterm-256color
  SELINUX_ROLE_REQUESTED=
  SELINUX_LEVEL_REQUESTED=
  SELINUX_USE_CURRENT_RANGE=
-bash: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8): No such file or directory
[root@ip-10-166-3-28 ~]# 

你知道如何解决这个问题吗？

Answer 1

我有点困惑的是，您的客户端日志显示您已成功登录。这些日志来自成功登录还是不成功登录？如果是前者，我们就需要后者。

我在这里部分猜测，但我有根据的猜测是这就是问题所在:{代码} debug1:ssh_gssapi_storecreds:不是 GSSAPI 机制{代码}

每当我遇到 ssh 问题时，我做的第一件事就是编辑客户端上的 /etc/ssh/ssh_config 并表示:

GSSAPIAuthentication no
GSSAPIDelegateCredentials no

并在服务器的/etc/ssh/sshd_config上添加:

GSSAPIAuthentication no
UseDNS no

我假设您实际上不想使用 GSSAPI。

这加快了速度，并且至少对我来说似乎解决了一些问题。

其他标准检查包括除您之外的任何人都无法写入您的主目录、.ssh 权限为 0700，以及 authorized_keys 文件为 0600 或 0644。我不认为这些是这里的问题，因为您会看到不同的调试。