SSH はエンドツーエンドで通信を保護するためのネットワークプロトコルで、お使いのネットワーク内同士だけでなく、外部のネットワークとの通信も保護することができます。 SSH で他のコンピュータに接続するには、接続先でのユーザ名と適切な認証手段を設定する必要があります。

SSH はクライアント／サーバ型のプロトコルです。他のホストからの接続を受け付けるには sshd デーモンを動作させておく必要があります。また、各ホストで動作する sshd にはそれぞれ独自の設定を行うことができますので、アクセス可能なユーザを制限したり、許可する認証方式を制限したりすることもできるようになっています。

認証と暗号化の機能は暗号鍵対によって行われます。それぞれの鍵対には公開鍵と機密鍵という 2 つの鍵が存在し、公開鍵は暗号化を、機密鍵は暗号の復号化を行うために使用します。また、機密鍵がきちんと保護されている限り、公開鍵は誰にでも配布してかまいません。機密鍵が漏洩してしまうと、機密鍵の元の所有者になりすまして暗号化した通信を行うことができるようになってしまいます。

SSH ではサーバとクライアントの双方が互いに認証しなければならない仕組みにより、強力な保護を提供しています。クライアントが SSH での接続を開始すると、サーバは自身の持つ公開鍵を提示します。示された公開鍵が既知のものであった場合 (クライアント側の ~/.ssh/known_hosts 内に保存されます) 、クライアントはサーバを信頼してそのまま処理を続行します。既知のものでなかった場合は、サーバを信頼して良いかどうか、下記のようにしてユーザに尋ねます:

The authenticity of host '192.168.22.219 (192.168.22.219)'
   can't be established. ECDSA key fingerprint is
   SHA256:yXf6pjV26N0fegvEYIt3HgG95s3Q1X6WYRhtHLF99pUo.
   Are you sure you want to continue connecting (yes/no/[fingerprint])?

ユーザは yes (このまま接続を続ける) または no (接続を中止する) のいずれかを入力できるほか、比較のために鍵の指紋 (fingerprint) そのものを入力することもできます。

注記: ホスト鍵の指紋 (fingerprint) について

ホスト鍵の指紋 (fingerprint) を接続するユーザに配布することで、接続時にホスト鍵が正しいかどうかを確認できるようになります。上記の表示で指紋そのものを入力すると、 ssh 側で指紋が一致しているかどうかを確認し、一致した場合にのみ接続を続けることができるようになります。これにより、目視で比較するよりずっと信頼性の高い確認を行うことができます。

これは、ユーザに検証を委ねても、セキュリティという観点では信頼性が低いためです。なお、指紋が一致していなかった場合でも、再度 yes を入力するか、表示された指紋をそのまま貼り付けることで、接続を続行することができます。また、より強力な保護として、証明書認証を使用する方法もあります。これは大規模向けの認証機構となるほか、上記のようなユーザへの手間を減らすことにもつながります (詳しくは 22.8項 「OpenSSH での証明書認証」 をお読みください) 。

接続先ホストの公開鍵が変更された場合、下記のようにセキュリティ警告を表示して接続が拒否されます:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:keNu/rJFWmpQu9B0SjIuo8NLjbeDY/x3Tktpl7oDJqo.
Please contact your system administrator.
Add correct host key in /home/geeko/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/geeko/.ssh/known_hosts:210
You can use following command to remove the offending key:
ssh-keygen -R 192.168.121.219 -f /home/geeko/.ssh/known_hosts
ECDSA host key for 192.168.121.219 has changed and you have requested strict
checking.
Host key verification failed.

このような場合、警告メッセージを表示せずに接続を行わせたい場合は、 ~/.ssh/known_hosts 内にある古い公開鍵を削除してから再度接続を行ってください。これにより、新しい鍵を受け付けるかどうかの確認が表示されるようになります。

openssh パッケージにはサーバとクライアントのほか、ファイル転送コマンドといくつかのユーティリティが含まれています。

OpenSSH では下記のような認証方式に対応しています:

openSUSE Leap では既定で OpenSSH パッケージをインストールします。パッケージ内には、下記のようなファイルが含まれています:

OpenSSH はインストール当初の状態でそれなりに強固な設定になっていますが、サーバのセキュリティを強化するための追加設定も用意されています。

重要: リモートの SSH サーバに対するアクセスの管理について

SSH サーバに対して何らかの設定変更を行う場合は、その変更が期待通りのものであることを確認できるまで、そのマシンに対して物理的なアクセス手段を残しておくか、もしくは root の SSH セッションを開いたままにしておく必要があります。これにより、期待通りの動作で無かった場合、設定をすぐに戻すことができるためです。

既定のサーバ設定は /etc/ssh/sshd_config で、ここには既定で使用される設定が書かれています。また、コメント内には全ての既定値が示されています。既定値を変更したい場合は、これらのコメント文字を外してから、必要な設定を記述してください。たとえば下記の例では、複数のネットワークインターフェイスを持つマシンで待ち受けるポートと IPv4 アドレスを指定しています:

#Port 22
Port 2022

#ListenAddress 0.0.0.0
ListenAddress 192.168.10.100

重要: /etc/services の更新について

