Cosa causa i problemi SSH dopo il riavvio di un server 14.04?

Perché il riavvio di un server che esegue Ubuntu 14.04 mi dà errori "Connessione rifiutata"?

Vedo ssh: connect to host <IP-address-here> port 22: Connection refusedma solo per 14.04 e solo dopo il riavvio. Sto usando 12.04 Desktop a casa. Come posso risolvere questo problema?

Per chiarire la domanda, ecco cosa funziona o non funziona per me:

• SSH in una nuova installazione di 12.04> logout> SSH in di nuovo> funziona
• SSH in una nuova installazione di 12.04> riavvia> SSH di nuovo> funziona
• SSH in una nuova installazione di 14.04> logout> SSH in di nuovo> funziona
• SSH in una nuova installazione di 14.04> riavvio> SSH di nuovo> Connessione rifiutata

Il problema che sto riscontrando è unico per 14.04 e si verifica solo dopo il riavvio. Ho diversi server con 12.04 prima e tutto funziona ancora perfettamente. Ho un nuovo server su cui voglio usare 14.04 e voglio capire cosa non va. Eventuali suggerimenti?

Ecco cosa ho provato finora:

sudo traceroute -p 22 -T <IP-address-here>

Traceroute funziona bene, ricevo una risposta dal server sulla porta SSH 22.

initctl list
...
ssh start/running, process 23371
...

Sembra che ssh sul server 14.04 sia impostato per l'avvio all'avvio (come previsto).

tom@Desktop:~$ ssh -vvv root@<IP-address-here>
OpenSSH_5.9p1 Debian-5ubuntu1.4, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to <IP-address-here> [<IP-address-here>] port 22.
debug1: connect to address <IP-address-here> port 22: Connection refused
ssh: connect to host <IP-address-here> port 22: Connection refused

Modifica: ecco l' intero syslog da una macchina appena creata . L'ho creato, SSH ha eseguito il reboot nowcomando e ha emesso il comando, quindi ho ricevuto un errore di connessione rifiutata dopo aver atteso il riavvio e aver provato a SSH per la seconda volta. Riavvio forzato tramite pannello di controllo di hosting e ora la connessione SSH funziona di nuovo.

Risposta rapida:

SSH non è il problema. Il comando che usi per riavviare è il problema: non fare reboot now, fare rebooto shutdown -r nowriavviare il sistema.

La sintassi del comando ( dal 13.04 ) è stata:

reboot [OPTION]...  [REBOOTCOMMAND]

Non è REBOOTCOMMANDmai esistito prima. Nel 12.04, il tuo è nowstato appena ignorato, ma ora viene utilizzato ... E sta rompendo tutto.

Risposta lunga, con i risultati dei test e la spiegazione:

Ho un problema simile con alcuni server che eseguono 14.04 E in VPS (ospitato dal provider OVH francese - che esegue OpenVZ) E quando lo faccio reboot nowall'interno del server stesso.

