SSH経由でアップグレードするリスクは何ですか？

走るとき

sudo do-release-upgrade

ssh経由で、次のメッセージが表示されます。

このセッションはsshで実行されているようです。推奨されません
現在、sshを介してアップグレードを実行するため
回復が困難です。

続行すると、追加のsshデーモンがポートで開始されます
「9004」。
続けたいですか？

sshを介してアップグレードする本当のリスクは何ですか？追加のsshデーモンはこれをどのように緩和しますか？

私がお勧めすることは、サーバー上で画面セッションを起動し、画面でアップグレードを実行することです。SSHセッションが（何らかの理由で）中断しても、アップグレードプロセスは停止しません。

Screenは、マシン上の永続的な端末を許可するプログラムです。そのため、スクリーンセッションを開始できます。マシンがそのスクリーンセッション（および履歴、実行中のプログラムなど）上にある限り、マシン上に誰もいなくても動作し続けます。X Serverが登場する前のマルチウィンドウテキストターミナルを提供するために、初期の段階で設計されました。APTを使用してインストールできます。

sudo apt-get install screen

そのため、サーバーにSSH接続して画面を開始し、アップグレードプロセスを開始することができます。インターネット接続が失われたり、コンピューターがクラッシュしたために、アップグレードが失敗することを心配する必要はありません。

@ Marco-Ceppiのソリューションはすでにに統合されていdo-release-upgradeます。

実行するdo-release-upgradeと、スクリーンセッションが自動的に開始されます。sshセッションが切断された場合、インストールを再開できます。必要なのは、新しいsshセッションを開いて、do-release-upgradeもう一度実行するだけです。以前のインストールに再接続します。

@ sepp2kが指摘する2番目のリスクは、sshdサーバーをアップグレードする必要があり、おそらく正しく再起動できない可能性があることです。したがって、アップグレードプログラムは、指定されたポートで2番目のデーモンを実行します。再開する前に、ネットワーク構成を確認して、このポートからアクセスできることを確認する必要があります。

幸運を。

さらに、スクリーンセッションdo-release-upgradeはそれ自体で開始され、rootアカウントで実行されるため、独自のスクリーンセッションがクラッシュしたsudo screen -x場合、（何らかの理由で）コマンドdo-release-upgradeが自動的に回復しない場合、実行することで回復できます。よくあるようです。

アップグレードの一部として新しいバージョンのsshデーモンがインストールされると、デーモンが再起動されます。何らかの理由で更新プログラムがデーモンを破壊すると、再度起動できなくなり、マシンにログインする方法がなくなります。

initシステムによって処理されず、したがってアップグレード中に再起動されない別のsshdを起動することにより、新しいバージョンが起動に失敗しても、古いバージョンのsshdが引き続き実行されることが保証されます。したがって、システムにログインして、デーモンが壊れた原因を確認できます。

私はそれをするのに（まだ）問題を抱えたことはありませんが、そのように半ダースほどの箱をアップグレードしただけです。何か問題が発生した場合、追加のSSHデーモンが訪問を回避する（または、リモートの再インストールオプションを利用する）唯一の望みかもしれません。