非標準の待ち受けポートを使用する場合は、 /etc/services ファイルを参照して、使用していないポートの中から選択してください。通常は 1024 以上の未使用ポートを使用します。設定後は、 /etc/services ファイル内にポートが使用中である旨を記録しておくことをお勧めします。

root のログインは許可しないようにしておくことが最適です。その代わり、一般ユーザでのログインを行ったあと、 sudo コマンドを利用して root 権限が必要な作業を行うようにしてください。どうしても root でのログインが必要な場合は、下記のサーバ設定例 (22.6項 「公開鍵認証」) にある PermitRootLogin prohibit-password と PasswordAuthentication のオプションを利用して、公開鍵認証のみを受け付けるように設定してください。

なお、下記の /etc/ssh/sshd_config ファイル例は、アクセス制御をより強化した設定例です:

# Check if the file modes and ownership of the user’s files and# home directory are correct before allowing them to loginStrictModes yes# If your machine has more than one IP address, define which address or# addresses it listens onListenAddress 192.168.10.100 # Allow only members of the listed groups to log inAllowGroups ldapadmins backupadmins # Or, deny certain groups. If you use both, DenyGroups is read firstDenyGroups users # Allow or deny certain users. If you use both, DenyUsers is read firstAllowUsers user1 user2@example.com user3 DenyUsers user4 user5@192.168.10.10 # Allow root logins only with public key authenticationPermitRootLogin prohibit-password# Disable password authentication and allow only public key authentication# for all usersPasswordAuthentication no# Length of time the server waits for a user to log in and complete the# connection. The default is 120 seconds:LoginGraceTime 60 # Limit the number of failed connection attempts. The default is 6MaxAuthTries 4

/etc/ssh/sshd_config ファイルを変更したあとは、下記のようにして文法チェックを行ってください:

> sudo sshd -t

なお、文法チェック機能は文法のみをチェックする仕組みであり、設定の誤りは検出されないことに注意してください。チェック完了後は下記のように入力して実行することで、設定を再読み込みさせることができます:

> sudo systemctl reload sshd.service

また、サーバの鍵ディレクトリに適切なパーミッションが設定されていることを確認してください。

/etc/ssh ディレクトリは 0755/drwxr-xr-x のパーミッションで所有者が root:root でなければいけません。

機密鍵は 0600/-rw------- のパーミッションで所有者が root:root でなければいけません。

公開鍵は 0644/-rw-r--r-- のパーミッションで所有者が root:root でなければいけません。

パスワード認証を行う場合は、接続先のマシン内にユーザアカウントとパスワードを設定し、 sshd を設定してそれを動作させておくだけです。個人用の SSH 鍵を作成する必要はありません。下記は、 sun というホストに対して suzanne というユーザ名で SSH ログインする場合の例です:

> ssh suzanne@sun

接続を行うと、まずは接続先で設定した suzanne のパスワード入力を求められます。また、 exit と入力して Enter を押すと、 SSH セッションを終了することができます。

両方のマシンでユーザ名が同じであれば、ユーザ名を指定する必要はありません。 ssh ホスト名 のように入力して実行するだけで済みます。認証が成功すると、相手側のコンピュータのコマンドラインを使用したり、 YaST のテキストモードのような対話的なアプリケーションを使用したりすることができるようになります。

これらに加えて、 ssh ユーザ名@ホスト コマンド の書式を使用することで、対話的でないコマンドを実行することもできます。この場合、ログインしてコマンドを実行したあと、そのまま接続を終了する動作になります。なお、 コマンド では適切に引用符を指定する必要があります。また、複数のコマンドはローカルのシェルと同じ方法で繋げることができます:

> ssh suzanne@sun "df -h && du -sh  /home"
> ssh suzanne@sun "sudo nano /etc/ssh/sshd_config"

リモートのマシンで sudo を実行すると、 sudo でのパスワード入力が求められます。

生成できる鍵の種類としては、 DSA, RSA, ECDSA, ECDSA-SK, Ed25519, Ed25519-SK があります。ただし、 DSA は何年も前に廃止予定とされていて、 OpenSSH 7.0 では無効化されていて使用すべきではありません。 RSA は最も一般的に使用されている種類で、古い仕組みではあるものの一般的に使用されています (なお、 OpenSSH 8.2 およびそれ以降のバージョンでは、 RSA はホスト鍵としては廃止予定になっています。ホスト鍵には ECDSA もしくは Ed25519 をお使いください) 。

Ed25519 と ECDSA はより強力で高速な鍵です。 Ed25519 が最も強力な鍵として提供されていますが、 Ed25519 や ECDSA に対応していない古いクライアントを受け付ける必要がある場合は、 3 種類全てのホスト鍵を作成してください。

注記: 古いクライアントの安全性について

古い SSH クライアントは ECDSA や ED25519 に対応していませんが、 ECDSA と ED25519 への対応は 2014 年に公開された OpenSSH 6.5 から提供されているものです。どうしても接続を受け付ける必要がある場合は、必ずセキュリティ更新を適用しておいてください。また、可能であれば古いクライアントからの接続は許可しないでください。

