web-dev-qa-db-ja.com

要塞サーバー：TCP転送VSを使用してサーバーに秘密キーを配置する

要塞サーバーBがあります。秘密鍵を使用して、AからBを介してCにSSHで接続する必要があります。

より良いオプションは何ですか：

  • プライベートSSHキーをサーバーに配置しますB.実稼働環境でこれを行うのは悪い考えです。

    ここ から：

    SSH秘密鍵を踏み台インスタンスに配置しないでください。代わりに、SSHエージェント転送を使用して、最初に要塞に接続し、そこからプライベートサブネット内の他のインスタンスに接続します。これにより、SSH秘密鍵をコンピューター上だけに保持できます。

  • SSHエージェント転送を使用します。エージェント転送を設定するには、TCP転送を許可する必要があります。エージェント転送を設定すると、転送ホストにソケットファイルが作成されます。これは、キーを宛先に転送できるメカニズムです。 AWSの要塞設定で：

    TCP転送：この値をtrueに設定すると、TCP転送（SSHトンネリング）が有効になります。これは非常に便利ですが、セキュリティ上のリスクもあるため、必要でない限り、デフォルト（無効）の設定を維持することをお勧めします。

    また here から：

    有害と見なされるSSHエージェント転送

何が良いですか？ 2番目のリンクの代替についてはどうですか：ProxyCommand、それはソケットファイルの問題に役立つことを理解していますが、それでもTCP転送なので、十分に安全ですか？

linuxsshsecurityprivate-keybastion
10
user2503775

ProxyCommandまたはProxyJumpを使用します

私はProxyCommandを使用することをお勧めします（構文は簡単ですが、クライアント側でopenssh 7.3+を必要とするため、ProxyJumpを使用することをお勧めします）。また、秘密鍵をクライアントにデプロイする必要はありません。要塞、すべてがローカルのままです。

ProxyJumpの例

クライアントコンピューターで、~/.ssh/configの下に次のような内容のファイルを書き込みます。

Host bastion
  HostName bastion.example.com
  User bastion-user
  Port 22
  IdentityFile ~/.ssh/id_bastion

Host srvC
  HostName srvC.local
  User server-user
  IdentityFile ~/.ssh/id_protected_lan
  ProxyJump bastion

次にssh srvCを実行すると、エージェント転送や要塞への秘密鍵のデプロイなしで、B（要塞）を介してCに接続します。

上記の例では、「bastion」はバスティオンホストのエイリアスで、srvCはサーバーCのエイリアスです。HostNameには、ホストのIPまたは実際の完全修飾ドメイン名を入力する必要があります。ユーザーの場合、Userを更新して、要塞とサーバーCの正しいログイン名を取得する必要があります。ローカルエージェント（KeeAgentやssh-agentなど）を使用する場合、IdentityFileはオプションです。 ）、ただし実行されていない場合も機能し、各キーパスフレーズを要求します。

公開鍵の配備

もちろん、publicキーを要塞とsrvCの両方にデプロイする必要があります。使用できます（$記号はプロンプトを説明するためのものであり、入力しないでください）。

$ ssh-copy-id -i ~/.ssh/id_bastion.pub \
   -o PreferredAuthentications=password \
   -o PubkeyAuthentication=no \
   bastion
$ ssh-copy-id -i ~/.ssh/id_protected_lan.pub \
   -o PreferredAuthentications=password \
   -o PubkeyAuthentication=no \
   srvC

注：上記は、パスワード認証が引き続き許可されている場合にのみ機能します。上記の展開とすべてが意図したとおりに機能することを確認したら、2台のサーバーでのパスワード認証を禁止する必要があります。

ProxyJumpの代わりにProxyCommandを使用した例

（クライアント側で）ProxyJumpをサポートしない古いバージョンのOpenSSHを使用している場合は、以下を置き換えます。

ProxyJump bastion

沿って

ProxyCommand ssh -q -W %h:%p bastion

私が理解している限り、これは似ています。

13
Huygens

ProxyJumpに関する答えを見ました。 ProxyCommandについて話しましょう。

しかし、待って、待ってください！私はあなたに書くことができますサーバーをハックする方法エージェント転送を使用するので、違いを理解するのがはるかに簡単です！

ハックしましょう！

基本的な手順については、私の投稿を読むことができます ここ

基本的な手順は次のとおりです。

  1. 要塞ユーザーを作成する
  2. Rootログインを無効にする
  3. ハッキングの試みをブロックする
  4. ポートを変更
  5. ファイアウォールを構成する
  6. SELinuxを設定する

AgentForwardingの使い方

-〜/ .ssh/configに設定を作成

  Host bast
        Hostname BASTION_IP
        ForwardAgent yes
        User bastion

-認証キーをssh-agentに追加します

ssh-add ~/.ssh/name_rsa

-要塞ホスに接続

ssh bast

-要塞からアプリケーションサーバーを接続する

 ssh app@IP -p PORT

ハッキング！

あなたは、まあ、私に質問をするかもしれません：

  • サーバーは安全ですか？そして答えは非常に簡単です：

    • 番号！

  • どうして？

    • SSHエージェント転送を使用しているため！

  • そして、問題はどこにありますか？

    • エージェント転送は危険であり、有害と見なされているためです。

  • どうして？

    • すべてを裏返しに説明しましょう：要塞ホストに接続すると、栄光のsshエージェントが転送されます。つまり、誰かがこのソケットデータを使用してサーバーにアクセスできるように、ソケットが設定されます。あなたの要塞サーバーが危険にさらされていると想像してください。もし誰かがあなたのLinuxサーバーに対して十分な権限を持っているなら、彼/彼女はあなたのソケット情報を使用するだけです。その結果、すべてのサーバーにアクセスできます。要塞ホストに接続している時間の長さに依存するため、妥協のウィンドウが非常に小さいことを知っています。しかし、ProxyCommandのような他のオプションがある場合、本当にリスクを冒しますか？したがって、ProxyCommandを使用してください！

