☰

ソケットの有効化を含むsystemdユーザー単位を介したオンデマンドSSH Socksエージェントは、期待どおりに再起動されません。

tag-icon • tag-icon ssh systemd proxy socks socket-activation
ソケットの有効化を含むsystemdユーザー単位を介したオンデマンドSSH Socksエージェントは、期待どおりに再起動されません。

私が使用している孤立したネットワークに到達するには -D 。

追加するたびに詳細を入力したくない場合は、次の手順に従います~/.ssh/config。

$ awk '/Host socks-proxy/' RS= ~/.ssh/config
Host socks-proxy
  Hostname pcit
  BatchMode yes
  RequestTTY no
  Compression yes
  DynamicForward localhost:9118

それから私はサービスユニット定義ファイル：

$ cat ~/.config/systemd/user/SocksProxy.service 
[Unit]
Description=SocksProxy Over Bridge Host

[Service]
ExecStart=/usr/bin/ssh -Nk socks-proxy

[Install]
WantedBy=default.target

デーモンが新しいサービス定義を再ロードし、新しいサービスをアクティブにし、開始し、状態を確認し、受信中であることを確認します。

$ systemctl --user daemon-reload
$ systemctl --user list-unit-files | grep SocksP
SocksProxy.service   disabled

$ systemctl --user enable SocksProxy.service
Created symlink from ~/.config/systemd/user/default.target.wants/SocksProxy.service to ~/.config/systemd/user/SocksProxy.service.

$ systemctl --user start SocksProxy.service 
$ systemctl --user status SocksProxy.service 
● SocksProxy.service - SocksProxy Over Bridge Host
   Loaded: loaded (/home/alex/.config/systemd/user/SocksProxy.service; enabled)
   Active: active (running) since Thu 2017-08-03 10:45:29 CEST; 2s ago
 Main PID: 26490 (ssh)
   CGroup: /user.slice/user-1000.slice/[email protected]/SocksProxy.service
           └─26490 /usr/bin/ssh -Nk socks-proxy

$ netstat -tnlp | grep 118
tcp     0    0 127.0.0.1:9118        0.0.0.0:*             LISTEN     
tcp6    0    0 ::1:9118              :::*                  LISTEN

これは期待どおりに機能します。その後、手動でサービスを開始したり永久に実行したりするのを防ぎたいと思います。、使用して オンデマンド（再生）生成に使用されます。うまくいかないようです。 （マイバージョン）sshこのソケットファイル記述子を受け取ることができないようです。

文書が見つかりました（1、2）、そして一例使用するためsystemd-socket-proxyd- サービスを「ラップ」する2つのツール、「サービス」と「ソケット」を作成します。

$ cat ~/.config/systemd/user/SocksProxyHelper.socket 
[Unit]
Description=On Demand Socks proxy into Work

[Socket]
ListenStream=8118
#BindToDevice=lo
#Accept=yes

[Install]
WantedBy=sockets.target

$ cat ~/.config/systemd/user/SocksProxyHelper.service 
[Unit]
Description=On demand Work Socks tunnel
After=network.target SocksProxyHelper.socket
Requires=SocksProxyHelper.socket SocksProxy.service
After=SocksProxy.service

[Service]
#Type=simple
#Accept=false
ExecStart=/lib/systemd/systemd-socket-proxyd 127.0.0.1:9118
TimeoutStopSec=5

[Install]
WantedBy=multi-user.target

$ systemctl --user daemon-reload

これ〜らしいssh死ぬか殺されるまで働きます。これにより、次の接続試行時に再生成されません。

質問：

  1. / usr / bin / sshがsystemdによって渡されたソケットを受け入れることができないというのは本当ですか？それとも最新バージョンですか？私のもの最新のDebian 8.9の1つ。
  2. このオプションはルートユニットでのみ使用できますかBindTodevice？
  3. 古いトンネルが期限切れになった後、最初の新しい接続でプロキシサービスが正しく再生成されないのはなぜですか？
  4. これが「要求時にSSHプロキシ」を設定する正しい方法ですか？そうでなければどうしますか？

ベストアンサー1

  • / usr / bin / sshがsystemdによって渡されたソケットを受け入れることができないというのは本当ですか？

次の点を考慮すると、これはあまり驚くべきことではないようです。

  • OpenSSHはOpenBSDプロジェクトです
  • systemdはLinuxカーネルのみをサポートします。
  • systemdサポートはオプション/ビルドタイム依存関係でOpenSSHに明示的に追加する必要があるため、販売が難しい場合があります。
  • このオプションはルートユニットでのみ使用できますかBindTodevice？

ユーザーの systemd インスタンスは、マスター pid-0 インスタンスと通信できないなど、非常に隔離されていることがよくあります。ユーザー単位ファイルのシステム単位に依存するようなことは不可能です。

言及された文書BindToDevice：

このパラメータを設定すると、デバイスに追加の依存関係が追加される可能性があります（上記を参照）。

上記の制限により、このオプションはユーザーのシステムインスタンスに影響を与えないことを暗示できます。

  • 古いトンネルが期限切れになった後、最初の新しい接続でプロキシサービスが正しく再生成されないのはなぜですか？

私が知っている限り、一連のイベントは次のとおりです。

  • SocksProxyHelper.socket始まった。
  • SOCKSクライアントはlocalhost：8118に接続します。
  • システムが起動しますSocksProxyHelper.service。
  • 依存関係としてSocksProxyHelper.servicesystemdも起動しますSocksProxy.service。
  • systemd-socket-proxydシステムソケットを受け入れ、そのデータを ssh。
  • ssh死亡または殺された。
  • systemdはこれを認識して非アクティブに設定しますSocksProxy.serviceが、何もしません。
  • SocksProxyHelper.servicessh引き続き実行され、接続を受け入れますが、実行されなくなったため接続できません。

修正は、そのドキュメントを引用して追加することですBindsTo=SocksProxy.service（SocksProxyHelper.service強調追加）。

設定には、スタイル設定された依存関係が必要です。ただし、この依存関係タイプは宣言された効果Requires=に加えてより強力です。Requires=バインドされたユニットが停止すると、本ユニットも停止します。。つまり、突然無効になった他のデバイスにバインドされたデバイスも停止します。さまざまな理由で、デバイスが突然予期せず無効になることがあります。サービスユニットの主なプロセスはそれ自体で終了する可能性があります。、デバイスデバイスのサポートデバイスを取り外したり、デバイスが取り付けられている取り付けポイントをシステムおよびサービスマネージャの介入なしに取り外すことができます。

同じデバイスに結合すると、After=動作がBindsTo=より強力になります。この場合、そのユニットは次のようにバインドされます。デバイスも有効にするには厳密に有効にする必要があります。。これは、他のユニットにバインドされたユニットが突然非アクティブになるという意味に加えて、他のユニットにバインドされたユニットが条件の確認に失敗したためスキップしたことを意味します（例えば、、、、ConditionPathExists=… ConditionPathIsSymbolicLink=- 以下を参照）。ランニング。したがって、多くの場合でBindsTo=一緒に使用するのが最善ですAfter=。

  • これが「要求時にSSHプロキシ」を設定する正しい方法ですか？そうでなければどうしますか？

「正しい方法」がない可能性があります。このアプローチには、利点（すべてが「オンデマンド」である）と欠点（systemdに依存し、sshがまだ受信を開始していないため、最初の接続が進行していない）があります。おそらくautosshでsystemdソケットアクティベーションサポートを実装する方が良い解決策になるでしょう。

おすすめ記事