SSH の鍵は 2 種類の目的で使用されます。クライアントがサーバを認証するためのホスト鍵と、サーバがクライアントを認証するためのクライアント鍵です (詳しくは 22.6項 「公開鍵認証」 をお読みください) 。サーバのホスト鍵は /etc/ssh ディレクトリ内に保存され、ユーザ鍵はユーザごとのディレクトリである /home/ユーザ名/.ssh ディレクトリ内に保存されます。

なお、ユーザ側で新しい SSH 鍵を作成すると、 /home/ユーザ名/.ssh ディレクトリが作成されます。

また、ホスト鍵にはパスフレーズを設定してはいけません。

ほとんどの場合、ユーザ鍵には強力なパスフレーズを設定します。

22.4.2 SSH サーバのホスト鍵作成 #Edit source

ホスト鍵はクライアント鍵とは違った管理方法になります。ホスト鍵にはパスフレーズを設定してはならないほか、鍵対は /etc/ssh ディレクトリ内に保存します。 OpenSSH では、必要に応じて自動的にホスト鍵を生成します。たとえば下記のようになります:

> ls -l /etc/ssh
total 608
-rw------- 1 root root 577834  5月  6 2021 moduli
-rw-r--r-- 1 root root   2403  5月  6 2021 ssh_config
-rw-r----- 1 root root   3420  5月  6 2021 sshd_config
-rw------- 1 root root   1381  2月 10 2021 ssh_host_dsa_key
-rw-r--r-- 1 root root    604  2月 10 2021 ssh_host_dsa_key.pub
-rw------- 1 root root    505  2月 10 2021 ssh_host_ecdsa_key
-rw-r--r-- 1 root root    176  2月 10 2021 ssh_host_ecdsa_key.pub
-rw------- 1 root root    411  2月 10 2021 ssh_host_ed25519_key
-rw-r--r-- 1 root root     96  2月 10 2021 ssh_host_ed25519_key.pub
-rw------- 1 root root   2602  2月 10 2021 ssh_host_rsa_key
-rw-r--r-- 1 root root    568  2月 10 2021 ssh_host_rsa_key.pub

なお、 ssh-keygen には新しいホスト鍵を作成するための特別なオプションである -A が用意されています。これはそれぞれの種類のホスト鍵対が存在していなかった場合、それらを自動的に生成することができます。保存先や空のパスフレーズ設定、鍵の種類ごとのビット長や空のコメントも自動的に設定されます。下記のように入力して実行すると、既存の鍵を削除して新しいホスト鍵対を生成することができます:

> sudo rm /etc/ssh/ssh_host*
> sudo ssh-keygen -A

なお、 ssh-keygen -A では既存の鍵を上書きすることはありませんので、ホスト鍵を完全に入れ替える場合は、事前に削除しておく必要があります。

重要: DSA 鍵の使用禁止について

ssh-keygen -A を実行すると、既に何年も前から安全性に問題があると考えられている DSA 鍵も生成されます。 OpenSSH 7.0 の時点でも未だ作成されますが、 sshd_config 側で使用されないように設定されています。そのため、生成された DSA 鍵は削除して問題ありません。

ホスト鍵の切り替え (詳しくは 22.5項 「ホスト鍵の切り替え」 をお読みください) を検討している場合は、新しいホスト鍵を別のファイル名に保存しなければなりません。単純に新しい鍵に入れ替えるだけの作業では、ユーザ側でホスト鍵の正しさを検証できないためです。ホスト鍵を切り替えるには、サーバ側で古い鍵と新しい鍵の両方を送信するように設定し、古い鍵で新しい鍵を検証できるようにしてください。そのため、古い鍵とは別のファイル名に保存する必要があります。下記の例では、新しい RSA, Ed25519 のホスト鍵を作成して、年月を指定した新しいファイル名に保存しています。もちろん新しいホスト鍵にはパスフレーズを設定してはなりません:

> cd /etc/ssh
> sudo ssh-keygen -b 4096 -f "SSH_HOST_RSA_2022_02"
> sudo ssh-keygen -t ed25519 -f "SSH_HOST_ED25519_2022_02"

なお、新しい鍵に設定するファイル名は任意のものでかまいません。

OpenSSH バージョン 6.8 およびそれ以降のバージョンでは、ホスト鍵を切り替えながら使用することのできるプロトコル拡張が利用できます。 SSH サーバの管理者は、たとえばホスト鍵が漏洩したり、既存の鍵の強度では弱いと判断したりした場合、古いホスト鍵を廃棄して新しいホスト鍵に切り替えなければならなくなります。バージョン 6.8 以前では、ユーザ側のマシンの ssh_config で StrictHostKeyChecking が yes に設定されていると、ホスト鍵の変更が検出されると警告メッセージを表示して接続が行われなくなっていました。この場合、ユーザ側で対応する公開鍵を known_hosts ファイルから手作業で削除して接続し直し、新しい鍵を受け付ける作業が必要になります。 SSH 経由でのスケジュールバックアップなど、自動化を行っている場合には面倒になってしまいます。

新しいホスト鍵の切り替え方式では、サービスの停止を伴うことなく新しい鍵を配布できる方式を提供しています。クライアントからの接続があると、サーバは手持ちの鍵を一覧で送信しますので、次回以降のログインで新しい鍵を自動的に受け付けるようにすることができます。これにより、鍵の移行のための猶予期間を設定することができますので、しばらく待ってから古い鍵を削除すれば、移行が完了することになります。ユーザ側の known_hosts ファイルも自動的に更新されますので、古い鍵から新しい鍵への切り替えも自動でできることになります。

