0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@Geek-3340

SSH接続について～インフラ知識０からAWSデプロイ学習記録～

0
Posted at

はじめに

この記事はAWSに自作アプリをデプロイするための学習記録です。

筆者の自己紹介

  • 異業種、実務未経験からフルスタックエンジニアを目指して転職活動中
  • 2024年10月から学習を開始、オンラインスクール卒業を経て、現在も学習を継続中

ポートフォリオアプリ：https://github.com/geek-3340/Fameal_app/tree/main

前回までの記事：

今回の内容

前回まではLinuxコマンド、ネットワーク基礎についてまとめてきました。
今回はAWSのEC2へ接続をする上で必須の基礎知識となるSSH（公開鍵認証によるリモートログイン）について解説していきます。

学習記録

SSHとは

SSH (Secure Shell) とは、リモートマシンに暗号化された通信でログインして操作するためのプロトコル

SSHは通信が暗号化されるので、たとえ途中で通信を傍受されても中身は読めない
今ではサーバー管理 = SSHと言っていいくらい標準的なツール

SSHの主な使われ方

  • AWS EC2にログインしてサーバー管理
  • GitHubにgit pushする時の認証
  • Dockerコンテナへの接続

パスワード認証 vs 公開鍵認証

SSHでログインする方法は大きく2つ

パスワード認証

普通のログインと同じで、「ユーザー名 + パスワード」で認証
シンプルだが以下の問題がある

  • パスワード総当たり攻撃に弱い
  • パスワードを使い回しがち
  • AWS EC2ではそもそも無効になっているのがデフォルト

公開鍵認証

鍵ペア（公開鍵 + 秘密鍵） を使う認証方式
こっちがデファクトスタンダード

仕組みのざっくりイメージ

あなたのPC                          サーバー (EC2)
─────────                           ─────────────
[秘密鍵] (絶対に外に出さない)        [公開鍵] (事前に登録しておく)

１.「ログインさせて」
                         ===>
                                   2.「じゃあこのチャレンジ文を秘密鍵で署名して」
                         <===
3.秘密鍵で署名して返す
                         ===>
                                   4.公開鍵で署名を検証 → OKならログイン許可

なぜこれが安全なのか

秘密鍵は一切ネットワークを流れない からに尽きる

サーバーは「公開鍵で署名を検証できるか」だけを確認するので、秘密鍵そのものは送信されない
つまり、たとえ通信を盗聴されても、秘密鍵が手に入らない以上、通信を解読するのは事実上不可能
秘密鍵はあなたのPCの~/.ssh/の中にずっと留まったまま

これが公開鍵暗号を使った認証の本質

鍵ペアを生成する

実際に鍵ペアを作ってみる

wsl
ssh-keygen -t ed25519 -C "your-email@example.com"

オプションの意味

  • -t ed25519: 鍵の暗号アルゴリズムを指定。ed25519は新しめで、短くて安全。昔はrsaが主流（-t rsa -b 4096）
  • -C "...": コメント。誰の鍵か後で識別するため、メールアドレスを入れる慣習

対話プロンプト

実行すると3つ聞かれる

Enter file in which to save the key (/home/user/.ssh/id_ed25519):

→ 鍵の保存先。そのまま Enter でデフォルト場所（~/.ssh/id_ed25519）

Enter passphrase (empty for no passphrase):
Enter same passphrase again:

→ パスフレーズ。秘密鍵自体にもパスワードを掛けられる
設定すると「秘密鍵ファイルを盗まれても、パスフレーズがないと使えない」状態になる
学習用なら空でOK（Enter2回押し）
本番用は設定するのが安全だが、毎回打つのが面倒なのでssh-agentを併用するなどの運用方法がある

生成された鍵を確認

wsl
ls -la ~/.ssh/

出力例

-rw------- 1 user user  411 May 16 ... id_ed25519
-rw-r--r-- 1 user user  103 May 16 ... id_ed25519.pub
  • id_ed25519: 秘密鍵。権限が600（所有者だけ読み書き）になってる。絶対に他人に見せない
  • id_ed25519.pub: 公開鍵。権限が644。これは公開してOKで、SSH接続をするサービスなどに対して設定する

前回の記事で扱ったLinuxのファイル権限がここで効いてくる
SSH秘密鍵は実際にこの600権限じゃないとSSHが拒否する仕様
「鍵が緩い権限で置かれてるなら、それは安全じゃない」とSSH側が判断

公開鍵の中身を見てみる

wsl
cat ~/.ssh/id_ed25519.pub

1行のテキストが出る

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIxxxxxxxxxxxxxxxxxxxxx your-email@example.com

これが公開鍵
例としてAWSのEC2にこの1行を登録することで、「あなたの秘密鍵でログインしていいよ」という権限が付与される

秘密鍵の中身

wsl
cat ~/.ssh/id_ed25519

-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAA...
（長い文字列）
-----END OPENSSH PRIVATE KEY-----

これが秘密鍵
この内容は一生誰にも見せない
Gitにコミットなんかしたらまじで終わり（後述）
AIのチャット画面にペーストすることもNG！

SSHの安全運用ポイント

ここは事故を防ぐ知識として絶対押さえておきたい

秘密鍵を絶対にGitにコミットしない

~/.ssh/id_ed25519       # ← 絶対に push しない

.gitignoreに常に入れておくこと

.gitignore
.env
.env.*
!.env.example
*.pem
id_rsa
id_ed25519 # このように設定

過去の事故事例: GitHubのパブリックリポジトリにAWSアクセスキーを誤ってpushすると、数分以内に世界中のbotが見つけて悪用する
気付いた時には数十万円〜数百万円の請求が来ていた、という事故が定期的に起きているらしい

秘密鍵が漏れたかも、と思ったら

即座に以下を実施する

  1. その鍵を使ってる全サーバーのauthorized_keysから該当の公開鍵を削除
  2. 新しい鍵ペアを生成

おわりに

今回はSSH接続についての解説でした！
特に公開鍵・秘密鍵による認証は、AWSリソースへの不正アクセスによる多額の請求などのセキュリティ事故等を防止するためにも、必須の知識として押えておきたいところです。

ご覧いただきありがとうございました🔥

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?