Qu'est-ce qui cause des problèmes SSH après le redémarrage d'un serveur 14.04?

Pourquoi le redémarrage d'un serveur exécutant Ubuntu 14.04 me donne-t-il des erreurs de «connexion refusée»?

Je vois ssh: connect to host <IP-address-here> port 22: Connection refusedmais seulement pour 14.04 et seulement après le redémarrage. J'utilise 12.04 Desktop à la maison. Comment puis-je résoudre ce problème?

Pour clarifier la question, voici ce qui fonctionne ou ne fonctionne pas pour moi:

• SSH dans une nouvelle installation de 12.04> déconnexion> SSH à nouveau> fonctionne
• SSH dans une nouvelle installation de 12.04> redémarrer> SSH à nouveau> fonctionne
• SSH dans une nouvelle installation de 14.04> déconnexion> SSH à nouveau> fonctionne
• SSH dans une nouvelle installation de 14.04> redémarrage> SSH à nouveau> Connexion refusée

Le problème que je rencontre est unique à 14.04 et ne se produit qu'après le redémarrage. J'ai plusieurs serveurs exécutant 12.04 avant cela et tout fonctionne toujours parfaitement. J'ai un nouveau serveur sur lequel je veux utiliser 14.04 et je veux comprendre ce qui ne va pas. Aucune suggestion?

Voici ce que j'ai essayé jusqu'à présent:

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

Traceroute fonctionne très bien, j'obtiens une réponse du serveur sur le port SSH 22.

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

Il semble que ssh sur le serveur 14.04 soit configuré pour démarrer au démarrage (comme prévu).

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

Edit: Voici le syslog entier d'une machine fraîchement créée . Je l'ai créé, SSH dans la reboot nowcommande & émis , puis j'ai obtenu une erreur de connexion refusée après avoir attendu qu'il redémarre et essayé SSH dans un deuxième temps. Redémarrage dur via le panneau de contrôle d'hébergement et maintenant la connexion SSH fonctionne à nouveau.

Réponse rapide:

SSH n'est pas le problème. La commande que vous utilisez pour redémarrer est le problème: ne faites pas reboot now, ne faites pas rebootou ne shutdown -r nowredémarrez pas votre système.

La syntaxe de commande ( depuis le 13.04 ) est:

reboot [OPTION]...  [REBOOTCOMMAND]

Le REBOOTCOMMANDn'a jamais existé auparavant. En 12.04, votre nowétait juste ignoré mais maintenant il est utilisé ... Et il casse tout.

Réponse longue, avec mes résultats de tests et explication:

J'ai un problème similaire avec certains serveurs exécutant 14.04 ET en VPS (hébergé chez le fournisseur français OVH - exécutant OpenVZ) ET en faisant reboot nowà l'intérieur du serveur lui-même.

Comme vous, j'ai lancé la commande à reboot nowpartir de la console (connecté à l'aide de SSH). Quelques secondes après avoir appuyé sur RETURN, ma session est automatiquement déconnectée. Comme vous, je n'ai jamais pu me reconnecter au serveur via SSH après avoir émis cette commande.

J'ai donc décidé d'ouvrir la console KVM fournie par OVH. (émulation de l'accès direct à l'aide du clavier et de l'écran sur un serveur physique pour ce type de serveur virtuel).

J'ai pu me connecter à ma machine et j'ai vu qu'elle entrait en mode mono-utilisateur, attendant que j'appuie sur CTRL+ Dpour continuer ou que j'entre le mot de passe root pour passer en mode maintenance. J'ai appuyé sur la combinaison de touches pour laisser le processus se poursuivre et j'ai ensuite pu SSH dans mon système à nouveau. Quelle a été ma surprise de voir, après avoir couru uptime, que le temps de disponibilité n'était pas de 2 ou 3 minutes mais encore beaucoup de jour: reboot nowexécuté à l'intérieur d'un VPS Ubuntu 14.04 ne redémarre pas vraiment, mais demande simplement à passer en mode mono-utilisateur!

De cela, j'ai appris à ne jamais demander un redémarrage depuis mon VPS mais à le demander à partir de la commande fournie sur l'interface de gestion de l'hébergeur.

Il n'y a donc aucun problème avec votre installation SSH. Le problème est lorsque vous tapez reboot now. En fait, je l'ai également testé par la suite, si vous aviez tapé reboot(juste le mot, pas d'option), il aurait fait ce que vous aviez l'intention de faire: redémarrer le serveur.

À l'aide rebootd'un argument (à partir de la page de manuel), appelez la commande shutdownavec les arguments donnés. Et en effet, si j'exécute shutdown now, j'ai le même comportement: le système n'est pas redémarré, il passe en mode mono-utilisateur.

Remarque: il semble que ce soit le comportement souhaité car le message apparaissant à l'écran après avoir cliqué sur l'exécution de cette commande dit quelque chose comme:

Le système passera en mode maintenance

Mode maintenance ou mode mono-utilisateur, cela représente la même chose, un niveau d'exécution avec plus qu'un shell, pas de réseau, pas de processus réseau, ...

Cela peut être déroutant, mais notez que l'utilisation correcte de shutdownest, par exemple: shutdown -h nowpour arrêter le système maintenant ou shutdown -r nowpour le redémarrer maintenant. Je ne savais pas que shutdown nowcela ne ferait que mettre le système en mode mono-utilisateur. Je fais habituellement init Spour y parvenir.

Je suis peut-être en retard, et cela peut être évident, mais ce qui a fonctionné pour moi a été de vérifier le fichier de configuration /etc/ssh/sshd_config: l'exécution du démon avec /etc/init.d/ssh startou toute autre combinaison a montré que le service était en cours d'exécution même s'il ne l'était pas, mais si je lance l'exécutable avec son chemin absolu (dans mon cas /usr/sbin/sshd), j'ai vu qu'il y avait un "0B" ajouté à la fin du fichier de configuration qui a causé une erreur au démarrage, le supprimer a résolu le problème.

Une autre cause potentielle est la ufwperte de la configuration de la règle de port SSH. Cela m'est arrivé à au moins une ou deux fois, où après avoir appliqué des mises à jour et redémarré, la configuration du pare-feu me bloquait l'accès au serveur. L'utilisation de la console VPS de mon hébergeur m'a permis d'accéder à la machine et de diagnostiquer le problème. Exemple ci-dessous montrant le problème (c.-à-d. Aucune entrée pour le port 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)

Réactiver le port comme suit fait l'affaire:

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

Pour mon système, le problème était que le script d'initialisation ssh /etc/init.d/sshétait le seul à vérifier la présence de la version la plus récente d'init.

Donc, /etc/init.d/sshne démarre pas ssh,parce qu'il croit que cela commencera upstart.

Dans mon cas, upstart ne démarre pas à cause de ma configuration particulière:

Il y avait une configuration correcte dans /etc/init/ssh.conf, mais il y avait aussi un /etc/init/ssh.overridefichier contenant manual, ce qui signifie qu'il sshdevrait être démarré manuellement.

Ce fichier a été créé par le get-remnux.shscript d'installation.

Le démarrage manuel ou la suppression du /etc/init/ssh.overridefichier résout le problème.