linux 手动配置多台服务器的免密登录,仅使用ssh-keygen 和 scp命令以及输出重定向或者vim,不使用ssh-copy-ip
在Linux系统中,要手动配置多台服务器之间的免密登录,可以通过生成SSH密钥对,并将公钥复制到目标服务器上实现。以下是详细的步骤,假设你已经拥有了所有服务器的访问权限并且知道每台服务器的用户名和IP地址。
步骤1: 在源服务器上生成SSH密钥对
如果你还没有创建过SSH密钥对,可以在源服务器上运行以下命令来生成一个新的密钥对。通常情况下,这个命令会生成一个默认名为 id_rsa
的私钥文件和一个名为 id_rsa.pub
的公钥文件。
ssh-keygen -t rsa -b 4096
这条命令会提示你输入保存密钥的文件名(可以按回车键接受默认值),以及为私钥设置密码(如果不需要密码保护可以直接按回车跳过)。
步骤2: 将公钥复制到目标服务器
对于每一台需要配置免密登录的目标服务器,你需要将你的公钥复制过去。这里以 target_server_ip
表示目标服务器的IP地址,以 target_user
表示目标服务器上的用户名。你可以使用 scp
命令或者手动使用 vim
编辑器来完成这一步。
使用scp命令
scp ~/.ssh/id_rsa.pub target_user@target_server_ip:~/
然后,你需要登录到目标服务器并手动将公钥添加到 .ssh/authorized_keys
文件中:
ssh target_user@target_server_ip
cat ~/id_rsa.pub >> ~/.ssh/authorized_keys
rm ~/id_rsa.pub # 删除临时上传的公钥文件
或者直接通过命令行操作
如果你不想使用 scp
,也可以直接通过命令行将公钥复制到目标服务器的 ~/.ssh/authorized_keys
文件中,这种方法更简洁:
cat ~/.ssh/id_rsa.pub | ssh target_user@target_server_ip "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
这条命令做了以下几件事:
cat ~/.ssh/id_rsa.pub
:读取本地的公钥文件。|
:管道符,将前面命令的输出作为后面命令的输入。ssh target_user@target_server_ip "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
:登录到目标服务器,并执行一系列命令。首先确保.ssh
目录存在,然后将输入(即公钥)追加到authorized_keys
文件中。
步骤3: 测试连接
完成上述步骤后,你应该可以从源服务器无密码地登录到目标服务器了。测试一下:
ssh target_user@target_server_ip
如果一切正常,你应该能够立即登录而无需输入密码。
注意事项
- 确保目标服务器上的
.ssh
目录和authorized_keys
文件有正确的权限设置。通常.ssh
目录应该有700权限,authorized_keys
文件应该有600权限。 - 如果遇到问题,检查目标服务器的SSH服务配置是否允许基于密钥的身份验证。
- 对于多台服务器,重复步骤2中的过程即可。
.ssh目录必须为700权限,authorized_keys必须为 600权限否则免密不成功
免密不成功的潜在原因
当免密登录不起作用,即使确认 sshd
服务运行正常时,可能的原因有很多。下面列出了一些常见的问题及其解决方法:
1. 文件权限不正确
问题描述:~/.ssh
目录或 ~/.ssh/authorized_keys
文件的权限不正确可能导致SSH服务器拒绝使用公钥认证。
解决方案:
- 确保
~/.ssh
目录的权限是700 (drwx------
)。 - 确保
~/.ssh/authorized_keys
文件的权限是600 (-rw-------
)。
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
2. 公钥未正确添加到 authorized_keys
文件
问题描述:如果公钥没有正确添加到 authorized_keys
文件,或者格式错误,可能会导致认证失败。
解决方案:
- 检查
~/.ssh/authorized_keys
文件中的公钥是否正确无误。 - 确认公钥是一行显示,没有多余的空格或换行符。
3. SSH配置不允许公钥认证
问题描述:服务器的SSH配置可能禁止了公钥认证。
解决方案:
-
编辑
/etc/ssh/sshd_config
文件,确保以下设置是正确的:PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
-
重启SSH服务使更改生效:
sudo systemctl restart sshd
4. 客户端或服务器端的SSH版本不兼容
问题描述:客户端与服务器端使用的SSH版本不同,可能会导致一些功能不兼容。
解决方案:
- 检查客户端和服务器的SSH版本是否一致,或者至少确保它们相互兼容。
- 使用
ssh -V
命令查看版本信息。
5. 用户名或主机名错误
问题描述:在尝试连接时使用了错误的用户名或主机名。
解决方案:
- 双重检查连接命令中使用的用户名和主机名是否正确。
6. 网络问题
问题描述:网络连接问题也可能阻止免密登录。
解决方案:
- 确保网络连接正常,可以尝试ping目标服务器来测试连通性。
7. SSH Agent问题
问题描述:如果你的私钥是加密的,那么需要确保SSH代理正在运行,并且私钥已经被添加到SSH代理中。
解决方案:
-
启动SSH代理并添加私钥:
eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_rsa
8. SELinux或AppArmor限制
问题描述:如果你的系统启用了SELinux或AppArmor,这些安全模块可能会阻止SSH服务访问必要的文件。
解决方案:
- 检查SELinux或AppArmor的日志文件,寻找相关的错误信息。
- 根据错误信息调整安全策略。
9. 日志文件
问题描述:查看日志文件可以帮助诊断具体的问题所在。
解决方案:
- 查看SSH服务的日志文件,通常是
/var/log/auth.log
或/var/log/secure
,查找与认证失败相关的错误信息。
通过逐一排查这些问题,你应该能够找到导致免密登录不起作用的具体原因,并采取相应的措施解决问题。
那能给.ssh目录下以及.ssh目录设置777权限吗为什么
虽然理论上你可以将 .ssh
目录和 ~/.ssh/authorized_keys
文件的权限设置为更宽松的权限(例如777),但这不是一个好主意,因为这会带来严重的安全风险。SSH服务设计时就考虑到了安全性,因此对文件权限有严格的要求。
为什么不能使用777权限?
-
安全性:
- 权限777意味着任何用户都可以读取、写入和执行该目录或文件。这意味着其他用户可以修改你的
.ssh
目录或~/.ssh/authorized_keys
文件,从而潜在地破坏你的安全设置。 - 权限700(
drwx------
)只允许文件所有者读取、写入和执行该目录,确保只有你本人可以访问这些文件。 - 权限600(
-rw-------
)只允许文件所有者读取和写入该文件,确保只有你本人可以访问这些文件的内容。
- 权限777意味着任何用户都可以读取、写入和执行该目录或文件。这意味着其他用户可以修改你的
-
SSH服务的要求:
- SSH服务器在处理认证时会检查文件权限。如果发现权限过于宽松,它会拒绝使用这些文件进行认证,以防止潜在的安全漏洞。
- 具体来说,如果
.ssh
目录的权限不是700,或者~/.ssh/authorized_keys
文件的权限不是600,SSH服务器可能会拒绝使用这些文件进行公钥认证。
如何设置正确的权限?
为了确保免密登录正常工作,建议你按照以下步骤设置正确的权限:
-
设置
.ssh
目录的权限:chmod 700 ~/.ssh
-
设置
~/.ssh/authorized_keys
文件的权限:chmod 600 ~/.ssh/authorized_keys
示例
假设你的用户名是 user
,目标服务器的IP地址是 192.168.1.100
,以下是完整的步骤:
-
生成SSH密钥对(如果还没有生成):
ssh-keygen -t rsa -b 4096
-
将公钥复制到目标服务器:
cat ~/.ssh/id_rsa.pub | ssh user@192.168.1.100 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
-
设置正确的权限:
ssh user@192.168.1.100 "chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"
-
测试连接:
ssh user@192.168.1.100
通过以上步骤,你应该能够成功配置免密登录,并确保系统的安全性。