ユーザーにSSHトンネルのセットアップを許可するが、それ以外は許可しない


97

ユーザーが特定のポート(たとえば5000)の特定のマシンへのSSHトンネルを設定できるようにしたいのですが、このユーザーをできるだけ制限したいと思います。(認証は公開/秘密鍵ペアで行われます)。

関連する〜/ .ssh / authorized_keysファイルを編集する必要があることはわかっていますが、そこにどのコンテンツ(公開キー以外)を入れるか正確にはわかりません。

回答:


91

Ubuntu 11.10では、ポート転送を許可しながら、-Tの有無にかかわらず送信されるsshコマンドをブロックし、scpコピーをブロックできることがわかりました。

具体的には、localhost:6379にバインドされた「somehost」にredis-serverがあり、sshトンネルを介して、キーファイルを持つ他のホストと安全に共有し、次のようにsshで接続します。

$ ssh -i keyfile.rsa -T -N -L 16379:localhost:6379 someuser@somehost

これにより、「somehost」上のredis-serverの「localhost」ポート6379が、「localhost」ポート16379に再マッピングされたsshコマンドを実行するホスト上にローカルに表示されます。

リモートの「somehost」では、authorized_keysに以下を使用しました。

cat .ssh/authorized_keys   (portions redacted)

no-pty,no-X11-forwarding,permitopen="localhost:6379",command="/bin/echo do-not-send-commands" ssh-rsa rsa-public-key-code-goes-here keyuser@keyhost

no-ptyは、端末を開こうとするほとんどのssh試行を停止します。

permitopenは、どのポートが転送を許可されるかを説明します。この場合、ポート6379転送したいredis-serverポートです。

command = "/ bin / echo do-not-send-commands"は、誰かまたは何かがssh -Tなどを介してホストにコマンドを送信できた場合、 "do-not-send-commands"をエコーバックします。

最近のUbuntuからman sshd、authorized_keys /コマンドは次のように説明されています。

command = "command"このキーが認証に使用されるときはいつでもコマンドが実行されることを指定します。ユーザーが指定したコマンド(存在する場合)は無視されます。

scpセキュアファイルコピーを使用しようとすると、「do-not-send-commands」のエコーで失敗します。sftpもこの構成で失敗することがわかりました。

以前の回答で行われた制限付きシェルの提案も良い考えだと思います。また、ここで詳しく説明されているすべては、「man sshd」を読んで「authorized_keys」を検索することで決定できることに同意します


1
一方では、no-ptyユーザが編集して、それがコマンドの実行を防ぐために何もしないインタラクティブseesionを開くことはできませんauthorized_keys、彼はのようなものとのアクセスを持っているファイルの場合ssh server 'sed -i -e s/no-pty// ~/.ssh/authorized_keys'
シナプス

4
@synapse command = "/ bin / echo do-not-send-commands"は、上記にもリストされていますが、コマンドをブロックするためのものです。メッセージを提供します。上記の設定全体を無効にする例を意図していましたか、それともno-ptyについてのみコメントしていますか?
ポール、

これは、管理者がauthorized_keysファイルまたは含むディレクトリのユーザーの所有権を付与する義務がされていないことを言及し、またそれも、ユーザーのホームディレクトリに存在していること(その場所のために正しく設定されているSSHサーバを想定)クマ
ダニエル・ファレル

?? @DanFarrellは、.ssh / authorized_keysをroot、wheel、またはだれが所有しますか?
Andrew Wolfe

@AndrewWolfeは通常、~user/.ssh/authorized_keysによって所有されuseruserアカウントへのアクセスに使用される承認済みキーを管理します。SSHはアクセス許可についてはうるさく~/.ssh/、その内容に期待を課す可能性があります。実行したところsudo chown root: .ssh/authorized_keys、ログインできなくなったようですが、過去の経験から、ユーザーがそのファイルを所有する必要がないことがわかっていますroot。必要に応じて管理できます。
Daniel Farrell

18

ユーザーのシェルを制限付きシェルに設定することをお勧めします。ユーザーの〜/ .bashrcまたは〜/ .bash_profileでPATH変数の設定を解除すると、ユーザーはコマンドを実行できなくなります。その後、あなたはのように、コマンドの限定セットを実行するユーザー(複数可)を許可することにした場合lesstail、インスタンスのために、そして、あなたは(のような別のディレクトリに許可されるコマンドをコピーすることができます/home/restricted-commands)とのポイントへのパスを更新しますそのディレクトリ。


1
しかし、それはユーザーがsshコマンドラインでのような別のコマンドを指定することを妨げませんssh use@host "/bin/bash"か?
フリッツ

はい、それはuser@hostシェルとしてrbash を持っていると仮定して、行います。制限付きシェルを
ジェイソンデイ

わかりました、私はそれを試しました、そしてあなたは正しいです。指定されたコマンドはログインシェルによって実行される/bin/bashため、スラッシュが含まれているため実行に失敗します。
Fritz

3
許可することlessはおそらく悪い考えですが、そこから無制限のシェルにエスケープできるため!/bin/bashです。他の例については、pen-testing.sans.org / blog / 2012/06/06 /…を参照してください。したがって、個々のコマンドを許可することは、たとえあったとしても、非常に慎重に行う必要があります。
Fritz

17

