主机接受SSH密钥,但客户端断开连接

直升机,

在安装fedora 23之后,我遇到了SSH问题。

当我不想用私钥连接到我的远程主机时,我的主机find密钥:

debug1: matching key found: file /home/theo/.ssh/authorized_keys, line 1 RSA {REDACTED} debug1: restore_uid: 0/0 Postponed publickey for theo from {REDACTED} port 60351 ssh2 [preauth] Connection closed by {REDACTED} [preauth] debug1: do_cleanup [preauth] debug1: monitor_read_log: child log fd closed 

但是当你看到我的客户自己断开连接

 debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/tbouge/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-rsa blen 1047 debug2: input_userauth_pk_ok: fp SHA256:{REDACTED} debug3: sign_and_send_pubkey: RSA SHA256:{REDACTED} debug2: we did not send a packet, disable method debug1: No more authentication methods to try. Permission denied (publickey). 

我可以使用相同的私钥连接到我的主机与腻子在Windows使用相同的私钥,我可以连接到我的手机使用不同的私钥。

你有什么主意吗 ?

的/ etc / SSH / ssh_conf

 Host * GSSAPIAuthentication yes # If this option is set to yes then remote X11 clients will have full access # to the original X11 display. As virtually no X11 client supports the untrusted # mode correctly we set this to yes. ForwardX11Trusted yes # Send locale-related environment variables SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE SendEnv XMODIFIERS 

谢谢

编辑:我可以连接一个密码

首先,有许多关于如何设置或configuration基于公钥的身份validation的详细文档,可以在线获得。 请看看其中一个,看看你是否一切正确。 这是一个。 所以我不打算再重复一次。

最基本的概念是(从这里复制):

基于密钥的身份validation使用两个密钥,一个允许任何人查看的“公共”密钥和另一个只允许所有者查看的“私人”密钥。 要使用基于密钥的身份validation进行安全通信,需要创build一个密钥对,将私钥安全地存储在要login的计算机上,并将公钥存储在要login的计算机上。

现在从您发布的debugging日志:

  • 看来有两个不同的用户参与其中。 /home/theo/.ssh/authorized_keys/home/tbouge/.ssh/id_rsa 。 你是否试图以一个用户login到另一个用户的主目录?
  • 这个错误Postponed publickey for theo..意思是在publick key方法之前已经尝试了不需要的authentication方法。 SSH会尝试一个接一个地在config中启用的每种validation方法。 在你的情况下,你有GSSAPIAuthentication yes启用你没有使用。 您可以通过执行GSSAPIAuthentication no来安全地禁用它。
  • debug2: we did not send a packet, disable method很可能是它不能处理私钥文件(文件权限或名称问题)。 SSH对本地和远程计算机中的目录和文件权限非常敏感。 chown user_name:user_group -R /home/userchmod 700 /home/.ssh chmod 600 /home/.ssh/authorized_keys )。 所以,确保你的设置正确。 看到这个: https : //unix.stackexchange.com/questions/131886/ssh-public-key-wont-send-to-server
  • 至于第三个错误: Permission denied (public key). ,有几件事要检查。

    • 错误的用户名
    • 错误的密钥对
    • 目标主机错误

      • 这里有更多的细节: https : //stackoverflow.com/questions/18551556/permission-denied-publickey-when-ssh-access-to-amazon-ec2-instance 。

以下部分有点令人困惑:

 debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-rsa blen 1047 debug2: input_userauth_pk_ok: fp SHA256:{REDACTED} debug3: sign_and_send_pubkey: RSA SHA256:{REDACTED} debug2: we did not send a packet, disable method 

为了更好地理解它,让我们一步一步地通过digitalocean中所述的authentication过程:

  1. 客户端首先发送一个想要authentication的密钥对的ID给服务器。
  2. 服务器检查客户端正在尝试login的帐户的authorized_keys文件中的密钥ID。
  3. 如果在文件中find与ID匹配的公钥,服务器将生成一个随机数并使用公钥对数字进行encryption。
  4. 服务器向客户端发送这个encryption的消息。
  5. 如果客户端实际上拥有关联的私钥,则可以使用该密钥对消息进行解密,从而显示原始号码。
  6. 客户端将解密的号码与用于encryption通信的共享会话密钥相结合,并计算该值的MD5哈希值。
  7. 然后,客户端将这个MD5散列发送回服务器,作为encryption号码消息的答案。
  8. 服务器使用相同的共享会话密钥和它发送给客户端的原始号码来自行计算MD5值。 它将自己的计算与客户发回的计算进行比较。 如果这两个值匹配,certificate客户端拥有私钥并且客户端被authentication。

就你所见,远程计算机只接受你的public key ,用这个密钥对数据包进行encryption并发送回客户计算机。 现在客户端计算机需要certificate它有正确的private key 。 只有正确的private_key它可以解密收到的消息,并发回答案。 在这种情况下,客户端没有这样做,authentication过程没有成功。

