🕺🏻 🎤 💫 SSHで作業中のホワイトスポット 💘 ➖ 📑

SSHは非常に強力で柔軟なツールですが、実践が示すように、誰もがその仕組みを理解して正しく使用しているわけではありません。 Secureという単語は、SSHの略語の一部であり、プロトコルの重要な側面の1つですが、多くの場合、不十分な注意を受けるのはセキュリティです。この記事では、SSHを使用する際のいくつかのよくある間違いと、しばしば忘れられる点についてお話したいと思います。

ユーザーを認証するにはいくつかの方法があります。

パスワードによる -標準的なメカニズムですが、最も信頼できるものではありません。私はそれに焦点を合わせません
キーによる -最も信頼性の高い認証方法ですが、正しく使用されている場合、これが適用されます
IPアドレス別 -互換モード。参考にしていますが、誰かがそれを冷静に使用するのではないかと疑っています。

非対称暗号化

SSHは非対称暗号化を使用します。その本質は、公開キーと秘密キーの2つのキーがあることです。公開鍵でメッセージを暗号化し、秘密鍵でメッセージを復号化できます。秘密鍵はそのまま保持され、公開鍵には誰でもアクセスできます。さらに、秘密鍵でメッセージに署名し、公開鍵でこの署名を検証できます。

この図は、公開鍵の交換後、2つのノードが安全でないインターネットを介して安全に相互に通信できることを示しています。

さらに、この同じキーペアを使用してユーザー認証を実行できます。

ユーザーの公開鍵をファイル$ HOME / .ssh / authorized_keysに追加する必要があります

このファイルには複数の公開鍵を含めることができます-それらはすべて機能します。

MITM攻撃に対する保護

MITM攻撃は、攻撃者が密かに中継し、必要に応じて、互いに直接通信していると思われる2者間の接続を変更する場合の暗号化攻撃の一種です。これは、通信チャネルを危険にさらす方法であり、攻撃者は、相手との間のチャネルに接続して、伝送プロトコルに介入し、情報を削除または歪めます。

プロトコルの2番目のバージョンの主な革新の1つは、MITM攻撃に対する組み込みの保護でした。

防御の本質は、各サイドが攻撃者ではなく、正確に予想されるサイドにいることを確認する必要があることです。

クライアント側のMITM保護の場合（つまり、サーバーに接続していることを確認するため）、 StrictHostKeyCheckingパラメーターとknown_hostsファイルが責任を負います。

サーバー公開鍵はファイルに保存されます：

$ HOME / .ssh / known_hosts-ユーザーファイル、

/ etc / ssh / ssh_known_hosts-システムファイル。

known_hostsの各エントリは、フィールドを含み、区切り文字としてスペースを使用した文字列です。

コンマで区切られた1つ以上のサーバー名またはIPアドレス
キータイプ
公開鍵
追加のコメント

これは、サーバーの「識別」

StrictHostKeyChecking=no|ask|yes

値は次のとおりです。

no-どんな場合でも接続が発生します。接続が安全でないという最大の警告を受け取ります。多くの場合、自動テストや自動障害などのあらゆる種類の自動スクリプトで見つけることができます。これが主な問題の原因です。スクリプトが正常に機能する場合、ユーザー（管理者）は何かが間違っていることに気付かず、感染/侵害が発生します。
ask -known_hostsにまだレコードが存在しない場合、新しい接続を要求します（デフォルト値）。接続に同意すると、新しいレコードが追加されます。
はい -常に最も安全なオプションをチェックしてください。自動システムで使用することを強くお勧めします。 known_hostsにエントリがある場合にのみ接続が行われます

これにより何が得られますか？

最初の接続で、攻撃者が自分をサーバーとして紹介したかどうかを判断できます
サーバーへの後続の接続中に、侵入者が立派なサーバーを置き換えないことを保証します

2番目の段落ですべてが明確な場合、最初の段落はどうですか？

ここでは、少なくとも3つのオプションを選択できます。

