Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
コンテンツコンテンツ
セキュリティ強化ガイド
  1. 前書き
  2. 1 セキュリティと機密保持
  3. I 認証
    1. 2 PAM を利用した認証
    2. 3 NIS の使用
    3. 4 YaST を利用した認証クライアントの設定
    4. 5 389 Directory Server を利用した LDAP サービス
    5. 6 Kerberos を利用したネットワーク認証
    6. 7 Active Directory サポート
    7. 8 FreeRADIUS サーバの構築
  4. II ローカルセキュリティ
    1. 9 物理的なセキュリティ
    2. 10 ソフトウエア管理
    3. 11 ファイルの管理
    4. 12 パーティションやファイルの暗号化
    5. 13 cryptctl を利用したアプリケーション向けのストレージ暗号化
    6. 14 ユーザ管理
    7. 15 cronat の制限
    8. 16 Spectre/Meltdown チェッカー
    9. 17 YaST を利用したセキュリティの設定
    10. 18 Polkit 認可フレームワーク
    11. 19 Linux でのアクセス制御リスト
    12. 20 AIDE を利用した侵入検知
  5. III ネットワークセキュリティ
    1. 21 X Window System と X 認証
    2. 22 OpenSSH によるネットワーク操作の機密保持
    3. 23 マスカレードとファイアウオール
    4. 24 VPN サーバの設定
    5. 25 X Window System で動作する PKI マネージャ XCA による管理
    6. 26 sysctl 変数によるネットワークセキュリティの改善
  6. IV AppArmor による権限の制限
    1. 27 AppArmor の紹介
    2. 28 入門
    3. 29 プログラムに対する予防接種
    4. 30 プロファイルのコンポーネントと文法
    5. 31 AppArmor のプロファイルリポジトリ
    6. 32 YaST を利用したプロファイルの構築と管理
    7. 33 コマンドラインからのプロファイル構築
    8. 34 チェンジハット機能による Web アプリケーションのプロファイル作成
    9. 35 pam_apparmor によるユーザの制限
    10. 36 プロファイルを作成したアプリケーションの管理
    11. 37 サポート
    12. 38 AppArmor 用語集
  7. V SELinux
    1. 39 SELinux の設定
  8. VI Linux 監査フレームワーク
    1. 40 Linux 監査システムの概要
    2. 41 Linux 監査フレームワークの設定
    3. 42 監査ルールセットの紹介
    4. 43 その他の情報源
  9. A GNU ライセンス
ナビゲーション
適用先 openSUSE Leap 15.6

22 OpenSSH によるネットワーク操作の機密保持 Edit source

概要

OpenSSH は openSUSE Leap に同梱される SSH (secure shell) 実装で、遠隔からの管理やファイル転送、機密を保持できないプロトコルへの機密トンネル設定など、さまざまな機能を提供するソフトウエアです。 SSH は 2 つのホスト間での認証を含む全通信を暗号化しますので、盗聴や接続の乗っ取りなどの被害から通信を保護することができます。本章では基本的な操作のほか、ホスト鍵の切り替えや証明書認証など、大規模展開向けに便利な機能を説明しています。

22.1 OpenSSH の概要 Edit source

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 では下記のような認証方式に対応しています:

パスワード認証

ユーザ名とパスワードで認証する方式です。この方式は、 SSH のセッションをどのマシンからでも受け付けることができますので、最も単純で柔軟な認証方式です。ただし、パスワードクラッキングには弱く、キーロガーなどによる窃取にも弱いため、機密性は低くなります。

公開鍵認証

ユーザ名とパスワードではなく、個人単位で鍵を設定して認証を行う方式です。公開鍵に対応する機密鍵を持つホストからしかログインできない仕組みであるため、パスワード認証に比べると柔軟性が落ちますが、パスワードクラッキングに強く、キーロガーなどによる窃取も回避できますので、パスワード認証よりはずっと強力です。