我希望这可以帮助你了解问题并解决问题。

你的SSH文件的权限是否正确?

.ssh文件夹 – > 700

公钥 – > 644

私钥 – > 600

同时检查用户和组

你的问题似乎是相当普遍的,也很清楚,我说。

  Permission denied (publickey). 

这对你来说意味着什么? 对我来说这意味着很多。

你可以在服务器端检查,如果你有selinux runnin强制模式pls? 如果不告诉我selinux运行的是什么模式。

此外,如果您可以再做一次尝试并捕获该尝试的审计日志,并在此处发布,它肯定会告诉我们为什么:

  tail -f /var/log/audit/audit.log (and try to attempt) 

这是许可问题清楚,但不是文件许可:-)

你说你在Windows机器上有相同的密钥; 你确定你的Linux机器上的私钥文件是正确的吗? 也许私钥是一个腻子的格式,SSH难以理解。 在任何情况下,如果我把一个不正确或无效的私钥文件,我得到完全相同的错误,你有。

为了纠正这个问题,在Linux机器上生成一个新的密钥,而不是重新使用另一台机器上的密钥会更合适。 您只需将新的公钥添加到主机上的authorized_keys文件中,然后就可以同时使用Windows的Windows密钥和Fedora的新Linux密钥。

看来问题(在我的情况下)是由键的types造成的。

我刚刚解决了它将以下内容添加到本地~/.ssh/config文件(Fedora 23客户机):

 PubkeyAcceptedKeyTypes=+ssh-dss 

虽然我已经将该行添加到服务器和客户端configuration文件,但只有客户端有所作为。 请注意,对于要读取的configuration文件,权限需要为600

我不知道是否有其他人仍然有这个问题,但我终于解决了我的一台机器(一台笔记本电脑),遇到了这个问题。 我相信我知道什么最终将它整理出来,我将把信息留在这里,希望它能帮助其他任何可能遇到这个问题的人 – 也希望有人能够希望检查我的解决scheme并确认它实际上是什么解决问题。

事实certificate,这个问题并不是(对我来说)使用SSH,而是使用PAM来configuration我的密钥。 /etc/pam.d中的configuration已经过期(尽pipe它可以通过Fedora 22正常工作),结果正确的事情不会在login[再]从$HOME/.ssh/ 。 运行这个命令:

 # sudo authconfig --updateall 

正确地重build/etc/pam.dconfiguration。 在下一次重新启动后,我login后,第一次尝试SSH到我的服务器,一个对话框要求我input我的SSH密钥( $HOME/.ssh/id_rsa )的密码。 我这样做,检查“自动解锁login”框中,瞧! 我从笔记本电脑中退出的能力恢复了。

背景

导致我解决这个问题的线索来自于我从外部来源导入RSA密钥。 (我带着一个USB钥匙,带着我的家庭networking的“远程访问”键,几年前我在入侵服务器的时候关掉了PasswordAuth到我面向外部的服务器。)在ssh-add -ing之后,这个RSA密钥不像那个坐在$HOME/.ssh/id_rsa ,它被远程服务器接受没有问题。

然后,我最终做了应该是一个多余的ssh-add ,拿起$HOME/.ssh/id_rsa 。 我注意到,在完成之后, ssh-add -l包含了同一个键的两个条目:

 % ssh-add -l 2048 SHA256:XXXXXXXXXXXXXXXXXXXXXX id_rsa (RSA) 2048 SHA256:XXXXXXXXXXXXXXXXXXXXXX me@host (RSA) 2048 SHA256:YYYYYYYYYYYYYYYYYYYYYY imported@usbkey (RSA) 

注意两个条目中的一个没有显示密钥标识符,只是与其公共签名匹配的私钥文件名。 就好像私钥没有被钥匙圈pipe理员真正解锁一样。

我相信这正是发生了什么事情,PAM正在将“坏钥匙”传递给未使用密码解锁的SSH代理程序。 所以,当ssh尝试使用密钥进行身份validation时,实际上并没有密钥对的(未locking)私有一半,因此身份validation失败。

最后一点是猜测,但不pipe是否有人在升级到F23之后,ssh密钥没有被远程主机接受(使用过的地方),使用authconfig重build/etc/pam.d/目录是值得的一个办法。

检查用户主目录权限。 这一点很重要。 必须是755. 700或770将无法正常工作。

在您的ssh_config ,尝试取消注释和/或添加/删除/附加到CipherCiphersMACs行。

在我看来, sshd正在寻找某种未包含在请求中的特定密码,可以通过在ssh_config对其进行configuration来添加该密码。

…而且我假设你no把远程服务器上的PubkeyAuthentication设置为no ,因为这肯定会导致失败。