ホスト鍵の切り替え機能を使用するには、新しい鍵の作成のほか、サーバ側では /etc/ssh/sshd_config ファイルの変更を、クライアント側では /etc/ssh/ssh_config ファイルの変更をそれぞれ行う必要があります。

まずは新しい鍵 (複数可) を作成します。下記の例では、ファイル名とコメントを指定して新しい RSA 鍵と Ed25519 鍵を作成しています。一般的には作成日などを含めておくとよいでしょう。また、ホスト鍵にはパスフレーズを設定してはいけません:

# ssh-keygen -t rsa -f ssh_host_rsa_2022-01 -C "main server"
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in ssh_host_rsa_2022-01
Your public key has been saved in ssh_host_rsa_2022-01.pub
The key fingerprint is:
SHA256:F1FIF2aqOz7D3mGdsjzHpH/kjUWZehBN3uG7FM4taAQ main server
The key's randomart image is:
+---[RSA 3072]----+
|         .Eo*.oo |
|          .B .o.o|
|          o . .++|
|         . o ooo=|
|        S . o +*.|
|         o o.oooo|
|       .o ++oo.= |
|       .+=o+o + .|
|       .oo++..   |
+----[SHA256]-----+

# ssh-keygen -t ed25519 -f ssh_host_ed25519_2022-01 -C "main server"
Generating public/private ed25519 key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in ssh_host_ed25519_2022-01
Your public key has been saved in ssh_host_ed25519_2022-01.pub
The key fingerprint is:
SHA256:2p9K0giXv7WsRnLjwjs4hJ8EFcoX1FWR4nQz6fxnjxg main server
The key's randomart image is:
+--[ED25519 256]--+
|   .+o ...o+     |
| . .... o *      |
|  o..  o = o     |
|  ..   .. o      |
|   o. o S  .     |
|  . oo.*+   E o  |
|   + ++==..  = o |
|    = +oo= o. . .|
|     ..=+o=      |
+----[SHA256]-----+

表示されたフィンガープリント (key fingerprint) を、ユーザ側で鍵を検証する際の確認として記録しておいてください。

新しい鍵のファイル名を /etc/ssh/sshd_config で指定します。既存の鍵はコメントアウトせず、そのまま設定しておいてください:

## 古い鍵
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_ecdsa_key

## 新しい鍵
HostKey /etc/ssh/ssh_host_rsa_2022-01
HostKey /etc/ssh/ssh_host_ed25519_2022-01

ファイルを保存したら、 sshd を再起動します:

# systemctl restart sshd.service

なお、ユーザ側の /etc/ssh/ssh_config では、下記のような設定をしている必要があります:

UpdateHostKeys ask
StrictHostKeyChecking yes

クライアント側からサーバに SSH で接続してテストしてみます。既に接続している場合はいったんログアウトして再接続してみてください。下記のようなメッセージが表示されるはずです:

The server has updated its host keys.
These changes were verified by the server's existing trusted key.
Deprecating obsolete hostkey: ED25519
SHA256:V28d3VpHgjsCoV04RBCZpLo5c0kEslCZDVdIUnCvqPI
Deprecating obsolete hostkey:
RSA SHA256:+NR4DVdbsUNsqJPIhISzx+eqD4x/awCCwijZ4a9eP8I
Accept updated hostkeys? (yes/no):yes

UpdateHostKeys ask を UpdateHostKeys yes に変更することで、変更された鍵を自動的に受け付けるように設定することもできます。

さらに詳しい情報を知りたい場合は、下記を参照してください:

公開鍵認証は、アカウントに対して設定されたパスワードではなく、ユーザが作成した個人用の鍵で認証を行う方法です。

下記は、コメント付きで個人用の RSA 鍵を作成する場合の例を示しています。まずは ~/.ssh ディレクトリに移動 (存在していない場合は作成して移動) したあと、新しい鍵対を作成します。この場合、パスフレーズはできる限り複雑なものとし、パスフレーズは安全な場所に記録しておいてください:

> cd ~/.ssh
> ssh-keygen -C "web server1" -f id-web1 -t rsa -b 4096

あとは作成した鍵対のうち、公開鍵を接続先のホストにコピーします。接続先のマシンにユーザアカウントがあれば、 SSH でアクセスして鍵を書き込みます:

> ssh-copy-id -i id-web1 user@web1

あとは作成した鍵でログインを試してみるだけです:

> ssh -i id-web1 user@web1
Enter passphrase for key 'id-web1':
Last login: Sat Jul 11 11:09:53 2022 from 192.168.10.122
Have a lot of fun...

この場合、パスフレーズの入力を求められますが、接続先のマシンのパスワードではなく、鍵のパスフレーズを入力する必要があることに注意してください。

