任务:假设我的远程服务器firewall
配置为仅允许我的特定家庭IP
连接port 22
,因此我并不担心此测试的安全性。也许我还计划使用非常复杂的用户名,例如“user_name_82391274829”
我可以SSH
像这样访问我的服务器吗?:
ssh user_name_82391274829@server
server:/#
换句话说,它只是登录,
不需要密码,也不需要 ssh-key。
注意:
它也应该适用于SCP
答案1
这其他答案有很多有效的观点。请阅读,因为我不会重复它们。我的答案是一份实用指南。
设置空密码在服务器上(我假设
user_name_82391274829
存在于系统中;chpasswd
需要根访问权限):printf '%s\n' 'user_name_82391274829:U6aMy0wojraho' | chpasswd -e
注意,这与完全没有密码不同。在我设置完全没有密码(
passwd -d user_name_82391274829
)之后,解决方案不起作用,因此请坚持使用上面的chpasswd -e
。sshd_config
服务器上的正确值:PasswordAuthentication yes PermitEmptyPasswords yes
调用
systemctl reload ssh.service
或等效命令来重新加载sshd
。
在 Debian 9 上测试。
答案2
我是否可以像这样通过 SSH 连接到我的服务器 [...] 它只需登录,无需密码,也无需 ssh 密钥。
是的,至少使用 OpenSSH 可以实现,通过禁用服务器的 sshd_config 文件中密码非空的要求。
它也应该与 SCP 兼容
SCP 没有自己的身份验证,它实际上只是调用ssh
远程连接。
我的远程服务器的防火墙配置为只允许我的特定家庭 IP 连接到端口 22,因此我并不担心这次测试的安全性。
这可不是什么好借口——IP 地址是最弱的身份验证形式之一。首先,服务器不知道连接是由您的实际 PC 建立的,还是由家庭网络上的受感染设备建立的,还是由使用您家庭 Wi-Fi 的客人/邻居建立的。
Linux 防火墙也更容易出现故障:例如,如果规则集中存在语法错误,它可能会恢复为在重新启动时允许来自任何地方的所有内容。(而如果您在 authorized_keys 中犯了一个错误,它仍然不允许任何人,除了有效的密钥条目。)
也许我还打算使用非常复杂的用户名,例如“user_name_82391274829”
你刚刚发明了一个密码。