SSH鍵認証

パスワードでログインするのをやめる

サーバーに入る手段がパスワードだけだと、総当たりで試され続けます。インターネットに置いた瞬間から、心当たりの無い接続が延々と来ます。人が覚えられる長さのパスワードでは、いつか当たります。

代わりに使うのが公開鍵認証です。仕組みはこうです。

1. 手元で鍵のペアを作る。秘密鍵と公開鍵の2つができる
2. 公開鍵のほうだけをサーバーに置く
3. 接続するとき、サーバーが「この公開鍵と対になる秘密鍵を持っているか」を確かめる

秘密鍵はネットワークに流れません。サーバーに置くのは公開鍵だけなので、サーバーが盗まれても秘密鍵は漏れません。当てずっぽうで通せる長さでもありません。

鍵を作る

-t は鍵の種類の指定です。ed25519 は短くて速く、いま新しく作るならこれで構いません。古い解説には rsa が出てきますが、こちらを選ぶ理由は減っています。

実行すると置き場所とパスフレーズを聞かれます。既定のまま進めると、次の2つができます。

.pub が付いているほうが公開鍵です。ここを取り違えて秘密鍵を配ってしまう事故が一定数あります。渡すのは .pub のほう、と覚えてください。

公開鍵をサーバーに置く

サーバー側が見るのは、そのユーザーのホームの下の決まった場所です。

>> で追記しているのは、複数人が同じユーザーで入る場合に、1行ずつ鍵を並べられるからです。> で上書きすると先客の鍵が消えます。

権限が緩いと、鍵は使ってもらえない

ここでつまずく人がとても多いところです。鍵を正しく置いたのに入れない。原因はたいてい権限です。

700 は持ち主だけが読み書きと移動をできる状態、600 は持ち主だけが読み書きできる状態です。他のユーザーから見える場所に鍵の一覧が置いてあると、誰かが自分の鍵を書き足せてしまいます。だから sshd は、権限が緩い authorized_keys をわざと無視します。親切心で黙って使ってくれたりはしません。

入れないときは、まずここを疑ってください。

実際に使うときの形

最後にコマンドを書くと、入って実行して抜ける、までを一気にやります。デプロイの自動化はこの形を使います。初回は接続先の身元を確認するかを聞かれ、yes と答えると相手の指紋が ~/.ssh/known_hosts に記録されます。あとで指紋が変わったときに警告が出るのは、この記録があるからです。

この学習環境は外のネットワークから切り離されていて、実際に外から入ってくる接続はありません。そこで確かめるのは、受け入れる側の準備が正しく整っているかです。鍵のペアが噛み合っていること、公開鍵が正しく登録されていること、権限が sshd に受け入れられる状態であること、そして sshd が待ち受けていること。入れない原因のほぼすべては、この4つのどれかにあります。

ペアが噛み合っているかを確かめる

秘密鍵から公開鍵を計算し直すコマンドがあります。

出てきた文字列が authorized_keys に登録した行と一致すれば、そのペアは確かに噛み合っています。別のマシンで作った鍵を貼り間違えた、といった事故はこれで見つかります。

手を動かす

deploy ユーザーの鍵を作り、公開鍵を登録し、権限を整えます。そのうえでペアが噛み合っていることを自分で確かめます。