GNOME セッション内で公開鍵認証を自動化したい場合は、 gnome-keyring を使用することができます。詳しくは 22.9項 「gnome-keyring を利用した公開鍵ログインの自動化」 をお読みください。

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

パスフレーズ無しの公開鍵認証

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

証明書認証

OpenSSH では証明書認証にも対応しています。これにより、鍵の管理の手間を省くことができるほか、より強力な認証手段となり、かつ大規模な SSH 展開にも対応できるようになります。

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

ssh

遠隔のホストに対して SSH 接続を開始するためのクライアント側コマンドです。

scp

遠隔のホストとの間でファイルをやり取りするためのコマンドです。

sftp

クライアントと SFTP サーバとの間でファイルを送受信するためのコマンドです (なお、 SFTP (SSH FTP) プロトコルは FTPS や FTPES (FTP over SSL/TLS) と呼ばれるプロトコルとは異なり、独自に作成されているものです) 。

ssh-add

ssh-agent コマンドで動作する認証エージェントに対して、機密鍵の情報を追加するためのコマンドです。

ssh-agent

公開鍵認証で使用する、ユーザの機密鍵とパスフレーズを管理するためのエージェントです。 ssh-agent はパスフレーズをメモリ内に保持し、必要に応じてパスフレーズを提供しますので、パスフレーズの再入力を省略することができるようになります。

ssh-copy-id

公開鍵認証を設定して、公開鍵を遠隔のホストにコピーするコマンドです。

22.2 サーバのセキュリティ強化 Edit source

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-passwordPasswordAuthentication のオプションを利用して、公開鍵認証のみを受け付けるように設定してください。

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

例 22.1: 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 でなければいけません。

22.3 パスワード認証 Edit source

パスワード認証を行う場合は、接続先のマシン内にユーザアカウントとパスワードを設定し、 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 でのパスワード入力が求められます。

22.4 ユーザ鍵とホスト鍵の管理 Edit source

生成できる鍵の種類としては、 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.1 ユーザ SSH 鍵の生成 Edit source

下記に示す手順では、 OpenSSH でのユーザ鍵の作成方法を説明しています。

手順 22.1: 既定の鍵と独自の鍵について
  1. 既定のパラメータ (RSA, 3072 ビット) でユーザ鍵対を生成するには、オプションを何も指定せず ssh-keygen と入力して実行します。なお、機密鍵を保護するため、強力なパスフレーズを設定しておいてください:

    > ssh-keygen
    Generating public/private rsa key pair.
    Enter file in which to save the key (/home/tux/.ssh/id_rsa):
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Your identification has been saved in id_rsa
    Your public key has been saved in id_rsa.pub
    The key fingerprint is:
    SHA256:z0uJIuc7Doy07bFTe1ppZHLVrkD/bWWlBAF/PcHjblU user@host2
    The key's randomart image is:
    +---[RSA 3072]----+
    |          ..o... |
    |           o . +E|
    |        . . o +.=|
    |       . o . o o+|
    |  .   . S . . o +|
    | . =  .= * + . = |
    |  o *.o.= * . +  |
    |   ..Bo+.. . .   |
    |    oo==  .      |
    +----[SHA256]-----+
  2. より長いビット長で RSA 鍵対を作成したい場合は、下記のように入力して実行します:

    > ssh-keygen -b 4096

    OpenSSH での RSA 鍵は、最大で 16,384 ビットまでとなっています。しかしながら、ビット長を大きくしても、かかる負荷に見合うだけの効果を得られません。詳しくは GnuPG の FAQ https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096 (英語) をお読みください。

  3. ユーザ鍵は必要な数だけ作成することができます。これらを異なるサーバへの接続に使用することができます。鍵対には重複しない名前を指定しなければならないほか、必要であればコメントを含めることもできます。これらは鍵の用途を記しておくのに最適です。たとえば下記のようにして名前とコメントを指定して作成します:

    > ssh-keygen -f backup-server-key -C "infrastructure backup server"
  4. 独自のファイル名やコメントを指定して Ed25519 鍵対を作成する場合は、下記のようにします:

    > ssh-keygen -t ed25519 -f ldap-server-key -C "Internal LDAP server"

    Ed25519 の鍵は 256 ビットの固定長です。暗号強度は RSA 4096 ビットと同程度になります。

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"

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

