シナリオ:
私は試しました:最初にWiFiに接続してからイーサネットを切断します。また、まずイーサネットを切断してからWiFiに接続します。どちらのアプローチも機能しません。 UbuntuとOS Xサーバーをクライアント用の両方のOSオプションとともに使用するときにも試してみました。運が悪い。
古い切断されたインターフェースの代わりに新しく接続されたネットワークインターフェースの使用を開始する必要があることをSSH接続に伝える何らかの方法が必要なようです。何か案は?
私は一日中WiFiにとどまることができることを理解していますが、それをしたくありません。リモートサーバーのスクリーンセッション内から作業し、次に再接続できることも理解していますインターフェイスを変更した後のスクリーンセッションですが、それもしたくありません。たとえば、SSHを介したデータベースダンプなどの大きなコマンドをパイピングしている場合や、SSHFSを介してファイルを開いている場合、または単に回避したい場合があります。再接続の煩わしさ
このソリューションはSSHFSなどでは機能しないと思いますが、少なくともシェル自体にローミングサポートを提供する Mosh を確認できます。
当然のことながら、これを行うことはできません。 SSHセッションは、4つのタプル(送信元アドレス、送信元ポート、宛先アドレス、宛先ポート)によって定義されるTCP接続で実行されます。既存の接続を別のアドレスにシフトすることはできません。クライアント上(インターフェイスがダウンしたときにOSが接続を切断するという事実は別として).
NATはこの状況を複雑にする可能性がありますが、役立つことはありません。
古いスレッドですが、同じものを探していたので、完全を期すために...
Windows 7以降では、wifiアダプターとイーサネットアダプターの両方を選択して、[ブリッジ接続]を選択するだけです。これにより、両方に1つのIPアドレスが与えられ、イーサネットを自由に切断して再接続できるようになります(継続的なWi-Fiの適用範囲を前提とします)。
問題は、ケーブルとwifiを切り替えると、ソースIPアドレスが変更されることです。これにより、sshセッションが戻されなくなります。
私はLinuxでこれを処理するために、VPNを介して接続し、VPN接続が常に同じIPをアカウントに与えることを確認しました(強制することは難しくありませんが、とにかくデフォルトで同じIPをVPN経由で受信する可能性が高いです)利用可能ですが、確実にするために強制することをお勧めします)。私は主にvtunを使用していますが、openvpnも大丈夫です。接続がVPN経由であることを確認してください(正しいルーティング、プッシュされたプレフィックスなど)。
5分間もケーブルからオフラインになり、その後wifiに接続し、すべてのsshセッションに接続したままにすることができました。進行中のping、mtr、htop、...何も起こらなかったかのように、vpnが復元されたときだけ続行します。
それは簡単にはできません。
IPまたはAP間を移動するとき、または長期間ネットワークが切断されている間でも、TelnetまたはSSHセッションを維持できる非常に高価なアプリケーションをいくつか紹介しますが、基本的には、常時オープンなサーバーを作成することでこれを実現します-クライアントマシンのサイドセッション。これにより、サーバーは接続の違いやドロップを認識しません。
私はあなたがそのようなことをコード化できると思いますが、もしそれが簡単なら、私のクライアントはワイヤレスハンドヘルドスキャナーでターミナル接続を開いたままにしておくために5桁のコストでレイプされることはないと思います。
しかし、実際に動作する可能性のある 永続的なSSHセッションを作成することを主張する画面 に遭遇しました...試してみてください。
VMとトンネリングを使った馬鹿げた量のハッキングでこれを行うことができると確信しています。
これは未テストですが、実際に機能するかどうかをお知らせください。
ssh -L 10022:remote.server.example.com:22
ssh 192.168.56.3 -p 10022
動作するかどうか教えてください。
最初にsshセッションを開始するときは、wifiのみにしてみてください。次に、イーサネットを接続します。これにより、新しい接続がイーサネットを経由できるようになりますが、確立された接続はwifiに残ります。少なくともOSXでこのように動作するのを見たので、OS /ハードウェアは異なる場合があります。