UbuntuでSSHを再起動するのは簡単なコマンドです。問題は、再起動するとサーバーへのアクセスを可能にするサービス自体に影響が出てしまうことが多い点です。
ローカルマシンではリスクは低い。VPSやリモートサーバーでは、Enterキーを押す前にいくつか確認しておきたい。設定ミス、ファイアウォールのポートの忘れ、または ssh そして sshdそして、あなたは予備のコンソールを探すことになるかもしれません。

UbuntuでSSHを再起動するコマンド
UbuntuとDebianでは、サーバー側のOpenSSHサービスは通常次のように呼ばれます。 sshしたがって、最も直接的な命令は次のとおりです。
sudo systemctl restart ssh
その後すぐに、サービスがアクティブ状態に戻ったことを確認してください。
sudo systemctl status ssh --no-pager
スクリプトやクイックセッションで便利な、より短いチェックを実行することもできます。
systemctl is-active ssh
もし答えが アクティブサービスは実行中です。 失敗した、 非アクティブな または「ユニットが見つかりません」というエラーが表示された場合は、原因を理解するまで現在のセッションを閉じないでください。
サービスを停止する前に、設定をテストしてください。
改造した場合 /etc/ssh/sshd_configまず、設定をテストします。これは、リモートSSH再起動を行う前に私が必ず行うチェックです。
sudo /usr/sbin/sshd -t
コマンドが何も返さない場合は、良い兆候です。エラーが表示された場合は、SSH を再起動する前にファイルを修正してください。メインファイルに対する明示的なテストについては、以下を参照してください。
sudo /usr/sbin/sshd -t -f /etc/ssh/sshd_config
このテストは、ファイアウォールやクラウドプロバイダがSSHポートをサポートしていることを保証するものではありませんが、無効な設定でデーモンを再起動することを防ぎます。シンプルで迅速、コマンドラインから介入する必要がなくなります。
再起動か再読み込みか:どちらを選ぶべきか?
SSHの設定変更を適用するのに、必ずしも完全な再起動は必要ありません。サービスが対応している場合は、リロードの方が影響が少ないです。
sudo systemctl reload ssh
実際には、私は リロード クリーンな構成変更の場合、 sshd -t 検証済み。私は 再起動 サービスがブロックされた場合、OpenSSHのアップデート後、またはクリーンな状態からやり直したい場合。
systemdがあなたのマシンについて何を認識しているかを確認するには、次のコマンドが役立ちます。
systemctl list-unit-files 'ssh*'
施設によっては、次のような状況に遭遇することもあるかもしれません。 ssh.socketこの場合は、何かに触れる前に状態を確認してください。
sudo systemctl status ssh.socket --no-pager
systemd コマンドを service、reload、restart と混同せずに理解するには、次のガイドも読み直してください。 ランダムな再起動前に役立つsystemctlコマンド。
SSHポートがまだリッスン状態であることを確認してください。
サービスはアクティブかもしれませんが、SSH は使用しているポートとは異なるポートでリッスンしている可能性があります。一般的な Ubuntu システムでは、ポートは多くの場合次のようになります。 二十二しかし、これは絶対的なルールではない。
どのポートがリッスンしているかを確認するには:
sudo ss -ltnp | grep ':22'
SSH設定でポートを変更した場合は、OpenSSHが実際にどのポートを適用しているかを確認してください。
sudo /usr/sbin/sshd -T | grep '^port'
このトピックについてさらに詳しく知りたい場合は、以下の記事をご覧ください。 Linuxにおけるnetstat、ss、およびオープンポート より包括的な方法を提供する。
ローカルファイアウォールも考慮してください。UFWでは、検証は即座に行われます。
sudo ufw status verbose
SSHがポート2222でリッスンしているにもかかわらず、ファイアウォールがポート22しか許可していない場合、サービスは完全に動作していても外部からはアクセスできない可能性があります。ホスティングプロバイダが上流でファイアウォールやセキュリティグループを設定している場合も同様です。
再起動が失敗した場合はログを確認してください。
もし systemctl status ssh エラーを示しています。まずはサービスログを確認してください。
sudo journalctl -u ssh -b --no-pager | size -50
再試行中は、リアルタイムのメッセージを確認することもできます。
sudo journalctl -u ssh -f
最もよくあるエラーは非常に明白です: 不明なオプション sshd_configポートが既に使用されている、ホストキーが不足している、ファイル権限が間違っている、またはディレクティブが間違った場所に配置されている可能性があります。
ネットワークの変更やサーバーの再起動後にネットワークカバレッジを拡張する必要がある場合は、次のガイドを参照してください。 journalctlと前回のLinux起動時のログ システムログ全体を読まなくても、エラーを整理するのに役立ちます。
リモートサーバーで取るべき予防措置
変更対象のマシンにSSHで接続している場合は、セッションを開いたままにしておいてください。サービスが再起動する前に、別のセッションを開いておくのも良いでしょう。
sshユーザー@サーバーアドレス
再起動後、別の端末から新しい接続を試してください。新しい接続が成功すれば、古い接続は閉じても構いません。失敗した場合でも、古いセッションがまだ役立つ可能性があります。
本番サーバーでは、ホスティングプロバイダーにバックアップコンソールがあることを確認してください。これは、SSHポート、UFW、静的IPアドレス、またはネットワーク構成を同時に変更する場合に特に重要です。後者については、次の記事を参照してください。 Debianにおける固定IPアドレス ネットワーク側でも同様に慎重な対応が取られる。
再起動ではなくOpenSSHを再インストールするタイミング
サービスがインストールされ、構成が有効で、問題が一時的なものである場合は、再起動で十分です。ただし、ユニットが ssh.service OpenSSH Server パッケージが存在しない場合、またはサーバーが過剰にクリーンアップされた場合は、インストールを最初からやり直す必要があります。
この場合、強制的に再起動をループさせないでください。まず、パッケージを確認してください。
dpkg -l | grep openssh-server
何も報告されない場合は、専用の手順を繰り返してください。 UbuntuにSSHをクリーンインストールする実行されていないサービスを再起動しても、何も解決しません。
検証前の私の簡単な方法
UbuntuでSSHを使用する必要がある場合は、手順をシンプルにします。設定をテストし、可能であればリロードし、必要であれば再起動し、その後、ポート、ファイアウォール、新しい接続を確認します。
sudo /usr/sbin/sshd -t
sudo systemctl reload ssh
sudo systemctl status ssh --no-pager
sudo ss -ltnp | grep ':22'
sudo ufw status verbose
リモートワークをしている場合は、新しいSSH接続が確立されるまでアクティブなセッションを閉じないでください。これはおそらくこの記事の中で最も地味なアドバイスですが、最も厄介なトラブルを未然に防ぐための重要なポイントです。
Ubuntuの公式ページ OpenSSHサーバー、ドキュメント システム制御マニュアルページ sshd そして sshd_configドキュメントも併せて UFWサーバーの手順を文書化する必要がある場合、これらは良い出発点となります。