获取权限被拒绝(publickey)甚至在authorized_keys服务器文件上使用我的公钥

时间:2021-07-30 14:27:40

I accidentally erased my private and public key in my local machine.

我不小心删除了我本地计算机中的私钥和公钥。

So I created a new pair using:

所以我创建了一对新的使用:

ssh-keygen -t rsa

and copied the content of the id_rsa.pub into my authorized_keys on the server (I can log in as root and I can see the root public key in the authorized_keys file).

并将id_rsa.pub的内容复制到服务器上的authorized_keys中(我可以以root身份登录,我可以在authorized_keys文件中看到根公钥)。

However, I keep getting Permission Denied. I already checked the ~/.ssh and the authorized keys permissions (which are set to 700 and 600 respectively).

但是,我一直拒绝权限。我已经检查了〜/ .ssh和授权密钥权限(分别设置为700和600)。

Any ideas?

Thanks!

Here you have the log output when I try to connect from my local machine:

当我尝试从本地计算机连接时,您有以下日志输出:

Aug 21 16:32:27 ip-xx-xx-xx-xx sshd[16635]: debug1: Forked child 27356.
Aug 21 16:32:27 ip-xx-xx-xx-xx sshd[27356]: Set /proc/self/oom_score_adj to 0
Aug 21 16:32:27 ip-xx-xx-xx-xx sshd[27356]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Aug 21 16:32:27 ip-xx-xx-xx-xx sshd[27356]: debug1: inetd sockets after dupping: 3, 3
Aug 21 16:32:27 ip-xx-xx-xx-xx sshd[27356]: Connection from 50.67.165.140 port 60112
Aug 21 16:32:27 ip-xx-xx-xx-xx sshd[27356]: debug1: Client protocol version 2.0; client software version OpenSSH_5.9p1 Debian-5ubuntu1.1
Aug 21 16:32:27 ip-xx-xx-xx-xx sshd[27356]: debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH*
Aug 21 16:32:27 ip-xx-xx-xx-xx sshd[27356]: debug1: Enabling compatibility mode for protocol 2.0
Aug 21 16:32:27 ip-xx-xx-xx-xx sshd[27356]: debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1
Aug 21 16:32:27 ip-xx-xx-xx-xx sshd[27356]: debug1: permanently_set_uid: 105/65534 [preauth]
Aug 21 16:32:27 ip-xx-xx-xx-xx sshd[27356]: debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
Aug 21 16:32:27 ip-xx-xx-xx-xx sshd[27356]: debug1: SSH2_MSG_KEXINIT sent [preauth]
Aug 21 16:32:28 ip-xx-xx-xx-xx sshd[27356]: debug1: SSH2_MSG_KEXINIT received [preauth]
Aug 21 16:32:28 ip-xx-xx-xx-xx sshd[27356]: debug1: kex: client->server aes128-ctr hmac-md5 none [preauth]
Aug 21 16:32:28 ip-xx-xx-xx-xx sshd[27356]: debug1: kex: server->client aes128-ctr hmac-md5 none [preauth]
Aug 21 16:32:28 ip-xx-xx-xx-xx sshd[27356]: debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
Aug 21 16:32:28 ip-xx-xx-xx-xx sshd[27356]: debug1: SSH2_MSG_NEWKEYS sent [preauth]
Aug 21 16:32:28 ip-xx-xx-xx-xx sshd[27356]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]
Aug 21 16:32:28 ip-xx-xx-xx-xx sshd[27356]: debug1: SSH2_MSG_NEWKEYS received [preauth]
Aug 21 16:32:28 ip-xx-xx-xx-xx sshd[27356]: debug1: KEX done [preauth]
Aug 21 16:32:28 ip-xx-xx-xx-xx sshd[27356]: debug1: userauth-request for user capistrano service ssh-connection method none [preauth]
Aug 21 16:32:28 ip-xx-xx-xx-xx sshd[27356]: debug1: attempt 0 failures 0 [preauth]
Aug 21 16:32:28 ip-xx-xx-xx-xx sshd[27356]: debug1: PAM: initializing for "capistrano"
Aug 21 16:32:28 ip-xx-xx-xx-xx sshd[27356]: debug1: PAM: setting PAM_RHOST to "s0106c8fb26427cda.vc.shawcable.net"
Aug 21 16:32:28 ip-xx-xx-xx-xx sshd[27356]: debug1: PAM: setting PAM_TTY to "ssh"
Aug 21 16:32:28 ip-xx-xx-xx-xx sshd[27356]: debug1: userauth-request for user capistrano service ssh-connection method publickey [preauth]
Aug 21 16:32:28 ip-xx-xx-xx-xx sshd[27356]: debug1: attempt 1 failures 0 [preauth]
Aug 21 16:32:28 ip-xx-xx-xx-xx sshd[27356]: debug1: test whether pkalg/pkblob are acceptable [preauth]
Aug 21 16:32:28 ip-xx-xx-xx-xx sshd[27356]: debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
Aug 21 16:32:28 ip-xx-xx-xx-xx sshd[27356]: debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
Aug 21 16:32:28 ip-xx-xx-xx-xx sshd[27356]: debug1: temporarily_use_uid: 1001/1001 (e=0/0)
Aug 21 16:32:28 ip-xx-xx-xx-xx sshd[27356]: debug1: trying public key file /home/capistrano/.ssh/authorized_keys
Aug 21 16:32:28 ip-xx-xx-xx-xx sshd[27356]: debug1: fd 4 clearing O_NONBLOCK
Aug 21 16:32:28 ip-xx-xx-xx-xx sshd[27356]: debug1: restore_uid: 0/0
Aug 21 16:32:28 ip-xx-xx-xx-xx sshd[27356]: Failed publickey for capistrano from <ip> port 60112 ssh2
Aug 21 16:32:28 ip-xx-xx-xx-xx sshd[27356]: Connection closed by <ip> [preauth]
Aug 21 16:32:28 ip-xx-xx-xx-xx sshd[27356]: debug1: do_cleanup [preauth]
Aug 21 16:32:28 ip-xx-xx-xx-xx sshd[27356]: debug1: monitor_read_log: child log fd closed
Aug 21 16:32:28 ip-xx-xx-xx-xx sshd[27356]: debug1: do_cleanup
Aug 21 16:32:28 ip-xx-xx-xx-xx sshd[27356]: debug1: PAM: cleanup