22.5 ホスト鍵の切り替え Edit source

OpenSSH バージョン 6.8 およびそれ以降のバージョンでは、ホスト鍵を切り替えながら使用することのできるプロトコル拡張が利用できます。 SSH サーバの管理者は、たとえばホスト鍵が漏洩したり、既存の鍵の強度では弱いと判断したりした場合、古いホスト鍵を廃棄して新しいホスト鍵に切り替えなければならなくなります。バージョン 6.8 以前では、ユーザ側のマシンの ssh_configStrictHostKeyCheckingyes に設定されていると、ホスト鍵の変更が検出されると警告メッセージを表示して接続が行われなくなっていました。この場合、ユーザ側で対応する公開鍵を 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 askUpdateHostKeys yes に変更することで、変更された鍵を自動的に受け付けるように設定することもできます。

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

22.6 公開鍵認証 Edit source

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

下記は、コメント付きで個人用の 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 にコピーする作業を実施しなければなりません。

22.7 パスフレーズ無しの公開鍵認証 Edit source

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

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

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

22.8 OpenSSH での証明書認証 Edit source

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 での証明機関構築は、下記のような手順で行います:

  • 機密の保持できる信頼できるサーバを構築して、そこに証明機関を配置します。まずは証明機関自身の鍵対を作成して、この機密鍵でユーザ鍵やホスト鍵への署名を行うとともに、公開鍵はサーバへのアクセスを許可する全てのユーザに配布します。

  • 次にホスト側の公開鍵を集めて、証明機関で署名を実施したあと、作成された証明書をそれぞれのホストに返します。発行されたホストの証明書は、ホスト鍵と同様に /etc/ssh 内に配置します。

  • 次にユーザ側の公開鍵を集めて、証明機関で署名を実施したあと、作成された証明書を各ユーザに返します。ユーザ側の証明書は、ユーザ鍵と同様に ~/.ssh 内に配置します。

  • サーバ側、ユーザ側の各マシンで設定ファイルを編集して、必要であれば sshd を再起動します。

  • なお、発行した証明書は、機密鍵が漏洩したり、ユーザが組織を脱退したり、サーバを退役させたりした場合に失効処理を実施します。証明書の失効処理は、ネットワーク内に配布した公開鍵を削除して回るよりは比較的簡単です。

なお、ユーザ側・サーバ側の管理者とも、それぞれの 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 を再起動します。

22.8.2 サーバ証明書の作成 Edit source

下記の例では、データベースサーバ (db-server) のホスト公開鍵に対して、署名を付与しています:

> 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

サーバ内に複数の鍵が存在する場合は、全ての鍵に対して署名を実施してください。

  • -s では機密鍵を指定しています。

  • -n ではプリンシパル名を指定しています。ホスト鍵の場合、ここには完全修飾ドメイン名によるマシンのホスト名を指定します。

  • -I では識別用の文字列を指定しています。ここはコメント欄ですので、わかりやすい説明を記述してください。また、この文字列はログにも記録されますので、ログ内を検索したい場合にも有用です。

  • -h ではホスト鍵の証明書であることを指定しています。

  • -V では証明書の有効期限を指定しています。この例では、証明書は 4 週間後になっています (指定可能な期間については、 man 1 ssh-keygen 内の "-V validity_interval" の章 (英語) をお読みください) 。

あとは発行された証明書が正しいことを確認します:

> 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)

あとは発行された証明書のフルパスを /etc/ssh/sshd_config で指定して、クライアント側に送信するようにします:

HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub

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

> sudo systemctl restart sshd.service

