背景 - なぜ SSH キーを使用し、暗号化する必要があるのか?#
まずは 3 つの理由を挙げます。見たくない方は操作手順に直接飛んでください。(2 分もかからずに操作できます)
第一の理由 - パスワードではなく SSH キーを使用すべき#
日常の業務で、私たちは頻繁に git
、rsync
、ssh
などのツールを使用しますが、従来のパスワード認証方式は面倒で攻撃を受けやすくなる可能性があります。以下のような問題が考えられます:
- 盗聴リスク:従来のパスワード入力方式は、盗聴者に見られる可能性があり、安全性の問題を引き起こします。SSH キーを使用すれば、パスワードを入力する必要がなく、盗聴リスクが大幅に減少します。
- パスワード管理の複雑さ:複数のリモートサーバーで異なるパスワードを使用すると、パスワードの混乱や忘却を招く可能性があります。SSH キーを使用すれば、少数のキー対を管理するだけで済み、パスワード管理の複雑さが大幅に簡素化されます。
- リモートサーバーの安全性:パスワードでリモートサーバーにログインすることは、悪意のある攻撃者に簡単に攻撃されるリスクがありますが、SSH キーを使用することで、攻撃者が身分を偽造してアクセスすることが難しくなり、リモートサーバーの安全性が向上します。
第二の理由 - どんな場合でも SSH プライベートキーは暗号化すべき#
SSH キーを使用していても、プライベートキーの保護には注意が必要です。便利だからといって SSH プライベートキーを暗号化しないのは危険です~~(多くの人がそうしているのでは?)
- プライベートキーは認証の核心:それはあなたのシステムとデータの主な鍵に相当します。プライベートキーが漏洩すると、悪意のある者があなたの身分を偽造してシステムにアクセスし、機密情報を盗んだり、未承認の操作を行ったりする可能性があります。
- プライベートキーは安全でない環境に存在する可能性がある:ローカルコンピュータ、モバイルデバイス、またはネットワークを介して転送される場合、これらの環境は安全ではありません。プライベートキーを暗号化することで、たとえプライベートキーが無許可でアクセスされた場合でも、あなたのデータやシステムが直ちに露出することはありません。
- デバイスが盗まれたり、紛失したり、他人にアクセスされた場合:暗号化されたプライベートキーは追加のセキュリティ層を提供します。悪意のある者がプライベートキーのファイルを取得できたとしても、その暗号化状態は直接使用を妨げます。
- マルウェアやウイルス:未暗号化のプライベートキーのファイルを探してシステムをスキャンする可能性があります。例えば、皆さんのコンピュータにはいくつかの海賊版ソフトウェアがあるでしょう?プライベートキーが暗号化されていれば、彼らは機密情報を容易に取得できず、攻撃のリスクが減少します。
時には、便利さから平文のプライベートキーを QQ などで別のコンピュータに転送する人もいますが、これは非常に危険な行為です。これは平文のプライベートキーです~~
第三の理由 - SSH-Agent を使用してパスワード入力の回数を減らす#
単に暗号化されたプライベートキーを使用するだけでは、パスワード入力の問題を根本的に解決することはできません。それは、すべてのパスワードを同じパスワードにまとめるだけです。また、毎回 git pull
の際にプライベートキーのパスワードを入力するわけにはいきません。そこで、頻繁なパスワード入力の煩わしさやパスワード漏洩のリスクを解決するために、SSH-Agent を導入します。
SSH-Agent は 解読されたプライベートキーを一時保存し、ユーザーはセッション開始時に一度だけパスワードを入力すれば、その後の接続は自動的に解読されたプライベートキーを使用します。これにより、パスワード入力の回数を大幅に減少させ、パスワードが盗聴されたり、傍受されたりする可能性を回避します。また、複数のリモートサーバーと頻繁にやり取りするユーザーにとって、SSH-Agent は 作業効率を大幅に向上させることができます。
BOSS の言葉: agent の本質はキーをメモリにロードすることです。メモリがキーを漏洩する可能性はありますが、非常に複雑な方法と脆弱性が必要で、一定の権限も必要です。また、現在の OS にはメモリアドレスのランダム化があり、これに対抗しています。
操作手順#
ローカルプライベートキーの暗号化#
あなたのローカルに既に SSH キー対があると仮定します。(GitHub を使用している方は皆さん持っているはずです。持っていない場合は ssh-keygen
を使用して生成するか、文末の SSH 関連の記事を参照してください)
以下が ローカルプライベートキーを暗号化するコマンド です(<id_rsa_path>
はあなたのローカルの ssh プライベートキーのパスで、一般的には ~/.ssh/id_rsa
です)
ssh-keygen -p -f <id_rsa_path>
これで暗号化が完了しました。次のステップは ssh-agent を起動することです。
SSH-Agent を使用して解読されたプライベートキーを管理する#
以下は、ssh-agent
を起動し、あなたのコンピュータ上のデフォルトのキー対をエージェントにロードするためのシェルコードです:
if [ -z "$SSH_AUTH_SOCK" ] ; then
eval `ssh-agent`
ssh-add # <id_rsa_path>、指定しなければデフォルト値を使用
fi
しかし、この方法には多くの問題があります。新しいシェルセッションを開くと、エージェントも再度開く必要があり、前のセッションが終了するときにエージェントを閉じなければ、そのエージェントはあなたのコンピュータのプロセス内で生き続けます。
SSH-Agent 設定の永続化による便利さと安全性の実現#
⚠️⚠️⚠️ 注意:この方法は個人のコンピュータにのみ適しています ⚠️⚠️⚠️
上記の問題を解決するために、SSH-Agent の起動設定をシェルの設定ファイルに追加することをお勧めします。これにより、毎回ターミナルセッションを開始する際に SSH-Agent が自動的に起動し、あなたのプライベートキーがロードされます。これにより、便利さと安全性が向上します。
以下はサンプルコードです。これをあなたの ~/.bashrc
または ~/.bash_profile
ファイルに追加してください(zsh の場合は ~/.zshrc
または ~/.zprofile
、私は個人的に rc ファイルに入れることをお勧めします。多くの場合、ログインシェルのメカニズムがトリガーされないためです):
fish バージョンはこちらを参照
このファイルに追加してください ~/.config/fish/config.fish
set SSH_ENV_FILE "$HOME/.ssh/agent-environment"
set SSH_TIMEOUT 86400 # 24 時間を秒で
function ssh_start_agent
ssh-agent -c -t "$SSH_TIMEOUT" > "$SSH_ENV_FILE"
chmod 600 "$SSH_ENV_FILE"
source "$SSH_ENV_FILE"
ssh-add # [<id_rsa_path>] あなたのパスに変更
end
if test -f "$SSH_ENV_FILE"
source "$SSH_ENV_FILE"
if not ps -p "$SSH_AGENT_PID" > /dev/null
ssh_start_agent
end
else
ssh_start_agent
end
SSH_ENV_FILE="$HOME/.ssh/agent-environment"
SSH_TIMEOUT=86400 # 24 時間を秒で
ssh_start_agent(){
ssh-agent -t $SSH_TIMEOUT | sed 's/^echo/#echo/' > "${SSH_ENV_FILE}"
echo "新しい SSH エージェントの初期化に成功しました"
chmod 600 "${SSH_ENV_FILE}"
. "${SSH_ENV_FILE}"
ssh-add # [<id_rsa_path>] あなたのパスに変更
}
if [ -f "${SSH_ENV_FILE}" ]; then
. "${SSH_ENV_FILE}"
if ! ps -p "$SSH_AGENT_PID" > /dev/null; then
start_ssh_agent
fi
else
ssh_start_agent
fi
(これは stackoverflow の高評価の例で、少し有効時間を調整しました。コンピュータが常にシャットダウンしない場合、1 日に 1 回パスワードを入力する必要があります。ssh フォワードの状況下では問題が存在しますが、個人のコンピュータでは十分です)
このコードは、毎回シェルセッションを開始する際に SSH-Agent が実行されているかどうかを確認します。実行されていない場合、自動的に起動し、あなたのプライベートキーをロードします。この方法により、SSH-Agent の便利さと安全性を常に享受できます。(真に理解できない場合は ChatGPT に尋ねてみてください。実際のポイントは、SSH-Agent の SSH_AUTH_SOCK
などの情報をファイルに保存し、他のシェルセッションでも読み取れるようにすることです)
さて、実際の操作はこれだけです。
ssh-agent 使用時の注意事項#
もちろん、ssh-agent を使用することが特に安全で、心配がないわけではありません。実際、ssh-agent を使用する際には多くの問題があります。以下は ssh-agent 使用時のいくつかの注意事項です:
- 他の人が root 権限を持つコンピュータで
ssh-agent
を実行しないこと:信頼性の低いコンピュータでssh-agent
を実行すると、悪意のあるユーザーがssh-agent
を通じてあなたの秘密データにアクセスし、安全を脅かす可能性があります。(日常的にコンピュータを使用しないときはロック画面を設定し、共有コンピュータでは実行しないでください) - プロキシ接続の転送を慎重に使用すること:
ssh-agent
はプロキシ接続の転送を許可することができますが、これは特定の状況で非常に便利です。ただし、信頼できるコンピュータにのみプロキシ接続を転送すべきであり、そうでないホストに秘密データを取得されないようにする必要があります。 - ログアウト時にキーとエージェントをアンマウントすること:コンピュータからログアウトするか、シェルセッションを終了する際には、無許可のアクセスを避けるために、キーと
ssh-agent
をアンマウントしていることを確認してください。これはssh-agent -k
コマンドを使用して実行できます。
ssh-agent
を使用する際は、上記の注意事項に従って、あなたの秘密データとシステムの安全を確保してください。
後記#
実際、ssh キーの管理方法は ssh-agent のみではなく、1password の CLI を試すこともできますが、私はあまり使用したことがありません。
この記事は、私自身の安全に関する記録に過ぎず、実際には門外漢である可能性があります。今後、サイバーセキュリティシリーズとして、私の生活の中でのネットワークセキュリティに関する知識を活用していく予定です。
注意:この記事に記載されている内容は、個人的な見解と経験の共有に過ぎず、絶対的に正確な安全なアドバイスではありません。より詳細で専門的な安全アドバイスが必要な場合は、安全の専門家や関連文献に相談してください。
参考資料#
- SSH チュートリアル - 網道: SSH の基礎知識については阮一峰のこのチュートリアルを参照してください。
- ssh-agent の使用と、どのように安全に一度だけ ssh パスワードを入力するか:ここでは ssh-agent が堡垒机の転送のシナリオについて言及されていますが、私の側には対応する使用シナリオがないため、この記事では触れていません。
- ssh-agent の落とし穴と、プロキシを安全に使用する方法:上記の記事と同じ著者によるもので、ssh-agent 使用時の注意事項について述べています。
更新#
- 2023-08-17 19:11 v0.7 fish バージョンのコードを追加
- 2023-08-22 22:17 v0.8 同僚から、太字の部分が多すぎて記事が非常に派手に見え、視覚体験に影響を与えていると指摘されたため、修正しました。
- 2023-08-22 23:05 v1.0 少し無駄な部分を削除し、基本的に合格点を得られるようになりました。