Come te ho emesso il comando reboot nowdalla console (effettuato l'accesso tramite SSH). Qualche secondo dopo aver premuto RETURN, la mia sessione viene automaticamente disconnessa. Come te non sono mai stato in grado di riconnettermi al server tramite SSH dopo aver emesso questo comando.

Quindi, ho deciso di aprire la console KVM fornita da OVH. (emulando l'accesso diretto tramite tastiera e schermo su un server fisico per questo tipo di server virtuale).

Sono stato in grado di connettermi alla mia macchina e ho visto che stava entrando in modalità utente singolo, aspettando che io premessi CTRL+ Dper continuare o per inserire la password di root per passare alla modalità manutenzione. Ho premuto la combinazione di tasti per avviare il processo e poi sono stato in grado di accedere nuovamente al mio sistema. Qual è stata la mia sorpresa vedere, dopo aver eseguito uptime, che il tempo di attività non è stato di 2 o 3 minuti ma ancora un sacco di giorni: reboot noweseguito all'interno di un Ubuntu 14.04 VPS non si riavvia davvero, ma sta solo chiedendo di passare alla modalità Utente singolo!

Da questo, ho imparato a non chiedere mai un riavvio dal mio VPS ma a richiederlo dal comando fornito sull'interfaccia di gestione dell'hoster.

Quindi non ci sono problemi con l'installazione di SSH. Il problema è quando si digita reboot now. In effetti, l'ho provato anche in seguito, se avessi digitato reboot(solo la parola, nessuna opzione), avrebbe fatto quello che volevi fare: riavviare il server.

Usando rebootcon un argomento (dalla pagina man) chiama il comando shutdowncon gli argomenti dati. E infatti, se eseguo shutdown now, ho lo stesso comportamento: il sistema non viene riavviato, passa in modalità utente singolo.

Nota: sembra che si tratti del comportamento previsto poiché il messaggio che appare sullo schermo dopo aver eseguito questo comando dice qualcosa del tipo:

Il sistema verrà portato in modalità manutenzione

Modalità di manutenzione o modalità utente singolo, questo rappresenta lo stesso, un runlevel con più di una shell, nessuna rete, nessun processo di rete, ...

Ciò può essere fonte di confusione, ma si noti che l'uso corretto di shutdownè, ad esempio: shutdown -h nowarrestare il sistema ora o shutdown -r nowriavviarlo ora. Non sapevo che shutdown nowavrebbe portato il sistema in modalità utente singolo. Di solito lo faccio init Sper raggiungere questo obiettivo.

Potrei essere in ritardo, e può essere ovvio, ma ciò che ha funzionato per me è stato controllare il file di configurazione /etc/ssh/sshd_config: eseguire il demone con /etc/init.d/ssh starto qualsiasi altra combinazione ha mostrato che il servizio era in esecuzione anche se non lo era, ma se lancio l'eseguibile con il suo percorso assoluto (nel mio caso /usr/sbin/sshd) ho visto che alla fine del file di configurazione c'era uno "0B" che causava un errore all'avvio, rimuovendolo risolto il problema.

Un'altra potenziale causa sta ufwperdendo la configurazione della regola della porta SSH. Questo mi è successo in almeno una o due occasioni, in cui dopo aver applicato gli aggiornamenti e riavviato, la configurazione del firewall mi stava bloccando l'accesso al server. L'utilizzo della console VPS del mio provider di hosting mi ha permesso di accedere al computer e diagnosticare il problema. Esempio di seguito che mostra il problema (ovvero nessuna voce per la porta 22):

user@host:~$ sudo ufw status verbose
[sudo] password for user:
Status: active
Logging: on (low)
    Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
80,443/tcp (Nginx Full)    ALLOW IN    Anywhere
25/tcp                     ALLOW IN    Anywhere
143                        ALLOW IN    Anywhere
110                        ALLOW IN    Anywhere
993/tcp (Dovecot Secure IMAP) ALLOW IN    Anywhere
995/tcp (Dovecot Secure POP3) ALLOW IN    Anywhere
25/tcp (Postfix)           ALLOW IN    Anywhere
465/tcp (Postfix SMTPS)    ALLOW IN    Anywhere
80,443/tcp (Nginx Full (v6)) ALLOW IN    Anywhere (v6)
25/tcp (v6)                ALLOW IN    Anywhere (v6)
143 (v6)                   ALLOW IN    Anywhere (v6)
110 (v6)                   ALLOW IN    Anywhere (v6)
993/tcp (Dovecot Secure IMAP (v6)) ALLOW IN    Anywhere (v6)
995/tcp (Dovecot Secure POP3 (v6)) ALLOW IN    Anywhere (v6)
25/tcp (Postfix (v6))      ALLOW IN    Anywhere (v6)
465/tcp (Postfix SMTPS (v6)) ALLOW IN    Anywhere (v6)

Riattivare la porta come segue fa il trucco:

user@host:~$ sudo ufw allow ssh
Rule added
Rule added (v6)

Per il mio sistema il problema era che lo script ssh init /etc/init.d/sshera l'unico che controllava la presenza della versione upstart di init.

Quindi /etc/init.d/sshnon inizia ssh,perché crede che sarà avviato da upstart.

Nel mio caso, upstart non si avvia a causa della mia particolare configurazione:

C'era una configurazione corretta in /etc/init/ssh.conf, ma c'era anche un /etc/init/ssh.overridefile contenente manual, il che significa che sshdovrebbe essere avviato manualmente.

Questo file è stato creato dallo get-remnux.shscript di installazione.

L'avvio manuale o la rimozione del /etc/init/ssh.overridefile risolve il problema.