不输入密码就无法设置ssh登录

8

我通过以下方式自动设置了ssh登录，而无需在服务器上输入密码：

cd ~/.ssh

ssh-keygen

ssh-copy-id -i ~/.ssh/id_rsa.pub tim@server1

它可以在服务器上运行。

后来我在另一台服务器上做了同样的事情。

ssh-copy-id -i ~/.ssh/id_rsa.pub tim@server2

立即我ssh tim@server2，但仍然需要我的密码。我做错了什么吗？我没有在第二台服务器上成功设置的一些可能原因是什么？（请注意，第二台服务器运行kerberos和Andrew文件系统）

$ ssh -v tim@server2
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to server2 [...] port 22.
debug1: Connection established.
debug1: identity file /home/tim/.ssh/id_rsa type 1
debug1: identity file /home/tim/.ssh/id_rsa-cert type -1
debug1: identity file /home/tim/.ssh/id_dsa type -1
debug1: identity file /home/tim/.ssh/id_dsa-cert type -1
debug1: identity file /home/tim/.ssh/id_ecdsa type -1
debug1: identity file /home/tim/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/tim/.ssh/id_ed25519 type -1
debug1: identity file /home/tim/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA xxx
debug1: Host 'server2' is known and matches the RSA host key.
debug1: Found key in /home/tim/.ssh/known_hosts:70
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Trying private key: /home/tim/.ssh/id_dsa
debug1: Trying private key: /home/tim/.ssh/id_ecdsa
debug1: Trying private key: /home/tim/.ssh/id_ed25519
debug1: Next authentication method: keyboard-interactive
Password:

我尝试了Anthon使用Diffie-Hellman密钥的方法，但仍然要求我输入密码。

$ cd ~/.ssh
$ ssh-keygen -t dsa
$ ssh-copy-id -i ~/.ssh/id_dsa.pub tim@server2
$ ssh -v tim@server2
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to server2 [...] port 22.
debug1: Connection established.
debug1: identity file /home/tim/.ssh/id_rsa type 1
debug1: identity file /home/tim/.ssh/id_rsa-cert type -1
debug1: identity file /home/tim/.ssh/id_dsa type 2
debug1: identity file /home/tim/.ssh/id_dsa-cert type -1
debug1: identity file /home/tim/.ssh/id_ecdsa type -1
debug1: identity file /home/tim/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/tim/.ssh/id_ed25519 type -1
debug1: identity file /home/tim/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA ...
debug1: Host 'server2' is known and matches the RSA host key.
debug1: Found key in /home/tim/.ssh/known_hosts:70
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Next authentication method: publickey
debug1: Offering DSA public key: /home/tim/.ssh/id_dsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Trying private key: /home/tim/.ssh/id_ecdsa
debug1: Trying private key: /home/tim/.ssh/id_ed25519
debug1: Next authentication method: keyboard-interactive
Password:
ssh 
— 提姆
source
登录后是否挂载了主目录？
— muru
过去每次登录后，我的家总是被装上。
— 2015年
是的，一旦登录，您便获得了主目录-但是在登录完成之前该怎么办？（考虑加密的主目录或网络主目录等）
— muru 2015年
听说server2使用Andrew文件系统。这是否意味着在登录完成之前没有安装我的家？我如何找到您的问题？
— 蒂姆（Tim）
我不确定Andrew文件系统的工作方式，但是如果您在同一服务器上有另一个登录名，请使用它，并查看是否可以看到tim的home目录的内容。
— muru 2015年

Answers:

10

您提到第二台服务器正在使用Andrew文件系统（AFS）。

我还没有使用它，但是据我了解，AFS是受Kerberos保护的文件系统，需要使用Kerberos票证才能工作。这意味着您需要登录到站点的Kerberos领域才能访问您的主目录。

如果使用密码登录，server2则可能已进行设置，以使其通过PAM登录到Kerberos领域。但是，如果您使用的是SSH密钥，server2则将无法获得执行此操作所需的信息，并且您将无法访问主目录。

幸运的是，从ssh -v您问题的输出中，我们可以推断出您的服务器已GSSAPI启用身份验证。只要您拥有适用于您的领域的有效kerberos票证，这就应该允许您执行无密码登录。请执行下列操作：

  • 登录到server2，然后运行该klist程序。这将返回以下内容：

    Ticket cache: FILE:/tmp/krb5cc_2000
