Quelles sont les causes 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 l'erreur "Connexion refusée"?
Je vois ssh: connect to Host <IP-address-here> port 22: Connection refused mais 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 dans de nouveau> fonctionne
- SSH dans une nouvelle installation de 12.04> redémarrage> SSH dans à nouveau> fonctionne
- SSH dans une nouvelle installation de 14.04> déconnexion> SSH dans à nouveau> fonctionne
- SSH dans une nouvelle installation de 14.04> redémarrage> SSH dans à nouveau> connexion refusée
Le problème que je rencontre est unique à 14.04 et ne survient qu'après le redémarrage. J'ai plusieurs serveurs en cours d'exécution 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 bien, je reçois une réponse du serveur sur le port 22 SSH.
initctl list
...
ssh start/running, process 23371
...
On dirait que ssh sur le serveur 14.04 est 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 & a émis la commande reboot now, puis une erreur de connexion a été refusée après avoir attendu le redémarrage et essayé de SSH une deuxième fois. Redémarrage difficile via le panneau de configuration d'hébergement et 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, faites reboot ou shutdown -r now pour redémarrer votre système.
La syntaxe de la commande ( depuis le 13.04 ) a été la suivante:
reboot [OPTION]... [REBOOTCOMMAND]
Le REBOOTCOMMAND n'avait jamais existé auparavant. Dans 12.04, votre now était simplement ignoré, mais maintenant il est utilisé ... Et ça 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 AND dans VPS (hébergé chez le fournisseur français OVH - exécutant OpenVZ) ET lorsque je fais reboot now à l'intérieur du serveur lui-même.
Comme vous, j’ai lancé la commande reboot now à partir de la console (connectée à l’aide de SSH). Quelques secondes après j'ai appuyé RETURN, ma session est automatiquement déconnectée. Comme vous, je n'ai jamais été en mesure de vous reconnecter au serveur via SSH après avoir exécuté 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+D pour continuer ou pour entrer le mot de passe root pour passer en mode maintenance. J'ai appuyé sur la combinaison de touches pour laisser le processus se poursuivre, puis j'ai pu à nouveau SSH dans mon système. Quelle était ma surprise de voir, après avoir lancé uptime, que le temps de disponibilité n’était pas de 2 ou 3 minutes, mais qu’il restait beaucoup de jours: reboot now exécuté dans un Ubuntu 14.04 VPS ne redémarre pas vraiment, mais demande simplement à passer en mode mono-utilisateur!
De là, j'ai appris à ne jamais demander de redémarrage dans mon VPS mais à le demander à l'aide de la commande fournie sur l'interface de gestion de l'hébergeur.
Ainsi, il n'y a pas de problème avec votre installation SSH. Le problème est lorsque vous tapez reboot now. En fait, je l’ai testé par la suite aussi, si vous aviez tapé reboot (juste le mot, pas d’option), cela aurait fait ce que vous aviez l’intention de faire: redémarrer le serveur.
Pour utiliser reboot avec un argument (tiré de la page de manuel), appelez la commande shutdown avec 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 semblerait que ce soit le comportement souhaité car le message apparaissant à l'écran après avoir exécuté cette commande indique quelque chose comme:
Le système sera amené en mode maintenance
En mode maintenance ou en mode mono-utilisateur, cela représente la même chose, un niveau d'exécution avec plus d'un Shell, pas de réseau, pas de processus réseau, ...
Cela peut prêter à confusion, mais notez que l'utilisation correcte de shutdown est par exemple: shutdown -h now pour arrêter le système maintenant ou shutdown -r now pour le redémarrer maintenant. Je ne savais pas que shutdown now ne ferait que mettre le système en mode mono-utilisateur. Je fais habituellement init S pour y parvenir.
Une autre cause potentielle est ufw qui perd la configuration de la règle de port SSH. Cela m'est arrivé à au moins une ou deux reprises. Après avoir appliqué les mises à jour et redémarré, la configuration du pare-feu m'empêchait d'accéder au serveur. L'utilisation de la console VPS de mon fournisseur d'hébergement m'a permis d'accéder à la machine et de diagnostiquer le problème. Exemple ci-dessous montrant le problème (c'est-à-dire 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éactivez le port comme suit:
user@Host:~$ Sudo ufw allow ssh
Rule added
Rule added (v6)
Je suis peut-être en retard et cela peut paraître évident, mais ce qui a bien fonctionné pour moi a été de vérifier le fichier de configuration /etc/ssh/sshd_config: exécuter le démon avec /etc/init.d/ssh start ou 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 le exécutable avec son chemin absolu (dans mon cas, /usr/sbin/sshd), j’ai vu qu’un "0B" était ajouté à la fin du fichier de configuration, ce qui provoquait une erreur lors du démarrage. Le fait de le supprimer a résolu le problème.