编辑2:
由于流感由于病毒、深夜会议
以及对 SSH 的了解非常生疏,我犯了一个愚蠢的错误:
从 /etc/ssh/ 中删除了服务器的私钥,
因为我认为它们不属于那里。
我最近阅读的文章和文档
要么过于简单要么过于复杂,
我无法快速找到我需要的信息,
因此在晚上睡觉前我问了下面的问题。
现在我已经整理好了,你可以直接跳到我的答案。
我把这个问题留在这里,因为如果没有这个问题,评论就没有意义。
===============================
原始问题:
远程服务器不接受任何类型的 ssh 连接。
我现在唯一的访问权限是通过托管提供商的网站。
原因是 sshd 密钥配置错误。
(由于愚蠢的错误;它多年来一直运行良好,而我昨天把它搞砸了。)
虽然它有“密码验证是的",它不再询问,只是关闭连接。
设置 SSH 密钥的说明假定您可以从本地终端访问密码,以便将新密钥发送到服务器,但我没有。
仅有 mPanel 网络访问,让 sshd 再次接受密码的最简单方法是什么?
或者,有没有办法在服务器和客户端上设置密钥而无需传输文件?
我对此表示怀疑,因为 mpanel 没有复制/粘贴功能,所以我必须手动输入公钥(似乎不切实际)。
希望我可以仅通过编辑 sshd 配置和/或隐藏一些文件来做到这一点。
它是带有 SSH 6.6 的 Centos7(与家里的 Manjaro 上的 SSH 9 兼容)。
之前,当密钥认证失败时,它会要求输入密码,但我已经很久没有使用密码了,以至于一时找不到密码,于是继续尝试更改密钥配置(通过 Filezilla 中的 sftp 更改文件)。
经过几次失败的登录尝试后,它不再要求输入密码,filezilla 连接也中断了。
(多年没有阅读 ssh 文档,忘记了一些要点。)
我想知道是否在某处设置了标志,并且 sshd 在该标志被清除之前不会要求输入密码……?
编辑:
‘KEXINIT sent’之后连接立即关闭。
这是因为本地和远程密钥不匹配。
debug1: SSH2_MSG_KEXINIT sent
Connection closed by ... (the server)
问题是“为什么它不要求输入密码?”。
但我甚至不关心为什么,我只想重置该 sshd 守护进程,
目前还不太清楚如何重置。
我想我很快就会重新启动该服务;也许会更改一些配置。
我正在阅读 redhat EL7 文档,但这需要一段时间……;)
fail2ban 未安装。我根本没有尝试使用 ssh 的任何密码,因为在我找到密码之前它就停止询问了;我曾在 mpanel 中使用过密码,它是正确的。
我希望获得的是有关如何安全轻松地清除 sshd 的一般信息,而不是诊断出了什么问题。
需要将其设置为接受密码,这样我才能使用新密钥对其进行配置。现在正在搜索有关 sshd 服务器设置的信息(大多数信息是关于客户端设置的)。
答案1
Martin 的评论为我指明了正确的方向。
这个问题的简短答案是:
在服务器上,在 /etc/ssh/ 中删除剩余的密钥,然后重新启动 sshd 服务。
这会导致 sshd 服务创建新的主机密钥对。
服务器使用其主机密钥对之一来设置加密通道
以与客户端进行协商;没有这个,它就无法要求密码,
因为密码不能以未加密的形式传输。
我已经删除了私钥,仅靠公钥是无法做到这一点的。
下面是我所需要的更多信息,
当时我无法在文档中找到所有信息。
(它在那里,但与许多其他细节混在一起。)
公钥认证的简单配置
文件布局:
client server
/etc/ssh/ /etc/ssh/
ssh_config sshd_config
|<---pubkey--- 'ssh_host' key pair
|
/<user>/.ssh/ | /<user>/.ssh/
known_hosts <-|
'id' key pair ---pubkey--> authorized_keys
文件“known_hosts”和“authorized_keys”
各自包含一个公钥列表,每行一个密钥。
/<user>/
可以是/root/
,以及任何/home/<username>/
。root
的工作方式与其他相同。
事件顺序(简化):
服务器设置
'ssh_host' 密钥对在 sshd 首次启动时创建,
如果密钥对丢失,sshd 会在每次重新启动时创建替换密钥对客户端设置
用户通过运行 ssh-keygen 创建“id”密钥对,
用户通过运行 ssh-copy-id 将公钥发送到服务器
(必须启用密码验证才能使 ssh-copy-id 正常工作)联系
服务器将“ssh_host”公钥发送给客户端,
客户端检查其是否在known_hosts中
[第一次连接到新服务器或密钥已更改的服务器时,
客户端会询问用户是否可以将服务器的密钥添加到known_hosts中。
这是不是好吧,如果你不期待的话]客户端将用户的“id”公钥发送到服务器,
服务器检查它是否在用户的authorized_keys中
[如果不在,客户端的用户就无法登录服务器]
笔记
密钥可以在用户之间“交叉”:
例如,将客户端用户的密钥放在服务器根的authorized_keys中
,如果PermitRootLogin不是“no”,那么该用户可以以root身份登录服务器。
这就是我如何以 root 身份连接 Filezilla。
在 Manjaro 上的 KDE 中,无法以 root 身份运行 X-windows 应用程序,
因此 Fz 需要以我的身份运行,但以 root 身份登录服务器;
它无权访问 root 的 id 密钥,因此必须使用我的密钥。 [在服务器上,PermitRootLogin 大部分时间都处于关闭状态,我 只在 Filezilla 是进行某些重新配置的最佳工具时短暂地
将其打开。]