ssh 密钥认证仍然提示密码

ssh 密钥认证仍然提示密码

我很快就让 ssh 密钥身份验证在我的生产服务器上运行起来。然而,我一直在努力让它在我的开发服务器上运行。

首先,我生成了密钥(我在家里和服务器上都使用 Ubuntu):

$ ssh-keygen -t rsa -f ~/.ssh/production-key.id_rsa

.ssh$ ls -l
total 36
-rw-rw-r-- 1 viggy viggy  234 Dec 22 15:21 config
-rw------- 1 viggy viggy 1766 Dec 22 15:03 development-key.id_rsa
-rw-r--r-- 1 viggy viggy  397 Dec 22 15:03 development-key.id_rsa.pub
-rw------- 1 viggy viggy 1766 Dec 22 13:12 production-key.id_rsa
-rw-r--r-- 1 viggy viggy  397 Dec 22 13:12 production-key.id_rsa.pub
-rw------- 1 viggy viggy 1766 Sep  5 20:36 id_rsa
-rw-r--r-- 1 viggy viggy  403 Sep  5 20:36 id_rsa.pub
-rw-r--r-- 1 viggy viggy 4422 Dec 22 11:45 known_hosts

我将开发私钥添加到我的配置文件中:

vim config
Host production
HostName xx.xxx.xx.xxx
User myuser
IdentityFile ~/.ssh/production-key.id_rsa

Host development
HostName xx.xxx.xx.xxx
User myuser
IdentityFile ~/.ssh/development-key.id_rsa

然后我将公钥复制到服务器:

cd ~/.ssh
vim authorized_keys // deleted contents of this file and copied my development-key.id_rsa.pub into it and saved file
cat authorized_keys // looked at contents to confirm it matched my development-key.id_rsa.pub

然后我尝试通过 ssh 进入开发服务器,但它要求我输入密码(而不是提示输入密码短语)。

接下来我开始排查为什么它不起作用。我检查了服务器上的文件/目录权限:

$ ls -l | grep home
drwxr-xr-x   6 root root  4096 Aug  7  2012 home
$ ls -l | grep myuser
drwxr-xr-x 16 myuser myuser  4096 Dec 22 17:47 myuser
$ ls -la | grep .ssh
drwx------  3 myuser myuser       4096 Dec 22 15:32 .ssh
~/.ssh $ ls -l | grep authorized_keys
-rw------- 1 myuser myuser  396 Dec 22 15:32 authorized_keys

接下来,我查看了 sshd_config 文件以确认其配置。现在我还没有禁用密码验证,但我在其他服务器上也没有禁用它,并且 ssh 密钥有效:

$ cd /etc/ssh
$ head -n 1000 sshd_config | grep 'PasswordAuthentication'
#PasswordAuthentication yes

我检查了是否有任何帐户不允许访问 ssh(但这里没有什么不寻常的):

$ head -n 1000 sshd_config | grep 'AllowUsers'
$ head -n 1000 sshd_config | grep 'DenyUsers'

我确保公钥认证已启用:

head -n 1000 sshd_config | grep 'PubkeyAuthentication'
PubkeyAuthentication yes
$ head -n 1000 sshd_config | grep 'RSAAuthentication'
RSAAuthentication yes
RhostsRSAAuthentication no

然后我重新启动了 ssh 服务器:

sudo restart ssh

然后我检查了我的主目录是否已加密,但事实并非如此:

ls -A /home
.directory   lost+found  quota.group  someuser
myuser  passenger   quota.user

我检查了一下系统上可能还有其他配置:

/ $ locate sshd_config
/etc/ssh/sshd_config
/usr/share/doc/openssh-client/examples/sshd_config
/usr/share/man/man5/sshd_config.5.gz

我尝试了这里的建议:

ssh 不再允许公钥认证

因此,最后我尝试在调试模式下使用 ssh,得到的结果如下(我更改了 IP 地址和用户名):