4 个解决方案

#1


0  

Delete the known_hosts entry for your workstation and try again. I use 644 for authorized_keys.

删除工作站的known_hosts条目,然后重试。我将644用于authorized_keys。

#2


0  

What users and paths are involved? In the standard openssh setup, the $HOME/.ssh directory of the remote user (the one into which ssh is logging in) is the right location for the authorized_keys file. However, it is also possible to have the files located elsewhere.

涉及哪些用户和路径?在标准的openssh设置中,远程用户的$ HOME / .ssh目录(ssh登录的目录)是authorized_keys文件的正确位置。但是,也可以将文件放在其他位置。

Also, check the file ownership. The authorized_keys file must be owned by the user logging in.

另外,检查文件所有权。 authorized_keys文件必须由登录用户拥有。

A check of /var/log/messages or /var/log/secure ("ls -ltr /var/log" after a failed attempt may help figure out the right log file) may give specifics.

检查/ var / log / messages或/ var / log / secure(尝试失败后的“ls -ltr / var / log”可能有助于找出正确的日志文件)可能会给出具体细节。

If all else fails, you could strace the sshd process(es) to see exactly which files they are reading. Not trivial to do, but it does get right to the guts of the operation of the server.

如果所有其他方法都失败了,您可以使用sshd进程来查看他们正在阅读的文件。这不是一件轻而易举的事,但它确实适应了服务器运行的内涵。

#3


0  

What works for me is:

对我有用的是:

chmod 750 /home/user
chmod 700 /home/user/.ssh
chmod 644 /home/user/.ssh/authorized_keys

If that doesn't work for you, try:

如果这对您不起作用,请尝试:

chmod 755 /home/user

#4


-1  

Ok so I figure it out... the issue was that I was adding the public key to the authorized_keys file on another user's directory. :S.. Thanks anyway

好的,我弄清楚了...问题是我将公钥添加到另一个用户目录上的authorized_keys文件中。 :S ..无论如何,谢谢

#1


0  

Delete the known_hosts entry for your workstation and try again. I use 644 for authorized_keys.

删除工作站的known_hosts条目,然后重试。我将644用于authorized_keys。

#2


0  

What users and paths are involved? In the standard openssh setup, the $HOME/.ssh directory of the remote user (the one into which ssh is logging in) is the right location for the authorized_keys file. However, it is also possible to have the files located elsewhere.

涉及哪些用户和路径?在标准的openssh设置中,远程用户的$ HOME / .ssh目录(ssh登录的目录)是authorized_keys文件的正确位置。但是,也可以将文件放在其他位置。

Also, check the file ownership. The authorized_keys file must be owned by the user logging in.

另外,检查文件所有权。 authorized_keys文件必须由登录用户拥有。

A check of /var/log/messages or /var/log/secure ("ls -ltr /var/log" after a failed attempt may help figure out the right log file) may give specifics.

检查/ var / log / messages或/ var / log / secure(尝试失败后的“ls -ltr / var / log”可能有助于找出正确的日志文件)可能会给出具体细节。

If all else fails, you could strace the sshd process(es) to see exactly which files they are reading. Not trivial to do, but it does get right to the guts of the operation of the server.

如果所有其他方法都失败了,您可以使用sshd进程来查看他们正在阅读的文件。这不是一件轻而易举的事,但它确实适应了服务器运行的内涵。

#3


0  

What works for me is:

对我有用的是:

chmod 750 /home/user
chmod 700 /home/user/.ssh
chmod 644 /home/user/.ssh/authorized_keys

If that doesn't work for you, try:

如果这对您不起作用,请尝试:

chmod 755 /home/user

#4


-1  

Ok so I figure it out... the issue was that I was adding the public key to the authorized_keys file on another user's directory. :S.. Thanks anyway

好的,我弄清楚了...问题是我将公钥添加到另一个用户目录上的authorized_keys文件中。 :S ..无论如何,谢谢