ケースを信頼し、新しいサーバーキーを追加することに同意します
フラグVisualHostKey = keyを追加します。クライアントはサーバーの公開キーの視覚的表現を表示しますが、この表現は一意であり、キーを覚えやすくします
フラッシュドライブまたはオープンソース：これは偏執的な選択肢ですが、システムのセキュリティを侵害すると数万ドルかかる場合は、これは不要ではありません。

公開キーの視覚化の使用

公開鍵が変更された場合

キー変更メッセージは、いくつかの理由で発生する可能性があります。

サーバーアドレスが変更されました
システムを再インストールするときなど、サーバーキーが変更された
MITM攻撃

私の練習では、オプション1と2は合計で100％になる傾向がありますが、ポイント3も除外できません。

以下は、ウェブとsshのアプローチを組み合わせたライフハックの例です

 curl https://server.com/ssh_fingerprint | tee -a ~/.ssh/known_hosts

一見、これはあまり安全ではありませんが、この情報はコマンドを使用して取得できます

 ssh-keyscan example.com

ただし、最初のバージョンでは、HTTPSを使用して受信したキーの信頼性をさらに検証します。

重要なCI / CDの使用の組み合わせ

 ssh-keyscan example.com >> ~/.ssh/known_hosts

初期化中に

 StrictHostKeyChecking=yes

MITM攻撃から確実に身を守ることができます。

多くのキー

多くの場合、このような写真を見つけることができます。

クライアント上のサーバーごとに独自のキーペアが生成され、 $ HOME / .ssh /に完全な混乱が作成されます。

一方では、1組のクライアントキーを使用するよりも安全です。1つのキーが侵害されると、1つのシステムのみが侵害され、ユーザーが操作したすべてではありません。

ただし、実践が示すように、ユーザーは最後のターンでこれに導かれ、多くの場合、手順のすべての指示に従うだけです。

 ssh-keygen ... ...

頭の中で何も考えずに、いくつかの鍵が他の鍵に擦り切れている状況を時々観察しました。

思い出させてください。偏執的なセキュリティを追いかけている場合、1つのキーペアがあれば十分ですが、同時に適切に保護する必要があります。

キー保護といえば

お金があるアパートへのキーとして、プライベートSSHキーを検討してください。 SSHキーよりも無謀な態度を見たことはありません。ユーザーがパスワードを保存することの重大性を多少なりとも理解している場合、秘密鍵へのアクセスを誰にも与えてはならないという事実を考える人はほとんどいません。

ここで強調することができるもの：

キーを安全な場所に保管します。理想的には暗号化されたストレージです
誰にもキーへのアクセスを許可しないでください。侵害されたキーは、アクセスが許可されているすべてのシステムを侵害します
秘密キーの暗号化により、セキュリティが向上しますキーが失われた場合でも、暗号化を解除するためにパスワードを取得するか、時間とコンピューティングパワーをキーの解読に費やす必要があります。
ちなみに、キーファイル400に正しい権限を設定することを忘れないでください。クライアントがキーの使用を拒否する場合、これはよくある間違いです。

コマンドを使用してパスワードを変更または追加できます

 ssh-keygen -p

SSHエージェント

ただし、多くの場合、キーを使用してサーバーにアクセスし、そこで使用する必要がある状況があります。この問題には3つの解決策があります。

秘密鍵をサーバーにコピーします
新しいキーペアを生成し、アクセスオプションとして登録する
ssh-agentを使用する

私の練習から、ケースの90％のユーザーは最初の2つのオプションを選択します。すでに述べたように、キーを侵害することほどひどいものはありません。

3番目の方法を使用することをお勧めします

SSHエージェントは秘密鍵を保存し、必要に応じて使用します。プログラム（たとえば、ssh）は、秘密鍵を使用する必要がある場合、それ自体を実行しませんが、ssh-agentを呼び出します。ssh-agentは、それだけが知っている秘密鍵情報を既に使用します。したがって、秘密鍵は誰にも公開されず、ユーザー自身に属するプログラムでさえも公開されません。

ssh-agentコマンドは、エージェントが対話する/tmp/ssh-XXXXXXXX/agent.ppidという名前のソケットファイルを作成します。環境変数SSH_AUTH_SOCK（ソケットファイルの名前が保存されている）およびSSH_AGENT_PID（エージェントプロセスの識別子が保存されている）を使用して、エージェントはすべての子プロセスへの連絡方法に関する情報を報告します。

