SSH在重启时重置为默认端口

我将我的家庭服务器上的默认SSH端口（在/etc/ssh/sshd_config文件中）更改为端口54747，然后重新启动ssh和sshd服务（永远不知道哪一个，所以为了安全起见，我都这样做了）。为了测试我的配置，我先注销然后再重新登录没有任何问题。

几天后，我安装了apt更新，然后重新启动了服务器。当我尝试重新登录SSH（在端口54747上）时，出现连接拒绝错误。

出于某种原因，我尝试在默认端口上进行SSH，并且有效！我回去检查sshd_config，但是它仍然具有自定义端口。因此，我重新启动ssh和sshd服务，然后恢复为“常规”行为（端口54747上的ssh）。我尝试重新启动，但连接再次被拒绝...

有人知道我做错了吗？

额外细节：

• Ubuntu 16.04.2 LTS
• 服务器还使用了HTPC，电视上有一个打开的会话（与SSH相同的用户）
• 我使用笔记本电脑的RSA密钥进行SSH加密，并禁用了密码身份验证
• 我曾经使用进行过重新启动sudo reboot -h now，但是在搜索之后，我发现某些人不推荐使用它，因此我尝试了sudo reboot，但没有任何区别

编辑 事件序列：

1. 将SSH端口从22更改为54747 /etc/ssh/sshd_config
2. 重新启动SSH和SSHD服务
3. 结束当前的SSH会话
4. SSH成功​​通过端口54747重新登录
5. 重启
6. SSH连接错误在端口54747上，但在端口22上成功
7. 重新启动SSH和SSHD服务
8. SSH成功​​返回端口54747，端口22连接错误
9. 重新启动并返回到6

编辑1： netstat输出

rgo@ATLAS:~$ sudo netstat -lntp | grep :54747
rgo@ATLAS:~$ sudo netstat -lntp | grep :22
tcp6       0      0 :::22                   :::*                    LISTEN      1/init  

编辑2： service sshd status

● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
   Active: inactive (dead)

编辑3： lsof -i | grep ssh

systemd      1     root   46u  IPv6  42724      0t0  TCP ATLAS:ssh->192.168.1.27:49837 (ESTABLISHED)
systemd      1     root   49u  IPv6  14641      0t0  TCP *:ssh (LISTEN)
sshd      4088     root    3u  IPv6  42724      0t0  TCP ATLAS:ssh->192.168.1.27:49837 (ESTABLISHED)
sshd      4088     root    4u  IPv6  42724      0t0  TCP ATLAS:ssh->192.168.1.27:49837 (ESTABLISHED)
sshd      4202      rgo    3u  IPv6  42724      0t0  TCP ATLAS:ssh->192.168.1.27:49837 (ESTABLISHED)
sshd      4202      rgo    4u  IPv6  42724      0t0  TCP ATLAS:ssh->192.168.1.27:49837 (ESTABLISHED)

作为参考，ATLAS是远程服务器主机名，192.168.1.27是我的笔记本电脑的LAN IP，并且在步骤6和7之间执行了命令

ufw status

Status: inactive

编辑4： ps -ef |grep sshd

root      4088     1  0 22:40 ?        00:00:00 sshd: rgo [priv]
rgo       4202  4088  0 22:40 ?        00:00:00 sshd: rgo@pts/1 sshd

ssh可能由systemd进行“套接字激活”，具体取决于配置，这意味着最初由systemd设置监听端口，而sshd仅在客户端首次连接时启动。这是为了加快启动时间：服务守护进程仅按需启动。

但是，这意味着您还必须将systemd配置为匹配的端口。您将在/lib/systemd/system/ssh.socket列表中找到系统配置ListenStream=22。要覆盖此内容，请创建一个文件/etc/systemd/system/ssh.socket.d/port.conf（ssh.socket.d如果需要，请创建目录），该文件包含：

[Socket]
ListenStream=
ListenStream=54747