ホストの証明書をクライアント側で受け付ける方法については、 22.8.3項 「ユーザ向けの CA 設定」 をお読みください。

22.8.3 ユーザ向けの CA 設定 Edit source

下記の例では、クライアント側で個別の鍵ではなく証明機関で署名された鍵を受け付ける設定を示しています。下記の例では単一のサーバに対してのみアクセスを許可しています。また、下記の設定は ~/.ssh/known_hosts 内で改行せず 1 行で記述する必要があることに注意してください。また、既に ~/.ssh/known_hosts ファイルが存在する場合は、ファイル名を変更して残しておき、下記の証明機関設定のみを含むようにしてください。なお、 /etc/ssh/ssh_known_hosts ファイルに証明機関を設定する方法もありますが、こちらを編集するには管理者権限が必要となります:

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

サーバを複数指定する場合は、カンマ区切りで指定してください。たとえば venus,venus.example.com,saturn,saturn.example.com のようになります。ワイルドカードを利用して *.example.com,*.example2.com のように指定し、ドメイン内の全てのサーバに対してアクセスを許可することもできます。

あとは実際にサーバに接続してみてください。ホスト鍵の受け付けを促すプロンプトが表示されず、そのままパスワード入力を求められれば成功です。

22.8.4 ユーザ証明書の作成 Edit source

下記のようにしてユーザの公開鍵に署名を付与します:

> 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 内に保存してください。

ユーザの証明書を発行すれば、サーバ側の ~/.ssh/authorized_keys ファイルは不要になります。サーバ側のこのファイルを削除したあと、 SSH で接続しなおしてみてください。パスワード入力を求められることなくログインできるようになるはずです (なお、サーバ側の /etc/ssh/sshd_config ファイルで、 TrustedUserCAKeys /etc/ssh/ca-user-sign-key.pub を設定していることをご確認ください。この設定で、信頼すべき証明機関を設定しています) 。

また、サーバ内のログファイルに Accepted publickey for suzanne が記録されていることも確認しておくとよいでしょう。

22.8.5 ホスト鍵の失効処理 Edit source

サーバが不正侵入を受けたり退役したりした場合は、証明書の失効処理を実施してホスト鍵の利用を停止する必要があります。このような場合は、各クライアント側の /etc/ssh/revoked_keys ファイルなどに対応する公開鍵を指定します:

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

上記で作成したファイルは、 /etc/ssh/sshd_config 内で下記のようにして指定します:

RevokedKeys /etc/ssh/revoked_keys

22.9 gnome-keyring を利用した公開鍵ログインの自動化 Edit source

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

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

> ssh-add ~/.otherkeys/my_key

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

> ssh-add -L

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

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

22.10 ssh-agent を利用した公開鍵ログインの自動化 Edit source

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

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

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

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

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

> ssh-add id_rsa id_ed25519

22.10.1 ssh-agent の X セッション内での利用 Edit source

openSUSE Leap では、 GNOME ディスプレイマネージャを起動すると ssh-agent が自動的に開始されます。 X セッションの開始時に ssh-add で鍵を自動的に読み込むようにしたい場合は、下記のように実施します:

  1. まずは対象のユーザでログインし、 ~/.xinitrc ファイルが存在しているかどうかを確認します。

  2. ファイルが存在していない場合、既存のテンプレートを使用するか、 /etc/skel 内にあるファイルをそのままコピーします:

    if [ -f ~/.xinitrc.template ]; then mv ~/.xinitrc.template ~/.xinitrc; \
    else cp /etc/skel/.xinitrc.template ~/.xinitrc; fi
  3. テンプレートをコピーした場合は、下記のような行を探してコメント文字を削除します。 ~/.xinitrc ファイルが既に存在していた場合は、下記の内容を追記します (コメント文字は削除してください)。

    # if test -S "$SSH_AUTH_SOCK" -a -x "$SSH_ASKPASS"; then
    #       ssh-add < /dev/null
    # fi
  4. あとは新しく X セッションを開始すると、 SSH のパスフレーズ入力を求められるようになります。

