web-dev-qa-db-fra.com

Serveur: après la mise à niveau de 16.04 à 18.04, ssh et ftp refusent les connexions

J'ai mis à niveau mon serveur hébergé distant du 16.04 au 18.04. Les premiers pas semblaient bien se dérouler sans erreurs ni avertissements. Jusqu'à l'étape de redémarrage.

J'ai confirmé l'étape de redémarrage. Après cela, la connexion SSH a bien sûr été fermée. J'ai attendu au moins 4 heures (je ne sais pas exactement combien de temps, mais au moins 4 heures), mais je ne pouvais toujours pas obtenir de connexions ssh et sftp.

Je peux

  • cingler avec succès le serveur
  • faire des redémarrages difficiles via l'interface Web de mon hébergeur

  • Je sais pertinemment que les cronjobs fonctionnent toujours

  • Je reçois toutes les quelques minutes des courriels contenant des erreurs provenant des tâches cron (Boinc a été désinstallé lors du processus de mise à niveau et ne peut donc pas être démarré; le cronjob Nextcloud échoue car Postgres ne semble pas être en cours d'exécution)

  • puisqu'il s'agit d'un serveur distant et que je n'ai aucun accès, je ne peux ni exécuter de commandes ni lire/écrire de fichiers

J'utilise normalement un gestionnaire de connexion, mais dans l'espoir d'obtenir plus d'informations que "connexion refusée", j'ai également essayé de l'exécuter directement dans la console. Résultat:

[croydon ~]$ ssh -vvv <sever-ip>
OpenSSH_7.9p1, OpenSSL 1.1.1 FIPS  11 Sep 2018
debug1: Reading configuration data /etc/ssh/ssh_config
debug3: /etc/ssh/ssh_config line 52: Including file /etc/ssh/ssh_config.d/05-redhat.conf depth 0
debug1: Reading configuration data /etc/ssh/ssh_config.d/05-redhat.conf
debug3: /etc/ssh/ssh_config.d/05-redhat.conf line 2: Including file /etc/crypto-policies/back-ends/openssh.config depth 1
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug3: gss kex names ok: [gss-gex-sha1-,gss-group14-sha1-,gss-group1-sha1-]
debug3: kex names ok: [[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1]
debug1: /etc/ssh/ssh_config.d/05-redhat.conf line 8: Applying options for *
debug2: resolve_canonicalize: hostname <sever-ip> is address
debug2: ssh_connect_direct
debug1: Connecting to <sever-ip> [<sever-ip>] port 22.
debug1: connect to address <sever-ip> port 22: Connection refused
ssh: connect to Host <sever-ip> port 22: Connection refused

J'ai lu qu'Ubuntu 18.04 n'accepte pas certains chiffrements plus anciens, mais je suppose que ce journal règle ce problème potentiel.

Y a-t-il un espoir de rétablissement, si oui que puis-je faire?

upgradesshdata-recoveryconnectionsftp
2
Croydon

En fait, mon fournisseur a mis en place un mode de secours dans lequel je pouvais comprendre le problème et le résoudre.

La version OpenSSH a été mise à jour vers une version plus récente. Ma configuration OpenSSH n'était pas valide avec la version actuelle. J'avais besoin de supprimer hmac-ripemd160 de la liste MAC et c'était tout (au moins pour ce problème).

OpenSSH devrait vraiment travailler sur de meilleurs messages d'erreur et/ou processus de mise à niveau. Être en lock-out n'est pas très amusant.

3
Croydon