SSH se restablece al puerto predeterminado al reiniciar

Cambié mi puerto SSH predeterminado en mi servidor doméstico (en el /etc/ssh/sshd_configarchivo) al puerto 54747, luego reinicié los servicios sshy sshd(nunca estoy seguro de cuál, así que hice ambos para estar seguro). Para probar mi configuración, me desconecté y luego volví a ingresar sin ningún problema.

Un par de días después, instalé actualizaciones aptas y luego reinicié mi servidor. Cuando intenté volver a SSH (en el puerto 54747), recibí un error de conexión rechazada.

Por alguna razón, intenté SSH en el puerto predeterminado, ¡y funcionó! Regresé para verificar el sshd_config, pero aún tenía el puerto personalizado. Así que reinicié los servicios sshy sshd, y volvió al comportamiento "normal" (ssh en el puerto 54747). Intenté reiniciar nuevamente, y la conexión se negó nuevamente ...

Alguien sabe lo que hice mal?

Detalles extra:

• Ubuntu 16.04.2 LTS
• El servidor también utiliza un HTPC, con una sesión abierta (mismo usuario que SSH) en mi televisor
• I SSH usando la clave RSA de mi computadora portátil, y he deshabilitado la autenticación de contraseña
• Solía ​​reiniciar con sudo reboot -h now, pero después de buscar, descubrí que algunas personas lo desaconsejaban, así que lo intenté sudo reboot, pero no hubo diferencias.

EDITAR Secuencia de eventos:

1. Cambie el puerto SSH de 22 a 54747 en /etc/ssh/sshd_config
2. Reinicie los servicios ssh y sshd
3. Finalizar sesión SSH actual
4. SSH vuelve a entrar con éxito en el puerto 54747
5. Reiniciar
6. Error de conexión SSH en el puerto 54747, pero exitoso en el puerto 22
7. Reinicie los servicios ssh y sshd
8. SSH nuevamente en el puerto 54747, error de conexión en el puerto 22
9. Reiniciar y volver a 6

EDITAR 1: netstat salida

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

EDITAR 2: service sshd status

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

EDITAR 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)

Como referencia, ATLAS es el nombre de host del servidor remoto, 192.168.1.27 es la IP de LAN de mi computadora portátil y el comando se ejecutó entre los pasos 6 y 7

ufw status

Status: inactive

EDITAR 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 puede ser "activado por socket" por systemd dependiendo de la configuración, lo que significa que inicialmente es systemd el que configura el puerto de escucha, y sshd solo se inicia cuando un cliente se conecta por primera vez. Esto es para acelerar el tiempo de inicio: los demonios de servicio solo se inician a pedido.

Sin embargo, esto significa que también debe configurar systemd en el puerto correspondiente. Encontrará la configuración del sistema en la /lib/systemd/system/ssh.socketque se enumeran ListenStream=22. Para anular esto, cree un archivo /etc/systemd/system/ssh.socket.d/port.conf(creando el directorio ssh.socket.dsi es necesario) que contenga:

[Socket]
ListenStream=
ListenStream=54747

Cambie el número al puerto deseado. La primera entrada en blanco borra el valor predeterminado anterior, y la entrada posterior agrega la nueva. Esto anula el valor predeterminado enviado /lib/systemd/system/ssh.sockety debe realizarse además del cambio /etc/ssh/sshd_config.

Luego, ejecute sudo systemctl daemon-reloadpara informarle a systemd sobre sus cambios y sudo systemctl reload sshsi su demonio ssh se estaba ejecutando anteriormente.

Verifique la configuración de su puerto en el /etc/ssh/sshd_configarchivo. Asegúrese de editar como sudo o un usuario en el grupo sudo. Todo lo que tiene que hacer para configurar el puerto es, en un tipo de línea Port 54747.Ahora, reinicie el servicio ssh ejecutando service sshd restart.Luego verifique que ssh esté escuchando en ese puerto ejecutando sudo netstat -lntp | grep ssh.Reiniciar y probar.

También verifique la configuración de su red. Si está en una red corporativa, asegúrese de estar en la vlan correcta.

A veces las cosas simplemente salen mal. Si estuviera en tu lugar, lo intentaría con:

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

ssh es el proceso del cliente que arbitra y mantiene una conexión de sesión de usuario con el servidor ssh. sshd es el demonio que se ejecuta en el servidor ssh para escuchar y autenticar las solicitudes de conexión ssh.

El archivo de configuración en el servidor sshd que se lee al iniciar el servicio sshd (que requiere privilegios de sudo para editar) es

/etc/ssh/sshd_config

El servicio debe comenzar desde

/etc/systemd/system/sshd.service

Para reiniciar sshd, lo que implicaría volver a leer el archivo sshd_config

sudo service sshd restart

Para ver qué puerto está escuchando el demonio sshd, así como otra información útil, sobre el tipo de servidor ssh

sudo service sshd status

Realice estos pasos en el orden especificado:

Reinicia el servidor ssh

Abra una sesión de terminal en el servidor ssh (no una conexión ssh en él)

Tipo hostname

Si hostname no devuelve el nombre del servidor ssh (Atlas en este caso), vuelva a realizar el paso anterior correctamente.

grep Port /etc/ssh/sshd_config - Anote el número de puerto. Debería ser el que especificó

sudo service sshd status

Si el estado informa que está activo, ejecutándose y escuchando en el puerto personalizado que especificó, entonces está bien en ese aspecto. De lo contrario, el inicio del servicio puede no estar llamando al archivo sshd_config que modificó, sino a otro archivo de configuración que contiene información predeterminada. Si el servicio no se inició (dice que está inactivo y no está activo y ejecutándose, entonces este es un problema diferente al que usted solicitó.

Es probable que estos pasos identifiquen la causa raíz del problema sobre el que está preguntando.

Para fines de prueba y para simplificar: en el lado del cliente, desde una sesión de terminal, ssh en el servidor ssh de la siguiente manera

ssh -l username -p 54747 hostname

Según los comentarios de OP, sospecho que sshd no se inicia en el arranque, pero se inicia correctamente cuando se invoca manualmente. Es posible que las conexiones ssh exitosas a través del puerto 22 NO se estén conectando al servidor ssh sino a otra cosa (por ejemplo, localhost). Para probar o desacreditar esto, después de conectarse a través de tipo ssh

hostname

Según lo que dice OP, supongo que el nombre de host no será el atlas del servidor ssh.

Para aislar aún más esto, después de reiniciar el servidor ssh pero antes de hacer nada más , desde una sesión de terminal en el tipo de servidor ssh (Atlas)

ssh localhost

Si esto falla, como debería, entonces

ssh -p 54747 localhost

Si esto tampoco funciona, eso confirmará los resultados obtenidos al ejecutar

sudo service sshd status

Probablemente haya respondido Y cuando apt detectó diferencias entre su sshd_config y la del paquete. Le pregunta si desea instalar la versión del paquete mantainer o conservar la suya.

Posibles causas en las que puedo pensar

1. Se inicia un binario sshd diferente en el arranque o se inicia sshd con una configuración diferente. Quizás systemd es el culpable aquí: tiene una forma diferente de cambiar el puerto, /usr/lib/systemd/system/sshd.socketaparentemente a través del archivo : https://www.vultr.com/docs/how-to-change-ssh-port-on-coreos
2. El / etc / o / etc / ssh correcto aún no está montado cuando se inicia sshd, ¿es un volumen separado en su máquina que se monta más adelante en el proceso de arranque?
3. sshd carece de permisos de lectura para el archivo de configuración en el momento del arranque, aunque no sé si sshd incluso comenzaría en ese momento.