no-X11-forwardingのようなauthorized_keysオプションに加えて、実際に求めているのは、permitopen = "host:port"だけです。このオプションを使用すると、ユーザーは指定されたホストとポートへのトンネルのみをセットアップできます。

AUTHORIZED_KEYSファイル形式の詳細については、man sshdを参照してください。


13
オプションセットの一部として「no-pty」も指定する必要があります。「permitopen」のみを使用する場合、トンネルを特定のホスト/ポートに制限しますが、インタラクティブシェルは引き続き許可します。
John Hart

permitopenでポート転送を制限すると、ssh -wが要求する種類のトンネルデバイス転送もロックされますか?
flabdablet 2014年

5
@JohnHart:no-ptyシェルのアクセスも制限しません。シェルにアクセスできますが、プロンプトは表示されません。あなたはまだコマンドを与えて、出力をうまく見ることができます。command="..."からのシェルアクセスを制限する場合は、このオプションが必要です.ssh/authorized_keys
2015年

9

私の解決策は、対話型シェルなしでトンネリングしているだけのユーザーに、/ etc / passwdのシェルを/ usr / bin / tunnel_shellに設定することです。

実行可能ファイル/ usr / bin / tunnel_shell無限ループで作成するだけです。

#!/bin/bash
trap '' 2 20 24
clear
echo -e "\r\n\033[32mSSH tunnel started, shell disabled by the system administrator\r\n"
while [ true ] ; do
sleep 1000
done
exit 0

ここで完全に説明: http : //blog.flowl.info/2011/ssh-tunnel-group-only-and-no-shell-please/


9
CTRL + Zはスクリプトからエスケープして、bashへの完全なアクセスを提供します...スクリプトの先頭に「trap '' 20」(引用符なし)を追加してみてください
Big Papoo

1
ヒントをありがとう、私はいくつかの割り込み信号のトラップを追加しました
ダニエルW.

1
「シェル」には/ bin / catを使用します。正常に動作するようです。catに対するエクスプロイトを認識せず、なんとかそれをクラッシュさせることができる入力パターンを見つけたとしても、sshセッションは単に終了します。
flabdablet 2014年

4
@BigPapoo:実際にテストしましたか?どこに逃げるかわからない。シェルに入っていてを実行するとtunnel_shellshell -> /bin/bash tunnel_shellもちろんシェルに戻ることができますが、ユーザーのシェルtunnel_shell として設定た場合は、/bin/bash tunnel_shell実行するだけで、シェルはエスケープできません。 、私が見る限りでは。私はそれをテストし、ctrl-zでエスケープできませんでした。あなたがいる場合やったセットアップを投稿することができ、それを試してみて、逃れることができますか?同様に、それがそのように機能するはずであると述べているドキュメントを知っているなら、それを投稿できますか?
Aleksi Torhamo 2015年

3

ログイン用の公開鍵を使用して、authorized_keysファイルをセットアップすることができます。そのアカウントに許可されていることを制限するために必要な追加情報については、よくわかりません。たとえば、次のようなコマンドを入力できることはわかっています。

no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding

次のような行をauthorized_keysファイルに入れたいでしょう。

permitopen="host.domain.tld:443",no-pty,no-agent-forwarding,no-X11-forwardi
ng,command="/bin/noshell.sh" ssh-rsa AAAAB3NzaC.......wCUw== zoredache 


3

ここに私が便利だと思った素晴らしい記事がありますhttp : //www.ab-weblog.com/en/creating-a-restricted-ssh-user-for-ssh-tunneling-only/

アイデアは次のとおりです(新しい制限されたユーザー名を "sshtunnel"として)

useradd sshtunnel -m -d /home/sshtunnel -s /bin/rbash
passwd sshtunnel

rbash(restricted-bash)を使用して、ユーザーが実行できることを制限していることに注意してください。ユーザーはcd(ディレクトリの変更)も環境変数の設定もできません。

次に、ユーザーのPATH env変数/home/sshtunnel/.profileを何もないように編集します。これにより、bashが実行するコマンドを見つけられなくなります。

PATH=""

最後に、次の権限を設定して、ユーザーがファイルを編集できないようにします。

chmod 555 /home/sshtunnel/
cd /home/sshtunnel/
chmod 444 .bash_logout .bashrc .profile

0

次のようなCプログラムを作成しました。

#include <stdio.h>
#include <unistd.h>
#include <signal.h>
#include <stdlib.h>
void sig_handler(int signo)
{
    if (signo == SIGHUP)
        exit(0);
}

int main()
{
    signal(SIGINT, &sig_handler);
    signal(SIGTSTP, &sig_handler);

    printf("OK\n");
    while(1)
        sleep(1);
    exit(0);
}

制限付きユーザーのシェルをこのプログラムに設定しました。

ssh server commandコマンドはシェルを使用して実行され、このシェルは何も実行しないため、制限されたユーザーは実行しても何も実行できないと思います。



-3

ユーザーが使用しているsshクライアントを介して、ユーザーのマシンにキーを生成します。たとえばpUTTYには、これとまったく同じことを行うユーティリティがあります。秘密鍵と公開鍵の両方を生成します。

生成された公開鍵ファイルの内容は、authorized_keysファイルに配置されます。

次に、公開鍵を生成した秘密鍵を使用するようにsshクライアントが構成されていることを確認する必要があります。かなり単純ですが、使用しているクライアントによって多少異なります。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.