将数字更改为所需的端口。第一个空白条目将删除先前的默认值，而后一个条目将添加新的默认值。这将覆盖默认的默认值，除了更改外还/lib/systemd/system/ssh.socket必须完成。/etc/ssh/sshd_config

然后运行sudo systemctl daemon-reload以告知systemd您所做的更改以及sudo systemctl reload ssh您的ssh守护程序先前是否正在运行。

验证/etc/ssh/sshd_config文件中的端口设置。确保您以sudo或sudo组中的用户身份进行编辑。设置端口所需要做的只是，在一种类型的线路上，Port 54747.现在通过运行重新启动ssh服务，service sshd restart.然后通过运行sudo netstat -lntp | grep ssh.重新启动和测试来验证ssh正在侦听该端口。

还要检查您的网络设置。如果您在公司网络中，请确保您位于正确的VLAN中。

有时情况会出错。如果我在你的位置，我会尝试：

cp /etc/ssh/sshd_config $HOME
sudo apt-get --reinstall install openssh-server

ssh是仲裁和维护与ssh服务器的用户会话连接的客户端进程。sshd是在ssh服务器上运行的守护程序，用于侦听和验证ssh连接请求。

启动sshd服务（需要sudo权限进行编辑）时读取的sshd服务器上的配置文件为

/etc/ssh/sshd_config

服务应该从

/etc/systemd/system/sshd.service

重新启动sshd，这将涉及重新读取sshd_config文件

sudo service sshd restart

要查看ssh服务器类型上sshd守护程序正在侦听的端口以及其他有用的信息

sudo service sshd status

按指定顺序执行以下步骤：

重新启动ssh服务器

在ssh服务器上打开终端会话（而不是到其中的ssh连接）

类型 hostname

如果主机名未返回ssh服务器的名称（在本例中为Atlas），请正确地重做上一步。

grep Port /etc/ssh/sshd_config -记下端口号。应该是您指定的那个

sudo service sshd status

如果状态报告它处于活动状态，正在运行并且正在侦听您指定的自定义端口，那么您就可以做到这一点。如果不是，则服务启动可能不会调用您修改的sshd_config文件，而是另一个包含默认信息的配置文件。如果该服务未启动（例如已停止运行且未处于活动状态且正在运行），那么这是与您要求的问题不同的问题。

这些步骤可能会确定您所问问题的根本原因。

为了测试和简化：在客户端，从终端会话中，您可以按以下方式ssh进入ssh服务器：

ssh -l username -p 54747 hostname

根据OP反馈，我怀疑sshd不会在启动时启动，但在手动调用时确实可以正确启动。通过端口22成功的ssh连接很可能不是连接到ssh服务器，而是连接到其他设备（例如localhost）。通过SSH类型连接来证明或揭穿

hostname

根据OP的说法，我猜主机名不会是ssh服务器地图集。

要进一步隔离此问题，请在重新启动ssh服务器之后但在进一步执行此操作之前，将其与ssh服务器（Atlas）上的终端会话

ssh localhost

如果这样做失败，那么应该

ssh -p 54747 localhost

如果还是不行，那将确认运行时获得的结果

sudo service sshd status

当apt检测到sshd_config与程序包的差异时，您可能只是回答Y。它询问您是要安装软件包管理器的版本还是保留您的版本。

我能想到的可能原因

1. 引导时会启动不同的sshd二进制文件，或者使用不同的配置来启动sshd。也许systemd是这里的罪魁祸首-它显然有一种通过文件更改端口的方式/usr/lib/systemd/system/sshd.socket：https : //www.vultr.com/docs/how-to-change-ssh-port-on-coreos
2. sshd启动时，尚未安装正确的/ etc /或/ etc / ssh，它是您机器上的一个单独的卷，可以在引导过程中稍后安装吗？
3. sshd在启动时缺少对配置文件的读取权限，尽管我根本不知道sshd是否甚至会随后启动。