sshfsセッションを使用してリモートでコマンドを実行する

sshfsセッションを使用してリモートでコマンドを実行する

リモートサーバーのSSHプロセスで問題が発生したため、接続しようとすると次のエラーが発生します。

kex_exchange_identification: read: Connection reset by peer

SSHデーモンを再起動すればいいようです。

しかし、問題は、SSHを介さずにサーバーに接続する方法がないことです。唯一のオプションは突然再起動することですが、これはお勧めできません。

ただし、リモートサーバー上のファイルシステムはsshfsを介してローカルにマウントされ、正常に機能し続けます。

既存のsshfsセッションを使用してリモートでコマンドを実行する方法はありますか?

関連:

ベストアンサー1

sshfsこれは「ファイルシステム」であり、ファイルシステムの機能のほとんどを完了できます。

アクセスできるディレクトリによっては、次のことがsshfsできます。

  • 再起動するスクリプトを作成します(代わりにフルパスをsshd使用)。/bin/lsls
  • sshfs(経由)サーバーに保存
  • スクリプトを呼び出すには、リモートシステムの、、、batchまたはatキューエントリを手動で編成します。crontab
  • ジョブをキューディレクトリに配置します。
  • 待つ。

ユーザー名はリモートサーバーでsudo有効になっていますか?リモートサーバーでLinuxを実行する前にat、、、batchおよび作業方法を検討してください。cron

OTOH、SSHを介してアクセスできないますます望ましくない状況は、最終的に再起動という望ましくない状況よりも大きくなる可能性があります。

この時間を活用してプロセスを再設計します。

リモートシステムでロシアのルーレットを変更する直前に、at「現在+ 15分」で実行するように古いが有効な設定を復元するタスクをキューに追加しました。その後、15分間トリガーを引いて「知って見て」再接続/ログインし、操作をキャンセルしますat。そうでない場合やできない場合は、以前の設定が15分以内に復元されます。

もちろん、これにはリモートシステムと変更(apt-get changelog packagename)の理解と元に戻すスクリプトの作成が必要です。また、「元に戻す」範囲を絞り込むのに役立ちます。多くのアプリケーションアップデートは接続/アクセスに危険を与えず、(おそらく)元に戻す必要はありません。

おすすめ記事