![设置 OpenSSH 以使用 rhosts?](https://linux22.com/image/72101/%E8%AE%BE%E7%BD%AE%20OpenSSH%20%E4%BB%A5%E4%BD%BF%E7%94%A8%20rhosts%EF%BC%9F.png)
我租了几个运行最新 Ubuntu 的 VPS,都带有 OpenSSH。我想尝试使用 .rhosts/.shosts 进行无密码登录。我知道这是不是推荐,并且最好使用公钥身份验证......我只是想测试并且知道如何设置它。我想从我的客户端/本地计算机登录到我的服务器/远程计算机,无需密码。我在本地计算机上使用普通的非 root 用户帐户,并且想要登录到远程计算机上具有相同用户名的帐户。
这是我的问题列表:
- 我必须在远程计算机上的 /etc/hosts 中列出本地计算机的主机名和 IP 地址吗?我还必须在本地计算机上的 /etc/hosts 中列出远程计算机的主机名/IP 吗? /etc/hosts 对此有什么影响吗?
- .rhosts 和 .shosts 有什么区别?
- 据我了解, .rhosts/.shosts 文件位于远程计算机上的用户主目录中,并且只能由所有者读取。它应该包含“主机名用户名”形式的行...这是正确的吗?
- 如果两台计算机上的用户名相同,是否可以删除用户名,或者必须是否在 .rhosts/.shosts 中明确说明?
- 即使我在两台计算机上获得不同的用户名(假设我拥有的名称位于 .rhosts/.shosts 中),是否可以使用此机制?
- 我可以在 .rhosts/.shosts 中使用 IP 地址代替主机名吗?如果远程计算机上的 /etc/hosts 包含此配对,我可以这样做吗?
- 我必须对远程和本地计算机上的 /etc/ssh/ssh_config 和/或 /etc/ssh/sshd_config 进行哪些更改?
- 是否可以选择设置它,这样我就可以避免使用“全局”/etc/ssh/ssh_known_hosts,并且只是使用我本地的 ~/.ssh/known_hosts?必须在客户端/本地、服务器/远程或两者上设置吗?
- 是否可以选择性地将其设置为忽略计算机的主机密钥,即只是寻找 .rhosts/.shosts 而不是对计算机进行身份验证? (是的,我知道这会很愚蠢......我只是想知道是否可以做到。)
- 我是否必须使用
rsh
或rlogin
命令才能使其正常工作,或者ssh
如果其余设置正确,也将正常工作? - 是否有可能以某种方式“本地”测试该机制 - 即。在同一台计算机上?如果我在同一台计算机上有多个用户帐户,我可以添加一个 .rhosts/.shosts 文件,其中包含“localhost”、“127.0.0.1”和/或我的计算机主机名的条目 - 以及我的其他帐户的用户名一样的计算机 - 并使这个机制发挥作用?毕竟,
ssh
也可以登录“localhost”上的其他帐户...如果可以的话,我该如何设置呢?
再说一遍,我只是在玩,想学习......我知道不仅不安全,而且还属于过河找水的情况。
答案1
所需的功能不需要在两台机器之间建立信任。此外,正如您所提到的,从安全角度来看,不建议这样做。
您可能想要执行的操作(如果您想要无密码)登录远程服务器如下:
- 在您的用户的本地计算机上使用
ssh-keygen -t rsa
并只需按进入按密码提示键。这将生成一个没有密码的密钥。因此,如果有人窃取私钥,他们将能够访问您的服务器(除非您使用防火墙将服务器的访问限制为仅您的 IP 地址) - 将公钥(例如〜/.ssh/id_rsa.pub,如果您在上一步中没有更改密钥对的名称)复制到服务器到所需帐户的主目录。
- 在服务器上您所需的帐户下创建(如果不存在)〜/.ssh 目录
mkdir -m700 -p ~/.ssh
- 将步骤 2 中复制的公钥内容添加到 ~/.ssh/authorized_keys 中(或者如果该文件不存在,只需将复制的公钥重命名为该名称)
- 确保 ~/.ssh 和 ~/.ssh/authorized_keys 上的所有权和权限正确。两者都应由主目录的用户及其主要组拥有,~/.ssh 目录应具有 0700 权限,~/.ssh/authorized_key 应具有 0600 权限。
从此时起,从本地计算机连接到所需的帐户将是无密码的(如果您没有更改密钥对的名称,则可以使用,或者如果您在步骤 1 中更改了密钥名称,则可以使用),ssh [email protected]
ssh -i ~/.ssh/name_of_your_private_key [email protected]
现在,如果您仍然想走“完全不安全”的方式并在机器之间建立信任,这就是您所追求的方法:http://itg.chem.indiana.edu/inc/wiki/software/openssh/189.html——我仍然不建议走这条路,除非你只是想看看它是如何工作的。即使在这种情况下,这也是值得怀疑的,因为从安全角度来看这确实是一个坏主意。