エージェントは、シェルで使用するのに便利な形式で情報を提供します。

 SSH_AUTH_SOCK=/tmp/ssh-XXt4pHNr/agent.5087; export SSH_AUTH_SOCK; SSH_AGENT_PID=5088; export SSH_AGENT_PID; echo Agent pid 5088;

-cスイッチを指定すると、エージェントはCシェル構文を使用します。デフォルト（および-sスイッチを明示的に指定する場合）では、Bourne Shell構文が使用されます。これらの変数は現在のシェルで設定する必要があるため、通常、ssh-agent呼び出しはevalコマンドと組み合わされます。

 $ eval `ssh-agent` Agent pid 5088

エージェントは、シグナルまたはコールによって明示的に終了されるまで動作します

 $ ssh-agent -k

エージェントが認識している秘密鍵のリストは、同じssh-addコマンドで-lコマンドラインスイッチを使用して表示できます。このコマンドは、各キーのフィンガープリントも報告します。

 $ ssh-add -l 1024 46:88:64:82:a7:f9:aa:ea:3b:21:9e:aa:75:be:35:80 /home/user/.ssh/id_rsa (RSA)

ssh-agentの使用例を以下に示します

さらに、エージェントは別の問題を解決します。秘密鍵を暗号化した場合、その秘密鍵にアクセスすると、毎回パスワードを要求されることはありません。エージェントを使用する場合、パスワードを入力する必要があるのは、エージェントにキーを追加するときだけです。

ローカル設定

フォームの行のセットを見るたびに

 ssh -p 2022 user@server.com -o StrictHostKeyChecking=yes -i ~/.ssh/server.pem

彼らは私にルーブルを与えました、そして、私はソチに長い間住んでいました。

ローカルマシンで、ファイル$ HOME / .ssh / configを見つけることができます。

 Host server User root HostName 192.168.0.3 IdentityFile ~/.ssh/server.pem Host example.com User admin IdentityFile ~/.ssh/production.pem

したがって、このファイルにはホストのほとんどのパラメーターを書き込むことができ、毎回入力する必要はありません。

他にセキュリティを改善する方法

1.キー認証を使用する場合、パスワードが残っていることを忘れないでください。秘密キーをどのように保護しても、攻撃者はキーを盗むことなくqwertyパスワードを取得してログインできます。

いくつかのソリューションを区別できます。

非常に複雑なパスワードを設定します。これを見つけて安全な場所に保管することは困難です。これにより、別のログイン方法を使用できます。
パスワードを完全に削除しますが、sudoなどに問題がある可能性があります
サーバーでパスワード認証を無効にします。実際には、これは通常、rootユーザーには禁止されています。すべてのユーザーに対して禁止されたままです。

パスワード認証なし / etc / ssh / sshd_config

2. ssh v1の使用を禁止することもできます

/ etc / ssh / sshd_configの プロトコル2

3.そして、ファイアウォール上の信頼できないソースへのSSHアクセスを必ず閉じてください

4.以前は、ポートを標準22から別のポートに変更することをお勧めしますが、非標準ポートへのログイン試行回数を観察することは確かです。これはハッキングに対する保護ではありません。

5.すでにパスワードの選択を検討している場合、パスワードを選択する試行を制限するためにfail2banを構成することは不要です。

6.プロトコルとライブラリは定期的に問題と脆弱性を発見します。ここでの詩は普遍的なアプローチです。ソフトウェアの更新に常に注目し、少なくともセキュリティパッチを定期的にインストールしてください。

7. ssh-agentはファイルをコピーするよりも安全ですが、たとえばサーバー上のrootユーザーによってハッキングされる可能性もあります。したがって、必要な場合にのみ転送を有効にすることをお勧めします。

結論

どのように聞こえても、ドキュメントを読んでください。

SSHは非常に安全なプロトコルですが、多くの場合、人的要因が問題の主な原因です。セキュリティに注意してください。

使用材料

SSHキーによるセキュリティ

SSHキーのエージェント管理

SSHで作業中のホワイトスポット