Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
SSH公開鍵認証による接続 / Connecting with SSH Public Key ...
Search
kaityo256
PRO
March 27, 2025
Technology
2
200
SSH公開鍵認証による接続 / Connecting with SSH Public Key Authentication
SSHの仕組み。
・鍵交換
・ホスト認証、ユーザ認証
・SSHエージェント
・SSHエージェント転送
kaityo256
PRO
March 27, 2025
Tweet
Share
More Decks by kaityo256
See All by kaityo256
論文紹介のやり方 / How to review
kaityo256
PRO
15
77k
デバッグの話 / Debugging for Beginners
kaityo256
PRO
9
1.4k
ビット演算の話 / Let's play with bit operations
kaityo256
PRO
6
420
GNU Makeの使い方 / How to use GNU Make
kaityo256
PRO
15
5.1k
制限ボルツマンマシンの話 / Introduction of RBM
kaityo256
PRO
3
1.1k
論文の読み方 / How to survey
kaityo256
PRO
219
160k
リンゴゲームと貧富の差 / Origin of the disparity of wealth
kaityo256
PRO
14
14k
渡辺研Slackの使い方 / Slack Local Rule
kaityo256
PRO
9
9k
時間の矢について / Time's arrow
kaityo256
PRO
12
18k
Other Decks in Technology
See All in Technology
Cloud Native PG 使ってみて気づいたことと最新機能の紹介 - 第52回PostgreSQLアンカンファレンス
seinoyu
0
150
Cline、めっちゃ便利、お金が飛ぶ💸
iwamot
18
17k
みんなで育てるNewsPicksのSLO
troter
4
1.1k
我々に残された仕事はあるのか?
taishiyade
0
200
LINE Notify互換のボットを作った話
kenichirokimura
0
100
AIが変えるソフトウェア開発__未来のアジャイルチームとは__.pdf
buchirei
0
370
モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実
kzkmaeda
0
100
[CATS]Amazon Bedrock GenUハンズオン座学資料 #2 GenU環境でRAGを体験してみよう
tsukuboshi
0
120
20250326_管理ツールの権限管理で改善したこと
sasata299
0
150
React Server Componentは 何を解決し何を解決しないのか / What do React Server Components solve, and what do they not solve?
kaminashi
5
1.1k
LINEギフトのLINEミニアプリアクセシビリティ改善事例
lycorptech_jp
PRO
0
150
職種に名前が付く、ということ/The fact that a job title has a name
bitkey
1
220
Featured
See All Featured
Become a Pro
speakerdeck
PRO
27
5.2k
A Philosophy of Restraint
colly
203
16k
Building Flexible Design Systems
yeseniaperezcruz
328
38k
Six Lessons from altMBA
skipperchong
27
3.7k
Building Applications with DynamoDB
mza
94
6.3k
Faster Mobile Websites
deanohume
306
31k
Code Review Best Practice
trishagee
67
18k
Making the Leap to Tech Lead
cromwellryan
133
9.2k
Writing Fast Ruby
sferik
628
61k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
102
18k
Automating Front-end Workflow
addyosmani
1369
200k
Stop Working from a Prison Cell
hatefulcrawdad
268
20k
Transcript
1 SSH公開鍵認証による接続 慶應義塾大学理工学部物理情報工学科 渡辺
2 端末とは もともとは大型コンピュータ(ホスト)に接続され、利用者が命令を送るための インタフェースのこと ホストコンピュータ 端末(ユーザーインタフェース) ホストコンピュータは高価であり、複数人で共有して利用するために 端末が必要だった
3 端末エミュレータ Macの「ターミナル」やWSLのUbuntuの画面は、 「端末エミュレータ」と呼ばれ、VT100の動作 をエミュレートするものがほとんど ClickRick – CC-BY-SA 3.0 https://commons.wikimedia.org/w/index.php?curid=6693684
ホスト IBM System/360 端末 IBM 2260 DEC PDP-11 VT100 VT100 • 昔はタイプライターが端末であった(テレタイプ端末, TTYの語源) • その後ディスプレイを使ったビデオ端末が出現 • ホストコンピュータにはビデオ端末が付属していたが、DECのVT100が端末 のスタンダードに
4 リモート接続 パーソナルコンピュータから、別の強力なコンピュータに遠隔から接続したい →リモート接続 自宅や居室 大学やサーバ室にあるサーバ 手元のPCの端末から、遠隔にあるマシンにリモートログインして作業 リモートにあるサーバに直接ログインしているかのよう作業できる リモートログインに使われたのがtelnetやrlogin
5 リモート接続とセキュリティ 自宅や居室 大学やサーバ室にあるサーバ telnetやrloginは通信を平文で送受信する user: password インターネットの通信は容易に傍受可能 通信路を傍受すると、接続先、ユーザ名、パスワードなどが全て見えてしまう セキュアな通信手段が欲しい
SSH
6 SSHとは SSH (Secure Shell) telnetやrlogin、rsh、ftpなどを代替するために生まれた SSHは規格であり、その実装の一つがOpenSSH $ ssh –V
OpenSSH_9.7p1, LibreSSL 3.3.6 SSHの役割 • 通信路の暗号化 • 全ての通信を傍受されても、盗聴者が内容を復元できないようにする • 認証(ホスト認証、ユーザ認証) • ホスト認証:接続しようとしているホストが正しいことを確認 • ユーザ認証:接続しようとしているユーザが正しいことを確認 接続時のフロー 鍵交換による通信路暗号化 ホスト認証 ユーザ認証 以後の通信は暗号化 ……
7 鍵交換 通信路が全て傍受されている前提で、秘密の情報を共有したい Alice Bob 𝑎, 𝐴 𝑏, 𝐵 AliceとBobが鍵のペア(𝑎,
𝐴)と(𝑏, 𝐵)を生成 𝐴 𝐵 𝐵 𝐴 公開鍵𝐴, 𝐵を互いに伝える(傍受可能) 𝑠 = 𝑎𝐵 𝑠 = 𝐴𝑏 𝑠 = 𝑎𝐵 = 𝐴𝑏を計算し、共通の秘密情報とする 𝐴, 𝐵 𝑠 傍受者は通信傍受で得た𝐴, 𝐵から秘密情 報𝑠を再現できない 以上のアルゴリズムをDiffie–Hellman (DH)鍵交換と呼ぶ
8 鍵交換 離散対数問題を使った実装例 Alice: 秘密の整数𝑎に対して𝐴 = 𝑔𝑎 mod 𝑝を計算し、公開鍵とする Bob:
秘密の整数𝑏に対して𝐵 = 𝑔𝑏 mod 𝑝を計算し、公開鍵とする 𝑠 = 𝐵𝑎 mod 𝑝 = 𝑔𝑎𝑏 mod 𝑝 AliceはBobから受け取った𝐵を使って以下を計算する BobはAliceから受け取った𝐴使って以下を計算する 𝑠 = 𝐴𝑏 mod 𝑝 = 𝑔𝑎𝑏 mod 𝑝 傍受者は𝐴, 𝐵の情報から𝑠を計算することができない(離散対数問題) →AliceとBobは、傍受されている通信路を使って秘密の情報𝑠を共有できた 楕円曲線上の演算を用いる Elliptic-curve Diffie-Hellman (ECDH)もよく使われている 𝑔と𝑝は既知とする
9 認証 鍵交換により通信路が暗号化されたとしても、通信相手が正しい相手であるか どうかはわからない 公開鍵による認証
10 公開鍵認証 Alice Bob Aliceが通信を通じてBobに「いま通信しているのは自分である」と証明したい あらかじめAliceは鍵のペアを作っておき、公開鍵をBobに渡しておく 秘密鍵(署名鍵) 公開鍵(検証鍵)
11 公開鍵認証 Alice Bob 1. BobはAliceにメッセージを送る 2. Aliceはメッセージに秘密鍵で 署名をしてBobに送り返す 3.
BobはAliceの公開鍵で署名を検証する 4. 検証に成功したら認証完了
12 ホスト認証 インターネットは情報がリレーされるので、途中に悪意ある中継点があると 通信路が書き換えられるおそれがある 通信相手が正しいホストであると確認する→ホスト認証 ユーザ認証の前に行われる
13 ホスト認証(初回) 初めて接続するホストで、クライアントが公開鍵を持っていない場合 1. ホストから公開鍵が送られてくる 2. この公開鍵を信じるか確認する 3. 鍵を信じる場合(yes)、この鍵を 「知っているホスト」に登録する
クライアント ホスト .ssh/known_hosts Are you sure you want to continue connecting (yes/no/[fingerprint])?
14 ホスト認証(二回目以降) クライアント ホスト ホストが秘密鍵で署名したメッセージを すでに所持している公開鍵で検証 ≠ ホストがなりすましである場合、異なる 公開鍵を送ってくるのでわかる 公開鍵を偽装しても、秘密鍵を持っていな
いので公開鍵に対応した署名ができない ≠
15 公開鍵認証のまとめ • 公開鍵認証には、署名に使う秘密鍵と、検証に使う公開 鍵のペアを使う • 検証側は、あらかじめ相手の公開鍵を保持しておく • 公開鍵で検証できる形で署名が可能なのは、秘密鍵の所 持者のみ
• 正しく署名できた人を「公開鍵に対応する秘密鍵の所持 者である」と認証できる ユーザ認証 ホスト認証 • ホスト認証でも、あらかじめ相手の公開鍵を登録してお くことが望ましい • しかし、初回接続時に公開鍵のフィンガープリントを確 認し、問題なければ登録する、という運用が多い https://docs.github.com/ja/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints https://docs.github.com/ja/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints 例:GitHubのSSHフィンガープリント
16 秘密鍵の暗号化 秘密鍵は電子ファイルなので、容易にコピーされてしまう → 暗号化により守る Abracadabra パスフレーズ もし秘密鍵が流出したとしても、暗号化に用いたパスフレーズが わからなければ秘密鍵が使えない(知識認証)
17 秘密鍵の暗号化 (1) ターミナルからGitHubにアクセスしようとする $ git push (2) パスフレーズにより秘密鍵を復号 (3)
秘密鍵を使って認証 パスフレーズによる知識認証でGitHubにアクセスしている わけはないことに注意
18 SSHエージェント 接続のたびにパスフレーズを入力するのは面倒 → SSHエージェント (1) パスフレーズにより秘密鍵を復号 (2) 復号した秘密鍵をSSHエージェントに記憶してもらう (3)
次回接続から記憶した秘密鍵を使う(パスフレーズ入力を省略)
19 多段SSH ユーザ サーバ まずサーバにログインし、そのサーバからGitHubにアクセスしたい GitHubから見たらサーバが接続元なので、そこに秘密鍵が欲しい しかし、サーバに秘密鍵を置きたくない→SSHエージェント転送
20 SSHエージェント転送 ユーザ サーバ ユーザPCの エージェント サーバの エージェント SSHエージェントが署名情報を転送することで、GitHubは接続したクラ イアントが登録済みの公開鍵の所持者であるとわかる
認証成功 署名リクエスト 署名リクエスト 署名応答 署名応答
21 SSHエージェントのまとめ SSHエージェントの役割は以下の2つ 1. 復号済みの秘密鍵を記憶する 2. 別の接続先に署名を転送する SSHエージェントを使うためには、SSHエージェントが起動し、 常駐している必要がある MacはKeyChainがSSHエージェントを兼ねる
Windows (WSL)は別途SSHエージェントを起動する必要がある SSHエージェントの使い方 復号した秘密鍵の記憶には ssh-add SSHエージェント転送をする場合は ssh –Aオプション ログアウトしたら秘密鍵の情報は消える