SSHプロキシアカウントはシェルなしで動作できる

シェルセッションを無効にしつつSSH転送を利用可能に保ち、SOCKS限定の強制には限界があることを理解する。

魅力的に見える設定は AllowTcpForwarding no です。残念ながら、これは ローカルのSSH SOCKSプロキシが必要とする 転送も無効にします。動的転送はサーバーポリシーを回避する抜け道ではありません。

専用アカウントでは、OpenSSH はいくつかの機能を分離します。ポリシーの断片で、シェルおよびサブシステムのセッションを防ぎながらローカル転送を許可できます。

Match User proxyuser
    AllowTcpForwarding local
    MaxSessions 0
    PermitTTY no
    X11Forwarding no
    AllowAgentForwarding no

サーバーのマニュアル は MaxSessions 0 を、シェル・ログイン・サブシステムのセッションを防ぎながら転送を許可する設定として説明しています。これを既存の認証済みアカウントに組み込んでください。これは完全な SSH セキュリティ設定ではありません。

転送のみは SOCKS のみではない

固定のローカル転送と SOCKS リクエスト は、最終的に同じ種類の宛先接続をサーバーに要求できます。ローカル転送を許可しても、クライアントが特定の SOCKS インターフェースを使ったことは保証されません。アカウントが SOCKS 限定利用を強制していると説明しないでください。

PermitOpen は、特定のリストが要件に合う場合に 宛先のホストとポートの組 を制限できます。これは、あらゆるプライベートネットワークに対してホスト名解決を考慮した一般的な禁止ではありません。より広いアドレス制限には、適切なホストネットワークポリシーが必要になる場合があります。

アカウント、鍵、およびインクルードされたサーバー設定は、転送をさらに制限できます。他の場所にある包括的な転送禁止は、この断片が許可しているように見える機能を削除する可能性があります。

復旧経路を用意した通常のサーバー管理手順を使い、許可される機能と拒否される機能を別々に評価してください。意図する結果は明示的な転送許可であり、誤って利用可能なままにされた対話的ログインや、自身の制限によって無効になったプロキシではありません。

関連記事