なお、安全性を高めたい場合は、接続先のマシンで公開鍵認証を強制して、パスワード認証を拒否するように設定することをお勧めします (詳しくは 例22.1「sshd_config の例」 ) をお読みください) 。この場合、接続先のマシンに個人用の公開鍵を設定していないと、 ssh-copy-id やその他の方法での公開鍵書き込みもまた実行できなくなることに注意してください。このような場合は、 USB メモリなどに公開鍵を書き込んで、接続先のマシンの ~/.ssh/authorized_keys にコピーする作業を実施しなければなりません。

これは機密鍵に対してパスフレーズを設定せずに公開鍵認証を使用する方式です。パスフレーズを指定せずに新しい鍵を作成したあとは、パスフレーズ付きの鍵と同じ手順で鍵を使用することができます。これは特にスクリプトや cron ジョブなどの自動化されたサービスで便利な方式です。ただし、機密鍵はきちんと保護しておかないと、容易にそのユーザになりすましてログインできてしまうので、注意が必要です。

なお、パスフレーズ無しで鍵を使用するもう 1 つの方法として、 gnome-keyring があります。こちらは機密鍵のパスフレーズを記憶して、必要に応じて適用を行うことができます。 gnome-keyring は GNOME デスクトップセッション向けの仕組みです (詳しくは 22.9項 「gnome-keyring を利用した公開鍵ログインの自動化」 をお読みください) 。

コンソールセッションの場合は ssh-agent を使用することができます (詳しくは 22.10項 「ssh-agent を利用した公開鍵ログインの自動化」 をお読みください) 。

OpenSSH 5.4 およびそれ以降のバージョンでは、証明書による認証を行うことができます。証明書認証は公開鍵認証と似ていますが、ホストとユーザとの間で認証を行うにあたって、単純な暗号鍵ではなくデジタル署名された証明書を使用します。証明書認証はサーバとユーザとの間の認証を集中管理することができますので、いちいち公開鍵を接続先のホストにコピーするような手間も発生しません。また、管理者側での制御もできるようになりますので、より管理者側に権力を集中させることができます。

証明書には公開暗号鍵のほか、ユーザ定義の識別文字列やユーザ名、ホスト名などを必要に応じて含めることができます。ユーザ側とホスト側の公開鍵にはいずれも証明機関 (CA) による署名が付与され、これによって正当性を確認できるようになります。つまり、ユーザ側もホスト側も、 CA の公開鍵を信頼しているだけで認証が成立しますので、わざわざユーザやホストごとに信頼を設定する必要もありません。

また、 OpenSSH の公開鍵認証の場合、ユーザの公開鍵をそれぞれ接続したい SSH サーバにコピーしていく手間がある (通常は ~/.ssh/authorized_keys ファイルに保存されます) ほか、ユーザ側でもホスト鍵を受け付ける (通常は ~/.ssh/known_hosts ファイルに保存されます) 必要がありました。このような構成では操作ミスを引き起こすことがあるほか、管理上も面倒な存在でした。また、このような公開鍵認証では鍵の有効期限が設定できませんので、新しい鍵に入れ替えたい場合は、ネットワーク内に存在する鍵を削除していく手間もありました。