ssh -vv [email protected]
OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /home/viggy/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to xx.xxx.xx.xxx [xx.xxx.xx.xxx] port 22.
debug1: Connection established.
debug1: identity file /home/viggy/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/viggy/.ssh/id_rsa-cert type -1
debug1: identity file /home/viggy/.ssh/id_dsa type -1
debug1: identity file /home/viggy/.ssh/id_dsa-cert type -1
debug1: identity file /home/viggy/.ssh/id_ecdsa type -1
debug1: identity file /home/viggy/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: [email protected],[email protected],ssh-rsa,[email protected],[email protected],[email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,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,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,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: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,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,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,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_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: RSA 42:f0:18:ae:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
debug1: Host 'xx.xxx.xx.xxx' is known and matches the RSA host key.
debug1: Found key in /home/viggy/.ssh/known_hosts:3
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: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/viggy/.ssh/id_rsa (0xb8bab790)
debug2: key: viggy@teamviggy (0xb8bb1e18)
debug2: key: viggy@teamviggy (0xb8bb1cb8)
debug2: key: /home/viggy/.ssh/id_dsa ((nil))
debug2: key: /home/viggy/.ssh/id_ecdsa ((nil))
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/viggy/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: viggy@teamviggy
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: viggy@teamviggy
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/viggy/.ssh/id_dsa
debug1: Trying private key: /home/viggy/.ssh/id_ecdsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
[email protected]'s password:

更新:我在开发服务器上使用了我的公共生产密钥,并且成功了。显然我的 ~/.ssh/config 文件中有些内容不正确,但我不确定是什么。

答案1

ssh -vv [email protected]
OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /home/viggy/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *

应用选项 *意味着 ssh 客户端认为您正在连接的主机不在配置文件中。

根据您对其他答案的评论,您已经将每个主机特定设置移至配置文件的顶部,“Host *”部分之前,因此解析现在不是问题。

但是 ssh 客户端仍然无法在配置文件中找到该主机,这只能意味着主持人您在配置文件中写入的内容与您在调用 ssh 时在命令行中写入的内容不同。您确定主持人你在配置文件中写的和你在命令行中写的完全一样吗?(必须完全一样,匹配前名称不会转换为规范化的主机名

答案2

我最近遇到了这个问题,结果发现是 SELinux 处于强制模式并且~/.ssh文件~/.ssh/authorized_keys具有错误上下文的问题。

audit2allow -a在客户端尝试 ssh 后,SElinux 中出现了以下输出:

#============= sshd_t ==============
allow sshd_t home_root_t:file { read getattr open };

运行restorecon -Rv ~/.ssh重置上下文后~/.ssh,和~/.ssh/authorized_keys已更新,并且从客户端 ssh 接入不再提示输入密码。

以下是让我了解 SELinux 的页面

答案3

您的配置文件是倒序排列的。我实际上不确定您的客户端是否查看了您的其他密钥,但以下是:

Host production
HostName xx.xxx.xx.xxx
User myuser
IdentityFile ~/.ssh/production-key.id_rsa

Host development
HostName xx.xxx.xx.xxx
User myuser
IdentityFile ~/.ssh/development-key.id_rsa

需要是:

Host development
HostName xx.xxx.xx.xxx
User myuser
IdentityFile ~/.ssh/development-key.id_rsa

Host production
HostName xx.xxx.xx.xxx
User myuser
IdentityFile ~/.ssh/production-key.id_rsa

从配置文件中:

任何配置值仅在第一次设置时才会更改。因此,主机特定的定义应位于配置文件的开头,默认值应位于结尾。

但是我的第二个建议(如果这也会失败,即使你把开发的东西全部放在最顶部) - 尝试将除开发 pub/priv 密钥和 known_hosts 之外的所有其他密钥从~/.ssh.

SSH 似乎默认为id_rsa和 ,id_rsa.pub即使您在此处进行了设置。因此,我将developement-key.id_rsa和 对应的 pub 重命名为id_rsaid_rsa.pub

答案4

我遇到了同样的问题,今天才解决。就我而言,ssh 仍然提示输入密码的原因是我生成了一个带有密码的公钥...已解决,生成了一个带有空密码的新公钥。有时我只需要停止运行一段时间...

相关内容