Default principal: wouter@EXAMPLE.ORG

Valid starting     Expires            Service principal
28-05-15 15:01:31  29-05-15 01:01:31  krbtgt/EXAMPLE.ORG@EXAMPLE.ORG
    renew until 29-05-15 15:01:28
28-05-15 15:02:04  29-05-15 01:01:31  IMAP/example.org@EXAMPLE.ORG
    renew until 29-05-15 15:01:28

    寻找以开头的行Default principal:。它告诉您您的Kerberos主体（在上面的示例中是wouter@EXAMPLE.ORG）。写下来。请注意，这不是电子邮件地址，并且区分大小写；即，主体以而EXAMPLE.ORG不是结尾example.org。

  • 在您的客户端计算机上，kinit使用主体名称运行（即，在上面的示例中为kinit wouter@EXAMPLE.ORG）。如果一切顺利，则当您klist再次运行时，您会看到本地计算机上有票证缓存。
  • 如果现在运行ssh -K server2，则应该可以登录，并且系统不应要求输入密码。

请注意，由于Kerberos的工作原理，票证缓存的有效性受到限制。请求的票证缓存的有效期不可能超过领域管理员配置的有效期（通常是10个小时左右）。票证过期后，您将需要kinit再次运行，然后再次输入密码。

— 伍特·韦尔赫斯特
source
谢谢。“在您的客户端计算机上，运行kinit”，是否意味着我必须在本地Ubuntu上安装Kerberos？
— 蒂姆（Tim）
是kerberos工具的一部分。您将在krb5-user软件包中找到所需的工具。
— Wouter Verhelst 2015年
创建公用密钥并将其复制到服务器时，应该使用rsa还是dsa？（我现在遵循Anthon的建议使用dsa）
— 蒂姆
由于服务器上的AFS，您不能使用SSH公钥，而需要使用kerberos。所以没关系；-)
— Wouter Verhelst 2015年
GSSAPI，dsa和rsa是否都是身份验证方法？
— 蒂姆（Tim）2015年
5

您应该尝试通过以下方式连接到server2：

ssh -v tim@server2

并与之进行比较，连接server1到此服务器将告诉您两个服务器的确切区别。

/etc/ssh/sshd_config两台计算机上最有可能存在差异。哪里server2或您~/.ssh存在可访问性问题（限制不够）。

从-v输出中可以看到，您提供了一个RSA私钥来进行验证（在中/home/tim/.ssh/id_rsa），但看起来server2仅支持Diffie-Hellman（并尝试 /home/tim/.ssh/id_dsa甚至不支持）。

— 安通
source
谢谢，我更新了运行命令的输出。不确定是什么意思
— 蒂姆
@Tim更新了我的答案，您应该与server2管理员联系，以查看为什么它似乎不支持RSA私钥/公钥。
— Anthon 2015年
除了询问管理员（根据我的经验，我认为这是不可能进行任何更改）之外，是否还有其他方法可以处理服务器的期望？
— 蒂姆（Tim）
@Tim，首先请确保~/.ssh服务器上确实安装了您的授权密钥（~/.ssh/authorized_keys）。然后，您可以尝试使用ssh-keygen生成diffie-hellman密钥对ssh-keygen -t dsa并将其复制。
— Anthon 2015年
（1）~/.ssh/authorized_keys服务器上有一个文件。这是否意味着已安装授权密钥？（2）如何将生成的diffie-hellman密钥对复制到服务器？由scp ~/.ssh/id_dsa.pub tim@server2:~/.ssh/authorized_keys？会~/.ssh/authorized_keys在服务器上覆盖吗？
— 2015年
4

将以下条目添加到您要从中尝试SSH的客户端计算机中。

配置文件： /etc/ssh/ssh_config

GSSAPIAuthentication no

之后，您将可以SSH到计算机。

如果您没有该文件的编辑权限，则还可以添加

Host *
  GSSAPIAuthentication no

到~/.ssh/config（如果不存在则创建此文件）

— 苏达姆斯·雷迪
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.