22.11 SSH 機密鍵のパスフレーズ変更 Edit source

機密鍵に設定したパスフレーズを変更したり、パスフレーズを削除したりしたい場合は、 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.

22.12 鍵の指紋 (fingerprint) の取得 Edit source

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]-----+

22.13 ネットワーク上の離れたホストでの X11 アプリケーションの起動 Edit source

SSH では、ネットワーク上離れた場所にある X アプリケーションも簡単に使用することができます。接続先のマシンの /etc/ssh/sshd_configX11Forwarding 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

22.14 エージェント転送 Edit source

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

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

22.15 scp - 機密を確保したファイルのコピー Edit source

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

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

1

ローカルから接続先に

2

接続先からローカルに

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

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

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

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

> scp -r src/ sun:backup/

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

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

22.16 sftp - 機密を保持したファイルの転送 Edit source

22.16.1 sftp の使用 Edit source

複数のファイルをコピーしたい場合や、異なる場所からコピーを行いたい場合は、 scp の代わりに sftp を利用したほうが便利になることがあります。このコマンドは、通常の FTP プロトコルと同様に、様々なコマンドを実行できるシェルを開くことができます。利用可能なコマンドの一覧を取得したい場合は、 sftp のプロンプトで help と入力してください。より詳しい詳細は、 sftp のマニュアルページに書かれています。

> sftp sun
Enter passphrase for key '/home/tux/.ssh/id_rsa':
Connected to sun.
sftp> help
Available commands:
bye                                Quit sftp
cd path                            Change remote directory to 'path'
[...]

22.16.2 ファイルアップロードのパーミッション設定 Edit source

通常の FTP サーバと同様に、ユーザは SFTP を利用することで、ダウンロードやアップロードを行うことができます。コマンドも通常の FTP サーバと同じで、 たとえばアップロードであれば put コマンドを利用します。既定では、アップロードしたファイルのパーミッションは、ローカル側のパーミッションと同じに設定されます。ただし、自動的に設定されるパーミッションを変更したい場合は、下記のいずれかを実施してください:

umask の設定

umask はパーミッションに対するフィルタとして動作する仕組みで、元々のファイルとアップロード先のファイルとの間で、引き継いで欲しくないビットを 1 にします。なお、アクセス許可を追加することはできません。取り消すことのみ実現できます:

元々のパーミッション

umask の値

アップロードされたファイルのパーミッション

0666

0002

0664

0600

0002

0600

0775

0025

0750

SFTP サーバ側で umask を適用するには、 /etc/ssh/sshd_configuration ファイルを編集します。まずは Subsystem sftp で始まる行を探し、行の末尾に -u オプションを追加して、必要な値を指定してください。たとえば下記のようになります:

Subsystem sftp /usr/lib/ssh/sftp-server -u 0002
明示的なパーミッションの指定

SFTP 経由でアップロードされた全てのファイルに対して、同じパーミッションを設定するように指定する方法です。 -u オプションと同様に、 600 , 644 , 755 のような 3 桁のパーミッション値を指定してください。 -m-u の両方が指定された場合、 -u は無視されます。

SFTP サーバ側で明示的にパーミッションを指定するには、 /etc/ssh/sshd_config ファイルを編集します。まずは Subsystem sftp で始まる行を探し、行の末尾に -m オプションを追加して、必要な値を指定してください。たとえば下記のようになります:

Subsystem sftp /usr/lib/ssh/sftp-server -m 600
ヒント
ヒント: SSH デーモンのログファイル表示

sshd が出力したログを表示したい場合は、下記のコマンドを実行します:

> sudo journalctl -u sshd

22.17 ポート転送 (SSH トンネリング) Edit source

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 のパッケージドキュメンテーション内にあります。

22.18 さらなる情報 Edit source

https://www.openssh.com

OpenSSH の Web ページ