要塞ホストが危険にさらされた場合にサーバーをハッキングする方法

トラックターゲット

/ tmpディレクトリには、次のようなものがあります。

[root@localhost tmp]# ll
total 12
drwx------  2 bastion bastion 4096 Sep  7 17:35 ssh-mKX88v0Vlo

一時ファイルを開いてみましょう

[root@localhost tmp]# cd ssh-mKX88v0Vlo/
[root@localhost ssh-mKX88v0Vlo]# ll
total 0
srwxr-xr-x 1 bastion bastion 0 Sep  7 17:35 agent.10507

このプロセスIDにconnectionsを見てみましょう。

netstat -nxp | grep  10507

結果：

unix  [ ]   STREAM     CONNECTED     501384   10507/sshd: bastion

および誰が接続していますか？

lsof -i -a -p 10507

結果：

COMMAND  PID   USER  FD  TYPE DEVICE SIZE/OFF NODE NAME
sshd    10507 bastion  3u  IPv4 501301  0t0  TCP *IP*:ssh->*IP*:8279 (ESTABLISHED)

ソケットファイルも確認できます。

cd /proc/10507/fd/
ls

結果：

lrwx------ 1 root root 64 Sep  7 17:46 0 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 1 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 10 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 14 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 15 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 2 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 3 -> socket:[501994]
lrwx------ 1 root root 64 Sep  7 17:46 4 -> socket:[502069]
lrwx------ 1 root root 64 Sep  7 17:46 5 -> socket:[502072]
l-wx------ 1 root root 64 Sep  7 17:46 6 -> /run/systemd/sessions/1836.ref
lr-x------ 1 root root 64 Sep  7 17:46 7 -> pipe:[502079]
l-wx------ 1 root root 64 Sep  7 17:46 8 -> pipe:[502079]
lrwx------ 1 root root 64 Sep  7 17:46 9 -> socket:[502080]

そして何が起こるかクライアント接続されるときリモートサーバーに？どれどれ：

lrwx------ 1 root root 64 Sep  7 17:46 0 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 1 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 10 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:48 11 -> socket:[502267]
lrwx------ 1 root root 64 Sep  7 17:46 14 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 15 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 2 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 3 -> socket:[501994]
lrwx------ 1 root root 64 Sep  7 17:46 4 -> socket:[502069]
lrwx------ 1 root root 64 Sep  7 17:46 5 -> socket:[502072]
l-wx------ 1 root root 64 Sep  7 17:46 6 -> /run/systemd/sessions/1836.ref
lr-x------ 1 root root 64 Sep  7 17:46 7 -> pipe:[502079]
l-wx------ 1 root root 64 Sep  7 17:46 8 -> pipe:[502079]
lrwx------ 1 root root 64 Sep  7 17:46 9 -> socket:[502080]

Netstatを使用してソケットファイルが使用されているかどうかを確認することもできます。

unix  3 [ ]  STREAM  CONNECTED  502267  10561/sshd: 
                     bastion  /tmp/ssh-oVoMXC6vb8/agent.10561
unix  3  [ ] STREAM     CONNECTED     502072   10561/sshd:  bastion

スチールソケット情報とIPアドレス

次に、要塞ホストのセッションがopenのときにソケット情報を盗む必要があります。また、宛先サーバーのIPも必要なので、netstatを使用します。

netstat -tn

最終ステップ使用転送されたソケットファイル

eval "$(ssh-agent -s)"
SSH_AUTH_SOCK=/tmp/ssh-EAKxOdL4fl/agent.10507

キーが読み込まれているかどうかを確認。

ssh-add -l

結果は何かであるはずですそのような：

2048 SHA256:2Psdl..B5KQ /home/usr/.ssh/name_rsa (RSA)

サーバーがハッキングされています。セキュリティの問題を修正するにはどうすればよいですか？

プロキシコマンド

Host app
    Hostname *.*.*.*
    IdentityFile ~/.ssh/your_rsa
    User *******
    Port ****
    ProxyCommand ssh -W %h:%p bast

Host bast
     Hostname *.*.*.*
     ForwardAgent no
     User ******

基本的な操作：サーバーを介してファイルを転送する方法（クライアントからサーバー、サーバーからクライアント）、私の投稿で読むことができます here

結論

  • 要塞ホストを使用する場合は、AgentForwardingを使用せず、ProxyCommandを使用してください
  • 認証には常に非rootユーザーを使用する
  • ファイアウォールを使用して、不要な接続をすべてブロックします。
  • SELinuxを使用する（一般）
  • 不正な資格情報で数回ログインしようとするIPアドレスをブロックする
  • 必要がない場合は、ユーザーにSudo権限を付与しないでください。
  • サーバーを監視する
  • セキュリティパッチのためにサーバーを更新する

詳細については、my blog を参照してください。さらに、私はいくつかのスクリーンショットを持っているので、あなたに役立つかもしれません。

5
grep

SSHエージェントフォワーディングを使用するだけで、他のほとんどの人がそうです。

  • 鍵はラップトップのsshエージェントにあります。
  • 要塞にログインし、エージェントによって認証されます。
  • そこからターゲットホストにログインし、認証リクエストをラップトップに転送します。

利点：悪用される可能性がある要塞に保存されているキーがない。

それが役に立てば幸い:)

4
MLu