解決策 1:
はい、/bin/false を使用してください シェルとして、リモートコマンドを実行せずにトンネリング SSH プロセスを開始するようにユーザーに指示します (つまり、 -N OpenSSH のフラグ):
ssh -N -L 1234:target-host:5678 ssh-host
解決策 2:
ユーザーの .ssh/authorized_keys ファイルに、次のように記述します:
permitopen="192.168.1.10:3306",permitopen="10.0.0.16:80",no-pty ssh-rsa AAAAB3N...
したがって、基本的に、コントロールはスペースで区切られたユーザーの ssh 公開鍵の前に配置されます。この例では、特定の公開鍵を使用する接続は、192.168.1.10 の MySQL サーバーと 10.0.0.16 の Web サーバーに対してのみ SSH ポート転送を行うことが許可され、シェル (no-pty) は割り当てられません。具体的には「no-pty」オプションについて質問していますが、ユーザーが特定のサーバーにのみトンネリングすることになっている場合は、他のオプションも役立つ場合があります。
authorized_keys ファイルのその他のオプションについては、sshd のマニュアル ページを参照してください。
ユーザーのエクスペリエンスが少し奇妙に見える場合があることに注意してください。ユーザーが SSH 接続すると、セッションがハングしているように見えます (ユーザーが pty を取得していないため)。それで大丈夫です。ユーザーが「-L3306:192.168.1.10:3306」などでポート転送を指定した場合、ポート転送は引き続き有効です。
いずれにせよ、試してみてください。
解決策 3:
/bin/press_to_exit.sh など、ログアウトのみを許可するシェルをユーザーに提供します。
#!/bin/bash read -n 1 -p "Press any key to exit" key
このようにして、トンネルをアクティブにして、必要な限りログインしたままにすることができますが、コマンドを実行することはできません。 Ctrl-c 接続を閉じます。
解決策 4:
ユーザーのログインを許可しないシェルを割り当てます。
例
#!/bin/sh
echo "No interactive login available."
sleep 60
exit 0
シェル プロンプトが表示されないようにし、60 秒のタイムアウトを与えます。60 秒間アクティブな接続がない場合は終了し、完全に切断されます (要件に応じて数を増やします)。
シェルが許可しないため、リモート コマンドも実行できません。