回答:
ユーザーの.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」などのポート転送を指定している場合、ポート転送は引き続き有効です。
いずれにせよ、試してみてください。
no-pty
シェルへのアクセスを妨げません。シェルにptyを与えるだけではありません。プロンプトは表示されません(つまり、「ハングしたように見える」)が、それでもコマンドを正常に実行できます。そこからのシェルアクセスを制限command="..."
する.ssh/authorized_keys
場合は、オプションが必要です。
ユーザーのログインを許可しないシェルを割り当てます。
例えば
#!/bin/sh
echo "No interactive login available."
sleep 60
exit 0
それらがシェルプロンプトを取得するのを防ぎ、60秒のタイムアウトを与えます-60秒間アクティブな接続がない場合は終了し、それによってそれらを完全に切断します(要件に応じて数を増やします)。
シェルはそれらを許可しないため、リモートコマンドも実行できません。
logout
通常の「」と同じ効果があります。
/sbin/nologin
、でユーザーフレンドリーなメッセージでカスタマイズできます/etc/nologin.txt
。
私の解決策は、対話型シェルを使用せずにトンネリングのみを行うユーザーに、/ etc / passwdのシェルを/ usr / bin / tunnel_shellに設定することです。
無限ループで実行可能ファイル/ usr / bin / tunnel_shellを作成するだけです。
さらにAllowGroups
and Match Group
オプションを使用します。
ここで完全に説明しています: http : //blog.flowl.info/2011/ssh-tunnel-group-only-and-no-shell-please/
-N
、シェルアクセスがあります。これは本当に問題を解決せず、危険です。