☰

SSH専用ジャンプボックスの設定

tag-icon • tag-icon shell ssh
SSH専用ジャンプボックスの設定

私はAWSクラスターを管理しており、現在変化しているアクセスリストに対して公開キーまたはLDAP認証を処理するのではなく、単一のジャンプボックスを介してのみSSHアクセスを実行する予定です。代わりに、ジャンプボックスの公開鍵は他のすべてのインスタンスで承認され、どのユーザーが他のインスタンスにアクセスできるかを制御します。しかし、一般ユーザーに秘密鍵を公開したくありません。

ssh [myserver]私の最初の解決策は、実行してユーザーssh username@aws-jumpbox [myserver]に接続できるようにする単純なシェルをbashに作成するか、コマンドのみを受け入れる対話型セッションをmyserver確立することでした。sshしかし、後でシェルスクリプトでは対話型セッションを作成できないことを覚えていました。

私が探しているものを達成する簡単な方法はありますか？私は完全に間違った道を行っていますか？

答え1

しかし、後でシェルスクリプトでは対話型セッションを作成できないことを覚えていました。

はい、可能です。ただし、これをコマンド（接続を確立するコマンド）-tに渡す必要があります。ssh到着ホストではなくホストにジャンプ~からジャンプヨスト）。その理由は、実行時にコマンドを指定した場合、デフォルトではssh対話型セッションに必要なttyが割り当てられていないためです。-tこの問題を解決してください。

いくつかの可能な選択肢：

  1. dialog.
  2. ターゲットシステムの名前を付けた各ターゲットシステムのジャンプホストにユーザーを作成します。このアプローチの欠点：多くのファイルでユーザーのSSHキーを維持する必要があります。これを行うには、いくつかの構成管理システムを使用するのが最善です。たとえば、puppet はauthorized_keysファイルと SSH キーの直接処理をサポートします。利点は、どのユーザーがどのホストにアクセスできるかをより簡単に定義できることです。

ユーザーがSSH秘密鍵を取得できないようにするには、そのユーザーもジャンプホストを使用またはscpアクセスできないようにする必要があります。sftpこれは彼らの仕事をより困難にすることができます。

全体的に個人的にあなたがやろうとしていることが良い考えなのかよくわかりません。ジャンプホストは「sshキーが多すぎる」という問題を解決せず、単に移動して独自の問題を発生させます（scp / sftpなし、追加したホストは攻撃者が良いターゲットを試すのに問題があります）。訪問するみんなネットワークのホストなので、セキュリティの観点から対話型セッションと指定されたコマンドにSPOFの問題があります。

代わりに、以下を提案します。

  • AWSホストで設定管理システムを使用し、起動する前に実行していることを確認してくださいsshd。これはいくつかの理由でとにかく良い考えです。私は選択肢よりもMuppetsをよく知っていますが、選択肢があります。

  • puppetを使用している場合は、次のようにユーザーのSSHキーを使用してファイルを作成します。

    $user_wouter_sshkey = 'ssh public key data'
$user_john_sshkey = 'ssh public key data'

    など。

  • リソースへのアクセスを許可するユーザーグループごとに定義されたタイプを作成します。

    define dbassh ($username = $title) {
    ssh_authorized_key {"wouter_dba_$username":
        key => $user_wouter_sshkey,
        type => 'ssh-rsa',
        user => $username,
    }
    ssh_authorized_key {"john_dba_$username":
        key => $user_john_sshkey,
        type => 'ssh-rsa',
        user => $username,
    }
}

    など。

  • これで、パペット構成の他の場所で次のことができます。

    user {"postgres":
    ensure => present,
    purge_ssh_keys => true,
}
dbassh {"postgres":}

答え2

あなたが説明するのは、単一の障害点であり、脆弱な点です。個人的に私は別のアプローチを選択します。つまり、ルータ、ファイアウォール、およびロードバランサとして機能する2つ以上のOpenBSDシステムをクラスタの前に配置します。ファイアウォール状態の同期鯉、そして使用確認コード誰が何にアクセスできるかを制御します。これにより、すべての人のキーをどこにでも配布し、1か所でアクセスを管理できます。認証と承認を分離し、単一障害点を削除します。

答え3

1）ジャンプホストにSSHセキュリティを設定します。静的IPがない場合は、会社のパブリックIPアドレスまたはISPが提供するIPアドレスブロックのみを許可してください。その後、自宅で働いているユーザーが最初にVPNを使用して内部ネットワークに接続できるようにすることができます。

https://www.freebsd.org/cgi/man.cgi?query=sshd_config&sektion=5

2）このジャンプホストサーバーからのみ出るように、他のサーバーへのSSHログインをロックします。

https://www.freebsd.org/cgi/man.cgi?query=sshd_config&sektion=5

3）サーバーに機能アカウントを作成し、機能/管理アカウントからSSHキーをプッシュします。 sudoerなどのさまざまなセキュリティ機能を使用してロックします。 MyCorporation...mycorpsql、mycorpweb、mycorpdev、mycorpsys。

また、ローカルセキュリティグループを効果的に使用してsuをロックすることもできます。

http://sharadchhetri.com/2014/03/27/allow-only-members-of-wheel-group-to-use-su-command-on-rhelcentos/

効果的には、グループからユーザーを削除してアカウントを無効にするだけです。これを行うには、ルートディレクトリにスクリプトを作成できます。

ユーザーの削除/終了

#!/bin/bash 
#   title   : deladminusers.sh
#   syntax  : deladminusers.sh username
gpasswd -d $1 youradmingrouphere
userdel $1

ユーザーの無効化

#!/bin/bash 
#   title   : disableadminusers.sh
#   syntax  : disableadminusers.sh username
gpasswd -d $1 youradmingrouphere
#makes password incomprehensible
sed -i "s/$1:/$1:!/g" /etc/shadow

ユーザーの有効化

#!/bin/bash 
#   title   : enableadminusers.sh
#   syntax  : enableadminusers.sh username
gpasswd --add $1 youradmingrouphere
#makes password comprehensible again.
sed -i "s/$1:!/$1:/g" /etc/shadow

4）ジャンプホストからすべてのサーバーにSSHキーをプッシュします。次に、読み取りと実行のみを可能にするために、機能アカウントプロファイルでsshファイルをロックします。

fiduser@jumphost ~: ssh-keygen -t rsa
fiduser@jumphost ~: for SERVER in `cat ~/serverlist`
do
    ssh-copy-id -i .ssh/rsa_id.pub fiduser@$SERVER
done

5）SUが許可されているユーザーを機能IDでロックし、ジャンプホストが厳密にロックされていることを確認します。ジャンプホストで通常のバイナリアクセスを無効にします。すべてのユーザーにSUとSSHを許可します。ジャンプホストの非ルート機能アカウントも許可します。ログイン後、パスワードなしのSSHの要件を最小限に抑えます。

ジャンプホストのOSバージョンに慣れていません。ユーザーをグループに追加してデフォルトのユーザーコマンドをロックすることは、ディストリビューション全体で解釈するのが難しい可能性があるため、調査する必要があります。

強力な対応策を使用してください。 fall2banを使用できますか？

会社のIP範囲をブロックしないように設定されていることを確認してください。また、オフィスの内部にジャンプホストをロックすることを忘れないでください。

関連情報