大企業では、このような手間を全体的に削減して自動化する仕組み (たとえば Ansible など) が必要でした。たとえば Meta 社 (詳しくは https://engineering.fb.com/2016/09/12/security/scalable-and-secure-access-with-ssh/ (英語) をお読みください) では、この仕組みを完全に自動化して、証明書を失効させて置き換えることができるようになっているほか、証明機関自身も自動化することで、業務の手間とならない仕組みを構成しています。

なお、事前に実施しておかなければならない作業として、ネットワーク内に存在する全てのホストに SSH 接続して設定ファイルを編集し、 sshd を再起動する必要があります。

OpenSSH での証明機関構築は、下記のような手順で行います:

なお、ユーザ側・サーバ側の管理者とも、それぞれの OpenSSH 鍵はきちんと保護してください。ただし、公開鍵は自由に公開してかまいません。電子メールなどの機密の保護できない方式で公開鍵を送信しても、機密鍵が保護されている限り問題はありません。

ただし、 SSH での証明書は SSL/TLS ではなく OpenPGP の標準に従っていることに注意してください。これにより、証明書の形式は X.509 ではなく、 OpenPGP 形式になっています。

22.8.1 新しい証明機関の構築 #Edit source

本章では、新しい証明機関 (CA) を構築する手順を説明しています。なお、証明機関を構築するにあたっては、管理の容易さや効率性を考えておくことをお勧めします。

重要: 証明機関自身の保護について

証明機関を設置するホストに対しては、注意深く構成するようにしてください。これは、証明機関は組織全体に対する認証の中枢となるためです。もしも証明機関に対して不正にアクセスできてしまうと、発行した証明書の安全性が損なわれるため、ネットワーク内のコンピュータに対して自由にアクセスを許す結果になってしまうばかりか、サーバや証明機関自身を騙して証明書を偽造することもできてしまいます。そのため、証明機関を設置するホストはそれ専用のコンピュータとして配置し、証明書の発行に必要なサービスのみを動作させるようにしてください。

また、サーバ向けとその他向けで別々の署名鍵を設定してもかまいません。管理すべき証明書の数が多い場合は、サーバ向けとクライアント向けで別々の証明機関のマシンを構築することもできます。同じマシン内に複数の証明機関を構築する場合は、別々のディレクトリ内でもかまいません。本章の例では、 /ca-ssh-hosts と /ca-ssh-users というディレクトリ内にそれぞれの証明機関を構築しています。また、ホスト名は ca.example.com という名前を使用しています。

なお、セキュリティポリシー上の理由から、ユーザやサーバに対する公開鍵のコピーを保持しておく必要がある場合は、それぞれサブディレクトリを作成して保存するようにしてください。これにより、追跡が容易にできるほか、名前の衝突を防ぐことにも繋がります。

重要: RSA 署名鍵の廃止予定について

2020 年 2 月に公開された OpenSSH 8.2 もしくはそれ以降のバージョンでは、 RSA による署名鍵は廃止予定とされています。 Ed25519 もしくは ECDSA をお使いください。

下記の例では、それぞれホスト鍵に署名するための鍵と、ユーザ鍵に署名するための鍵をそれぞれ作成しています。それぞれには強力なパスフレーズを設定してください:

> sudo ssh-keygen -t ed25519 -f /ca-ssh-hosts/ca-host-sign-key -C "signing key for host certificates"
Generating public/private ed25519 key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in ca-host-sign-key
Your public key has been saved in ca-host-sign-key.pub
The key fingerprint is:
SHA256:STuQ7HgDrPcEa7ybNIW0n6kPbj28X5HN8GgwllBbAt0
 signing key for host certificates
The key's randomart image is:
+--[ED25519 256]--+
|      o+o..      |
|   . . o.=E      |
|    = + B .      |
|   + O + = B     |
|  . O * S = +    |
|   o B + o .     |
|    =o=   .      |
|   o.*+  .       |
|   .=.o+.        |
+----[SHA256]-----+

> sudo ssh-keygen -t ed25519 -f /ca-ssh-users/ca-user-sign-key -C "signing key for user certificates"
Generating public/private ed25519 key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in ca-user-sign-key
Your public key has been saved in ca-user-sign-key.pub
The key fingerprint is:
SHA256:taYj8tTnjkzgfHRvQ6HTj8a37PY6rwv96V1x+GHRjIk signing key for user certificates
The key's randomart image is:
+--[ED25519 256]--+
|                 |
|             . +.|
|          . E o.o|
|         . + . ..|
|      . S * o .+.|
|     o + + = +..+|
|    . = * . O + o|
|     + = = o =oo+|
|      . o.o  oOX=|
+----[SHA256]-----+

鍵を作成したら、署名鍵 (公開鍵であることをよくお確かめください) を SSH サーバの動作する全てのホスト内の /etc/ssh 内にコピーします。あとは全てのホスト内の /etc/ssh/sshd_config ファイルを編集して、署名鍵を指定しておきます:

TrustedUserCAKeys /etc/ssh/ca-user-sign-key.pub

ファイルを保存したら、 sshd を再起動します。

> sudo ssh-keygen -s /ca-ssh-hosts/ca-host-sign-key \
   -n venus,venus.example.com -I "db-server host cert" \
   -h -V +4w /etc/ssh/ssh_host_ed25519_key.pub
Enter passphrase:
Signed host key /etc/ssh/ssh_host_ed25519_key-cert.pub: id
"db-server host cert" serial 0 for venus,venus.example.com
valid from 2022-08-08T14:20:00 to 2022-09-05T15:21:19

> ssh-keygen -Lf /etc/ssh/ssh_host_ed25519_key-cert.pub
 /etc/ssh/ssh_host_ed25519_key-cert.pub:
        Type: ssh-ed25519-cert-v01@openssh.com host certificate
        Public key: ED25519-CERT SHA256:/
         U7C+qABXYyuvueUuhFKzzVINq3d7IULRLwBstvVC+Q
        Signing CA: ED25519 SHA256:
         STuQ7HgDrPcEa7ybNIW0n6kPbj28X5HN8GgwllBbAt0 (using ssh-ed25519)
        Key ID: "db-server host cert"
        Serial: 0
        Valid: from 2022-08-08T14:20:00 to 2022-09-05T15:21:19
        Principals:
                venus
                venus.example.com
        Critical Options: (none)
        Extensions: (none)

HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub

> sudo systemctl restart sshd.service

@cert-authority db,db.example.com ssh-ed25519
 AAAAC3NzaC1lZDI1NTE5AAAAIH1pF6DN4BdsfUKWuyiGt/leCvuZ/fPu
 YxY7+4V68Fz0 signing key for user certificates

> sudo ssh-keygen /ca-ssh-hosts/ca-user-sign-key -I "suzanne's cert" -n suzanne -V +52w user-key.pub
 Signed user key .ssh/ed25519key-cert.pub: id "suzanne's cert" serial 0
 for suzanne valid from 2022-09-14T12:57:00 to 2023-09-13T12:58:21

ssh-ed25519-cert-v01@openssh.com
    AAAAIHNzaC1lZDI1NTE5LWNlcnQtdjAxQG9wZW5zc2guY29tAAAAIK6hyvFAhFI+0hkKehF/
    506fD1VdcW29ykfFJn1CPK9lAAAAIAawaXbbEFiQOAe5LGclrCHSLWbEeUauK5+CAuhTJyz0
    AAAAAAAAAAAAAAACAAAAE2RiLXNlcnZlciBob3N0IGNlcnQAAAAeAAAABXZlbnVzAAAAEXZl
    bnVzLmV4YW1wbGUuY29tAAAAAGMabhQAAAAAYz9YgQAAAAAAAAAAAAAAAAAAADMAAAALc3No
    LWVkMjU1MTkAAAAgfWkXoM3gF2x9Qpa7KIa3+V4K+5n98+5jFjv7hXrwXPQAAABTAAAAC3Nz
    aC1lZDI1NTE5AAAAQI+mbJsQjt/9bLiURse8DF3yTa6Yk3HpoE2uf9FW/
    KeLsw2wPeDv0d6jv49Wgr5T3xHYPf+VPJQW35ntFiHTlQg= root@db

RevokedKeys /etc/ssh/revoked_keys

GNOME デスクトップ環境をインストールすると、 gnome-keyring パッケージも自動的にインストールされ、有効化されます。 gnome-keyring はシステムのログインに統合され動作する仕組みであるため、ログイン時に自動的に機密記憶領域の保護が解除されます。ログイン時のパスワードを変更しても、 gnome-keyring はそれを自動的に認識して更新処理を行います。

gnome-keyring は ~/.ssh ディレクトリ内にある全ての鍵対 (*.pub の形式の公開鍵があるもの) を自動的に読み込みます。その他のディレクトリ内にあるファイルを読み込みたい場合は、 ssh-add コマンドで読み込みを行ってください。たとえば下記のようになります:

> ssh-add ~/.otherkeys/my_key

読み込まれた全ての鍵を表示するには、下記のコマンドを実行します:

> ssh-add -L

システムを起動して SSH セッションを開くと、機密鍵のパスフレーズの入力を促されます。

gnome-keyring はセッションを終了するまでの間パスフレーズを記憶します。そのため、システムを再起動しない限り、パスフレーズを再度入力する必要がなくなります。

openssh パッケージには ssh-agent というユーティリティが付属しています。このユーティリティは、セッションが終了するまでの間だけ機密鍵とパスフレーズを記憶して、必要なときに自動的にそれを適用することができます。

ssh-agent をログイン時に自動的に起動して鍵を読み込むように設定したい場合は、 ~/.profile ファイル内に下記のような行を記述します:

eval "$(ssh-agent)"
ssh-add

上記の行のうち、最初の行は ssh-agent を起動するコマンドで、次の行は ~/.ssh ディレクトリ内にある全ての鍵を読み込むコマンドです。このように起動を行うことで、公開鍵認証が必要な SSH セッションを開始すると、最初の 1 回だけはパスフレーズの入力を求められます。その後はシステムを再起動するまでパスフレーズを記憶しますので、再入力を行う必要が無くなります。

なお、特定の鍵のみを読み込むように設定したい場合は、下記のように ~/.profile 内で id_rsa や id_ed25519 のファイルを指定してください:

> ssh-add id_rsa id_ed25519

機密鍵に設定したパスフレーズを変更したり、パスフレーズを削除したりしたい場合は、 ssh-keygen コマンドを使用します:

> ssh-keygen -pf ~/.ssh/server1
Enter old passphrase:
Key has comment 'shared videos server1'
Enter new passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved with the new passphrase.

ssh-keygen コマンドを使用することで、公開鍵の指紋を表示することができます。下記の例では、 ED25519 鍵に対して SHA256 形式の指紋を表示しています:

> ssh-keygen -lf ldap-server
256 SHA256:W45lbmj24ZoASbrqW0q9+NhF04muvfKZ+FkRa2cCiqo comment (ED25519)

-v フラグを指定すると、 ASCII アート形式での鍵表示を行うこともできます:

> ssh-keygen -lvf ldap-server
256 SHA256:W45lbmj24ZoASbrqW0q9+NhF04muvfKZ+FkRa2cCiqo comment (ED25519)
+--[ED25519 256]--+
|                 |
|                 |
|    .. .         |
|  .o..+ +        |
| ...o+ BSo+      |
|. ..o.o =X       |
|...o o..* =      |
|o.*.* =+ = .     |
|E*o*+O. o.o      |
+----[SHA256]-----+

SSH では、ネットワーク上離れた場所にある X アプリケーションも簡単に使用することができます。接続先のマシンの /etc/ssh/sshd_config で X11Forwarding Yes を設定しておかなければなりませんが、 ssh コマンドに -X オプションを付けることで、接続先の DISPLAY 変数が自動的に設定され、全ての X 出力が SSH の接続を介してローカルマシンに表示されるようになります。それと同時に接続先で起動された X アプリケーションは、不正に傍受されたりできないようになります。

たとえば下記のように実行することで、リモートのマシンでシンプルなゲームである GNOME Mines を動かすことができます:

> ssh wilber@sun
Password:
Last login: Tue May 10 11:29:06 2022 from 192.168.163.13
Have a lot of fun...

wilber@sun>  gnome-mines

起動したアプリケーションはローカルにインストールされているかのように、ローカル側に表示されるはずです (ただしネットワーク側の遅延があると、その分だけ性能に影響があります) 。アプリケーションの終了も通常と同じで、閉じるボタンを押すだけです。ただし、アプリケーションを閉じても SSH のセッションは終了せず、そのまま動作し続けます。

重要: Wayland では X11 転送機能が使用できない問題について

X11 転送機能を利用するには、接続先で X Window System が動作している必要があります。これは、 X Window System にはネットワーク機能が内蔵されているものの、 Wayland にはそのような機能が内蔵されていないことによるものです。

X Window System で動作しているのか、それとも Wayland で動作しているかを確認するには、下記のように入力して実行します:

> echo $XDG_SESSION_TYPE
x11

Wayland で動作している場合は、下記のような出力になります:

> echo $XDG_SESSION_TYPE
wayland

systemd を利用して判断したい場合は、 loginctl コマンドを使用します:

> loginctl show-session "$XDG_SESSION_ID" -p Type
Type=x11

> loginctl show-session "$XDG_SESSION_ID" -p Type
Type=wayland

-A オプションを追加することで、 ssh-agent 認証の仕組みが接続先のマシンに引き継がれます。このオプションを使用することで、公開鍵を様々なホストに登録して適切な場所に保存しておくだけで、それらのホストにパスワード無しでログインできるようになります (詳しくは 22.6項 「公開鍵認証」 をお読みください) 。

/etc/ssh/sshd_config では、既定で AllowAgentForwarding yes が設定されています。無効化したい場合は No に変更してください。

scp は、指定したファイルをリモートのマシンとの間でコピーするプログラムです。 jupiter 内でのユーザ名と sun 内でのユーザ名が異なる場合は、 ユーザ名@ホスト名 の形式で指定してください。また、ホームディレクトリ以外のディレクトリにファイルをコピーしたい場合は、 sun: ディレクトリ の形式で指定してください。下記の例では、ローカルから接続先に、および接続先からローカルにそれぞれファイルをコピーしています。

> scp ~/MyLetter.tex tux@sun:/tmp 1
> scp tux@sun:/tmp/MyLetter.tex ~ 2

ヒント: -l オプションについて

ssh コマンドでは、 -l オプションを指定することで、接続先のコンピュータ内でのユーザを指定することができます (ユーザ名@ホスト名 と同じ意味になります) 。 scp コマンドの場合、 -l は scp が消費する帯域を制限するためのオプションを意味しています。

正しいパスワードの入力が行われると、 scp はデータ転送を開始します。進捗表示バーと、各ファイルの転送にかかる残り時間が表示されます。 -q オプションを指定すると、それらの出力を省略することができます。

scp はディレクトリ全体を再帰的にコピーする用途でも使用することができます:

> scp -r src/ sun:backup/

上記のコマンドを実行すると、 src ディレクトリ内にある全てのファイルとサブディレクトリを、 sun 内の ~/backup ディレクトリにコピーします。サブディレクトリが存在していない場合は、それらは自動的に作成されます。

-p オプションは、 scp に対してファイルのタイムスタンプを変更しないようにするオプションです。 -C はデータ転送を圧縮するよう指示するオプションです。これにより転送の際のデータ量を減らすことができますが、送信側・受信側両方のホストでプロセッサにかかる負荷が上昇します。

ssh は TCP/IP 接続を転送するような用途でも使用することができます。この機能は SSH トンネリング とも呼ばれ、暗号化された通信を介して TCP の接続を別のマシン内にある特定のポートに転送することができます。

下記のコマンドを実行することで、 ローカルの TCP ポート 25 (SMTP) への接続を行うと、 jupiter への暗号化接続を介して sun の TCP ポート 25 (SMTP) に接続するようになります。これは特に、 SMTP-AUTH や POP-before-SMTP のような機能を持たない SMTP サーバを使用するような場合に有用です。 このようにポート転送を行うことで、電子メールを 「自宅の」 メールサーバに配送するような構成を構築することができます。

# ssh -L 25:sun:25 jupiter

上記と同様に、全ての POP3 接続 (ポート 110) を sun に転送したい場合は、下記のように実行します:

# ssh -L 110:sun:110 jupiter

いずれのコマンドも特権ポートを使用していることから、 root で実行しなければなりません。いったんコマンドを実行すれば、一般ユーザからもそのポートを使用して電子メールを送受信できるようになります。この場合、電子メールソフトウエア側のサーバ設定は localhost を指定します。上記で説明したそれぞれのプログラムのオプションに関する説明は、 /usr/share/doc/packages/openssh 内にある OpenSSH のパッケージドキュメンテーション内にあります。

SSH ブルートフォース攻撃とは、様々なユーザ名とパスワードの組み合わせでログインを試すことにより、ネットワーク経由でサーバへの不正侵入を試みるものです。攻撃者は自動化されたツールを利用して侵入を試みるため、膨大な数のユーザ名とパスワードの組み合わせを試すことができてしまいます。

このような不正侵入を防ぐには、 fail2ban と呼ばれるソフトウエアを使用します。 fail2ban は定期的にシステムログを検索して攻撃を検知し、ファイアウオールで接続元の IP アドレスからのアクセスを禁止するなど、その攻撃内容に応じた処理を実施します。なお fail2ban は、ユーザ名とパスワードを使用するサービスを保護するためだけに使用することができます。