我在 Linux 机器上使用 SSH 时遇到了一个非常奇怪的问题。我有一个由 OpenSSH 密钥标识的无密码 git 用户。如果我尝试从网络上的同一个或不同的 Linux VM ssh 进入它,它会失败(请参阅下面的完整调试信息)。
但是现在,奇怪的是:我可以从我的 Windows 7 机器上顺利地 ssh 进入,使用完全相同的键! 这表明我们可能遇到了客户端问题。如果服务器上的密钥不知何故被破坏,我应该无法从任何地方进行连接。
我已经为此苦苦挣扎了好几天。关于这个问题有很多话题,但没有一个解决方案有效或适用。
我已经尝试过的常见解决方案:
客户端和服务器上的 ~/.ssh 权限均已正确设置。
具体来说,~/.ssh/* 被设置为 600(一个线程建议将 authorized_keys(服务器)更改为 644,但没有效果)。
~/.ssh 目录本身设置为 700。
~ 中的所有内容均归同名用户/组所有。
客户端(/home/kris/.ssh):
drwx------ 2 kris kris 4096 Apr 11 01:17 . drwx------ 38 kris kris 4096 Apr 11 01:29 .. -rw------- 1 kris kris 458 Apr 11 16:22 config -rw------- 1 kris kris 1675 Apr 10 22:29 id_rsa_kriscraig_git -rw------- 1 kris kris 1675 Apr 11 01:08 id_rsa_kriscraig_git_CRAIGCOM-LINUX -rw------- 1 kris kris 400 Apr 11 01:08 id_rsa_kriscraig_git_CRAIGCOM-LINUX.pub -rw------- 1 kris kris 1675 Apr 11 01:09 id_rsa_kriscraig_git_CRAIGCOM-UT3 -rw------- 1 kris kris 400 Apr 11 01:09 id_rsa_kriscraig_git_CRAIGCOM-UT3.pub -rw------- 1 kris kris 951 Apr 10 22:29 id_rsa_kriscraig_gitolite_Kris -rw------- 1 kris kris 214 Apr 10 22:29 id_rsa_kriscraig_gitolite_Kris.pub -rw------- 1 kris kris 381 Apr 10 22:29 id_rsa_kriscraig_git.pub -rw------- 1 kris kris 1626 Apr 11 17:50 known_hosts
服务器(/home/git/.ssh;由于我一直在反复尝试,现在有点混乱):
drwx------ 2 git git 4096 Apr 11 01:36 . drwx------ 8 git git 4096 Apr 9 17:55 .. -rw-r--r-- 1 git git 2174 Apr 11 01:40 authorized_keys -rw------- 1 git git 904 Aug 4 2012 authorized_keys_bak -rw------- 1 git git 354 Aug 4 2012 authorized_keys_bak2 -rw------- 1 git git 2174 Apr 11 01:13 authorized_keys_bak3 -rw------- 1 git git 160 Apr 10 00:32 config -rw------- 1 git git 1675 Aug 3 2012 id_rsa -rw------- 1 git git 1675 Apr 11 01:08 id_rsa_kriscraig_git_CRAIGCOM-LINUX -rw------- 1 git git 400 Apr 11 01:08 id_rsa_kriscraig_git_CRAIGCOM-LINUX.pub -rw------- 1 git git 1675 Apr 11 01:09 id_rsa_kriscraig_git_CRAIGCOM-UT3 -rw------- 1 git git 400 Apr 11 01:09 id_rsa_kriscraig_git_CRAIGCOM-UT3.pub -rw------- 1 git git 951 Apr 10 00:32 id_rsa_kriscraig_gitolite_Kris -rw------- 1 git git 214 Apr 10 00:33 id_rsa_kriscraig_gitolite_Kris.pub -rw------- 1 git git 381 Aug 3 2012 id_rsa.pub -rw------- 1 git git 414 Aug 4 2012 known_hosts
虽然这一点可能很明显,但事实上我已经验证了配置中的文件路径是正确的。
我已尝试多次生成/分发新密钥。
我也尝试复制/粘贴已经在 Windows 上运行的程序,甚至使用 dos2unix 来确保我们没有处理任何编码问题(CRLF/LF 等)。
我使用标准方法生成密钥:
ssh-keygen -t rsa
我曾尝试调整父主目录的权限,但无济于事。
我修改了本地配置以及 /etc/ssh/*_config
是的,我每次都会重启 sshd。我甚至会随机重启服务器,以防万一。
我确信我至少错过了几件事。我最近睡得很少……
此时我会接受任何建议。如果我已经尝试过,我不会给你差评。=)
基本客户端/服务器信息
服务器
- CentOS 5.9 64 位(VirtualBox)
- 4 GB 内存
- 200 GB HDD(动态分配)
- 4 个 CPU
- 桥接网络(它们都连接到同一个路由器)
- 测试:无
Linux 客户端 #1
- CentOS 5.9 64 位(VirtualBox)
- 1 GB 内存
- 15 GB HDD(动态分配)
- 1 个 CPU
- 桥接网络
- 测试:失败
Linux 客户端 #2
- 服务器本身。这似乎是排除一些可能性的好方法。
- 测试:失败
Windows 客户端
- Windows 7 Ultimate 64 位(VirtualBox 主机)
- 32 GB 内存
- 200 GB 硬盘
- 731 GB 硬盘
- 232 GB 硬盘
- 465 GB 硬盘
- 2.72 TB 硬盘
- 16 CPU
- 测试:成功
调试信息(敏感数据已删除)
服务器
/var/log/secure 中两次失败的 ssh 尝试的结果条目:
Apr 11 22:21:45 CRAIGCOM-LINUX sshd[14738]: Connection from (WAN IP) port 35326
Apr 11 22:21:45 CRAIGCOM-LINUX sshd[14739]: Connection closed by (WAN IP)
Apr 11 22:21:52 CRAIGCOM-LINUX sshd[14741]: Connection from (WAN IP) port 35328
Apr 11 22:21:52 CRAIGCOM-LINUX sshd[14742]: Connection closed by (WAN IP)
Linux 客户端(本质上两者相同)
[kris@CRAIGCOM-LINUX .ssh]$ ssh git@CRAIGCOM-LINUX -vvv
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /home/kris/.ssh/config
debug1: Applying options for CRAIGCOM-LINUX
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to (SERVER HOST) [(SERVER IP)] port 22.
debug1: Connection established.
debug1: identity file "/home/kris/.ssh/id_rsa_kriscraig_git_CRAIGCOM-LINUX" type -1
debug1: loaded 1 keys
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.3
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,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-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[email protected],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_init: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-ctr 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: 118/256
debug2: bits set: 484/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /home/kris/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug3: check_host_in_hostfile: filename /home/kris/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug1: Host '(SERVER HOST)' is known and matches the RSA host key.
debug1: Found key in /home/kris/.ssh/known_hosts:1
debug2: bits set: 522/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: "/home/kris/.ssh/id_rsa_kriscraig_git_CRAIGCOM-LINUX" ((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 publickey
debug3: authmethod_lookup publickey
debug3: remaining preferred:
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: "/home/kris/.ssh/id_rsa_kriscraig_git_CRAIGCOM-LINUX"
debug3: no such identity: "/home/kris/.ssh/id_rsa_kriscraig_git_CRAIGCOM-LINUX"
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-with-mic,password).
这就是我被困的地方
从日志中可以看出,尝试打开私钥文件后,它返回“无此身份”。我认为这种拒绝发生在客户端。据我所知,它没有向服务器发送任何内容;只是打开并突然关闭连接。
我实在想不通为什么两个 CentOS 机器上的密钥文件都出错了!权限设置得很完美,文件可读,两台服务器都没有使用 SELinux,相同的密钥在 Windows 客户端上运行良好,等等。
我擅长担任系统管理员;但归根结底,我是一名开发人员,而不是 IT 人员。这种级别的 SSH 调试已经超出了我的专业领域。我不想这么说,但我真的没有主意了。根据我在互联网上找到的每一件事,这应该是可行的。但事实并非如此。我错过了什么?
谢谢你的帮助!希望你们中有人能意识到这个问题,并引导我走向正确的方向。如果您需要更多详细信息,请随时询问。
--克里斯
答案1
请使用 ssh-agent。
- 首先将您的密钥添加到代理:
ssh-add ~/.ssh/$keyfile
。 - 然后验证密钥是否加载成功:
ssh-add -l
- 然后尝试 ssh 到你的远程机器。(代理应该进行身份验证。)
如果您的密钥确实有问题,您在尝试添加它时就会注意到。