SSH ripristina la porta predefinita al riavvio

Ho cambiato la mia porta SSH predefinita sul mio server di casa (nel /etc/ssh/sshd_configfile) alla porta 54747, quindi ho riavviato i servizi sshe sshd(non sono sicuro di quale quindi ho fatto entrambi solo per sicurezza). Per testare la mia configurazione, mi sono disconnesso e poi di nuovo senza problemi.

Un paio di giorni dopo, ho installato gli aggiornamenti apt, quindi ho riavviato il mio server. Quando ho provato a reinserire SSH (sulla porta 54747), ho riscontrato un errore di connessione rifiutata.

Per qualche motivo, ho provato a SSH sulla porta predefinita e ha funzionato! Sono tornato a controllare sshd_config, ma aveva ancora la porta personalizzata. Quindi ho riavviato i servizi sshe sshd, e sono tornato al comportamento "normale" (ssh sulla porta 54747). Ho provato a riavviare di nuovo e la connessione ha rifiutato di nuovo ...

Qualcuno sa cosa ho fatto di sbagliato?

Dettagli extra:

• Ubuntu 16.04.2 LTS
• Il server viene anche utilizzato un HTPC, con una sessione aperta (stesso utente di SSH) sulla mia TV
• Ho SSH usando la chiave RSA del mio laptop e ho disabilitato la password auth
• Ero solito riavviare sudo reboot -h now, ma dopo aver cercato, ho scoperto che era scoraggiato da alcune persone, quindi ho provato sudo reboot, ma nessuna differenza

EDIT Sequenza di eventi:

1. Cambia la porta SSH da 22 a 54747 pollici /etc/ssh/sshd_config
2. Riavvia i servizi ssh e sshd
3. Termina la sessione SSH corrente
4. SSH rientra correttamente sulla porta 54747
5. Reboot
6. Errore di connessione SSH sulla porta 54747, ma riuscito sulla porta 22
7. Riavvia i servizi ssh e sshd
8. SSH è tornato correttamente sulla porta 54747, errore di connessione sulla porta 22
9. Riavvia e torna a 6

EDIT 1: netstat output

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

MODIFICA 2: service sshd status

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

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

Per riferimento, ATLAS è il nome host del server remoto, 192.168.1.27 è l'IP LAN del mio laptop e il comando è stato eseguito tra i passaggi 6 e 7

ufw status

Status: inactive

MODIFICA 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 può essere "attivato dal socket" da systemd a seconda della configurazione, il che significa che inizialmente è systemd che imposta la porta di ascolto e sshd viene avviato solo quando un client si connette per la prima volta. Questo per accelerare i tempi di avvio: i demoni di servizio vengono avviati solo su richiesta.

Tuttavia, ciò significa che è necessario configurare anche systemd sulla porta corrispondente. Troverai la configurazione del sistema in /lib/systemd/system/ssh.socketquali elenchi ListenStream=22. Per sovrascrivere questo, crea un file /etc/systemd/system/ssh.socket.d/port.conf(creando la directory ssh.socket.dse necessario) che contiene:

[Socket]
ListenStream=
ListenStream=54747

Modificare il numero sulla porta desiderata. La prima voce vuota cancella il valore predefinito precedente e la voce successiva aggiunge quella nuova. Questo sostituisce l'impostazione predefinita fornita /lib/systemd/system/ssh.sockete deve essere eseguito oltre alla modifica /etc/ssh/sshd_config.

Quindi esegui sudo systemctl daemon-reloadper dire a systemd delle tue modifiche e sudo systemctl reload sshse il tuo demone ssh era precedentemente in esecuzione.

Verifica le impostazioni della porta nel /etc/ssh/sshd_configfile. Assicurati di modificare come sudo o come utente nel gruppo sudo. Tutto quello che devi fare per impostare la porta è, su un tipo di linea Port 54747.Ora, riavvia il servizio ssh eseguendo service sshd restart.Quindi verifica che ssh sia in ascolto su quella porta eseguendo sudo netstat -lntp | grep ssh.Riavvia e testa.

