リリースアップグレード後にサーバーに接続できない

リリースアップグレード後にサーバーに接続できない

古い 16.04 LTS をアップグレードしている最中に、ロックアウトされてしまい、元に戻す方法がないようです。助けてください。

私は基本的な手順に従いました:

sudo apt-get update
sudo apt-get upgrade -y
sudo apt-get dist-upgrade
sudo do-release-upgrade

リリース アップグレード中は、すべてがスムーズに進みました。エラー メッセージも何も表示されませんでした。再起動によってシステムへのアクセスが切断されました。ポート 1022 で開始されたセカンダリ SSH プロセスも完全にタイムアウトしました。

ここで問題となるのは、切断されているため、root@ip として接続できないことです。SSH キーを使用した接続のみが可能です。

これは SSH からのデバッグです:

:~$ ssh -vvvvvvvvv atlas
OpenSSH_7.6p1 Ubuntu-4ubuntu0.5, OpenSSL 1.0.2n  7 Dec 2017
debug1: Reading configuration data /home/name/.ssh/config
debug1: /home/name/.ssh/config line 1: Applying options for atlas
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "(ip)" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to (ip) [(ip)] port 22.
debug1: Connection established.
debug1: identity file /home/name/.ssh/atlas_a type 0
debug1: key_load_public: No such file or directory
debug1: identity file /home/name/.ssh/atlas_a-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.5
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.6p1 Ubuntu-4ubuntu0.5
debug1: match: OpenSSH_7.6p1 Ubuntu-4ubuntu0.5 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to (ip):22 as 'name'
debug3: hostkeys_foreach: reading file "/home/name/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/name/.ssh/known_hosts:2
debug3: load_hostkeys: loaded 1 keys from (ip)
debug3: order_hostkeyalgs: prefer hostkeyalgs: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
Connection closed by (ip) port 22

(名前とIPは編集しました)

何が起こっているのでしょうか? なぜ接続できないのでしょうか? すべてを完全に壊してしまったのでしょうか、それとも何らかの方法で回復できる可能性はあるのでしょうか? これは仮想サーバーであり、物理的にアクセスできず、リモート再起動も現在は失敗しているようです。

ヘルプ :)

編集:これを修復することはできないようなので、もう少し具体的に説明します。具体的には、何を間違えたのでしょうか。これを防ぐにはどうすればよかったのでしょうか。SSH デバッグでは、実際に問題を引き起こした原因に関するフィードバックが得られず、この特定のケースのために開かれた「予約」ポート (1022) はまったく機能しません。

サーバー全体を失わなければならないとしても、少なくともこのことから学びたいのですが、どうやら「機能しない」だけなのでしょうか?

編集2:驚いたことに、ホストが提供する「修復」モードでサーバーに再度アクセスできました。アクセスを保証し、これを修正するにはどうすればよいでしょうか? (VI 経由ですべてのファイルにアクセスでき、それらは /repair/ フォルダーに配置されています)

関連情報