https://en.wikibooks.org/wiki/OpenSSH

OpenSSH Wikibook (英語)

man sshd

OpenSSH デーモンのマニュアルページ

man ssh_config

OpenSSH のクライアント側設定ファイルのマニュアルページ

man scp, man sftp, man ssh, man ssh-add, man ssh-copy-id, man ssh-keygen

ファイルコピー ( scp , sftp ) やログイン ( slogin , ssh ) 、鍵管理などのコマンドに対するマニュアルページ。

/usr/share/doc/packages/openssh-common/README.SUSE

SUSE 固有のパッケージドキュメンテーション; 提供元からの既定値の変更点などを説明しています。

22.19 fail2ban による SSH ブルートフォース攻撃の抑止 Edit source

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

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

22.19.1 fail2ban とは? Edit source

fail2ban は /var/log/apache/error_log 等のログファイルを定期的に検索し、繰り返し何度もログインを試しているような不正アクセスの端緒を検出し、 IP アドレス単位でのアクセス禁止を設定することができます。 fail2ban ではファイアウオールルールを設定して、一定時間のアクセス禁止を実現しています。

fail2ban は Apache, SSH, Courier など、様々なサービスに対応するフィルタが提供されています。 fail2ban を利用することで、不正アクセスを未然に減らすことができるようになります。

22.19.2 SSH ブルートフォース攻撃を抑止するための fail2ban の使用 Edit source

fail2ban をインストールして設定しておくことで、 SSH ブルートフォース攻撃からサーバを保護することができます。

手順 22.2: SSH ブルートフォース攻撃を抑止するための fail2ban の使用
  1. fail2ban をインストールするには、下記のようなコマンドを入力して実行します:

    # sudo zypper -n in fail2ban firewalld
  2. fail2ban をインストールすると、既定の設定ファイルである jail.conf がインストールされますが、このファイルは fail2ban パッケージの更新で上書きされてしまう仕組みであることから、このファイルに直接設定を記述してはなりません。その代わりに、 jail.local というファイルを作成して設定してください。 fail2ban では両方のファイルを読み込むようになっています。

    # cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
  3. まずはエディタでファイルを開きます。

    vi /etc/fail2ban/jail.local
  4. 設定項目のうち、知っておかなければならない項目は 4 種類になります。

    fail2ban の設定
    図 22.1: jail.local ファイルの設定
    ignoreip

    アクセスを禁止したくない IP アドレスの一覧を指定します。既定では IPv4 アドレスの 127.0.0.1 と IPv6 アドレスの ::1 (いずれも自分自身を表すアドレスです) が設定されています。それ以外にもアクセスを禁止したくないアドレスがある場合は、ここに追加してください。

    bantime

    特定の IP アドレスからのアクセスを禁止する際、その禁止期間を指定します。設定値が m (分) または h (時間) で終わっていない場合、禁止期間は秒単位であるものとして解釈されます。また、 -1 を設定すると、恒久的にアクセスを禁止することになります。

    findtime

    特定の IP アドレスからのアクセスを禁止するにあたっての持続時間を指定します。

    maxretry

    試行失敗の上限回数を指定します。

    注記
    注記

    同じ IP アドレスからのアクセスが findtime で指定した時間内に maxretry で指定した回数以上実施された場合、 bantime で指定した時間だけアクセスを禁止することになります。なお、 ignoreip に含まれる IP アドレスについては除外されます。

    fail2ban では様々な種類の jail に対応しています。 jail とは設定の単位で、それぞれが様々な種類の接続に対応しています。

  5. fail2ban サービスを有効化や起動は、下記のようにして行います:

    サービスを有効化するには:

    #  systemctl enable fail2ban

    起動するには:

    #  systemctl start fail2ban

    サービスの状態を確認するには:

    #  systemctl status fail2ban.service
    重要
    重要

    なお、設定を変更した場合は fail2ban の再起動を実施しなければならないことに注意してください。

このページを印刷