Controlla anche le impostazioni di rete. Se sei su una rete aziendale, assicurati di essere nel vlan corretto.

A volte le cose vanno male. Se fossi al tuo posto, proverei con:

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

ssh è il processo client che arbitra e mantiene una connessione di sessione utente al server ssh. sshd è il demone che viene eseguito sul server ssh per ascoltare e autenticare le richieste di connessione ssh.

Il file di configurazione sul server sshd che viene letto all'avvio del servizio sshd (che richiede i privilegi sudo per la modifica) è

/etc/ssh/sshd_config

Il servizio dovrebbe iniziare fuori

/etc/systemd/system/sshd.service

Riavviare sshd che implicherebbe la rilettura del file sshd_config

sudo service sshd restart

Per vedere quale porta sta ascoltando il demone sshd, così come altre informazioni utili, sul tipo di server ssh

sudo service sshd status

Esegui questi passaggi nell'ordine specificato:

Riavvia il server ssh

Apri una sessione terminale sul server SSH (non una connessione SSH in esso)

genere hostname

Se hostname non restituisce il nome del server ssh (in questo caso Atlas) ripetere il passaggio precedente correttamente.

grep Port /etc/ssh/sshd_config - annotare il numero di porta. Dovrebbe essere quello che hai specificato

sudo service sshd status

Se lo stato segnala che è attivo, in esecuzione e in ascolto sulla porta personalizzata specificata, allora sei bravo a farlo. In caso contrario, l'avvio del servizio potrebbe non chiamare il file sshd_config modificato ma un altro file di configurazione che contiene informazioni predefinite. Se il servizio non è stato avviato (dice morto e non attivo e in esecuzione, allora questo è un problema diverso da quello che hai chiesto.

Questi passaggi probabilmente identificheranno la causa principale del problema che stai chiedendo.

A scopo di test e per semplicità: sul lato client, da una sessione di terminale si entra nel server ssh come segue

ssh -l username -p 54747 hostname

Sulla base del feedback OP, sospetto che sshd non si avvii all'avvio ma si avvii correttamente quando viene invocato manualmente. Le connessioni ssh riuscite tramite la porta 22 potrebbero NON essere connesse al server ssh ma a qualcos'altro (ad esempio localhost). Per dimostrarlo o ridimensionarlo, dopo aver effettuato il collegamento tramite tipo ssh

hostname

Sulla base di ciò che OP sta dicendo, suppongo che il nome host non sia l'atlante del server SSH.

Per isolare ulteriormente questo, dopo aver riavviato il server SSH ma prima di fare qualsiasi altra cosa , da una sessione terminale sul tipo di server SSH (Atlas)

ssh localhost

Se questo fallisce, come dovrebbe, allora

ssh -p 54747 localhost

Se questo non funziona, ciò confermerà i risultati ottenuti durante l'esecuzione

sudo service sshd status

Probabilmente hai appena risposto a Y quando apt ha rilevato differenze tra il tuo sshd_config e quello del pacchetto. Chiede se si desidera installare la versione di Package Mantainer o conservare la propria.

Possibili cause a cui riesco a pensare

1. Un diverso binario sshd viene avviato all'avvio o sshd viene avviato con una diversa configurazione. Forse systemd è il colpevole qui - ha un modo diverso di cambiare porta, /usr/lib/systemd/system/sshd.socketapparentemente tramite file : https://www.vultr.com/docs/how-to-change-ssh-port-on-coreos
2. Il / etc / o / etc / ssh corretto non è ancora montato all'avvio di sshd, è un volume separato sul computer che viene montato successivamente nel processo di avvio?
3. sshd non ha i permessi di lettura per il file di configurazione al momento dell'avvio, anche se non so se sshd sarebbe nemmeno iniziato.