2026 Nov. 03.
2026 Oct. 14.
2026 Oct. 14.
2026 Sep. 13.
2026 Feb. 25.
2025 Feb. 08.
2024 May. 26.2025 Feb. 08.
2024 Jan. 20.
2023 Dec. 30.
2023 Aug. 13.
2023 Jun. 25.
2023 May 05.
2022 Oct. 01.
2022 Feb. 08.
2021 Nov. 23.
2021 May 02.
2021 Apr. 30.
2021 Mar. 25.
2021 Feb. 05.
2021 Jan. 31
2019 Oct. 12.
2018 Sep. 01.
2017 Feb. 12.
2016 Dec. 03.
2017 Feb. 12.
2016 Dec. 03.
パスワード認証は禁止し、パスフレーズ認証にし、十分長いパスフレーズを設定すること。
LAN外からの接続ではなるべくVPN接続しLAN内として接続すること。
鍵ファイルについて
公開鍵
サーバーに置く。クライアントには不要。
サーバーの接続ユーザーの${HOME}/.ssh/authorized_keysファイルの末尾に新たな公開鍵ファイル内容を連結していく。
公開鍵ファイルは、その内容をサーバーの authorized_keys に追記したら削除してよい。
authorized_keysの属性は 644 。
秘密鍵
クライアントの ~/.ssh/ ディレクトリに置く。サーバーには不要。
ファイル属性は必ず 600 にする。known_hostsファイル
ファイル名 CLEINT: ~/.ssh/known_hosts接続したことのあるSSHサーバ証明書が格納されるファイル。
暗号種類
(高強度順に)ed25519(EdDSA) 鍵長はない
ecdsa(鍵長 521bit 384bit 256bit)
rsa (鍵長 4096bit 3072bit 2048bit)最も広く使用されているため、最もよくサポートされている。
DSA 非推奨。OpenSSH 7.0からはデフォルトで無効化。SSH2で使える。 鍵長が1024bit。
RSA1 非推奨。SSH protocol 1で利用できる。
クライアントが利用できる暗号にする。
EdDSA、2048bitもしくは4096bitのRSA利用がよい。
時とともに古い方式となるので、時々見直す。
インストール
( Ubuntu )
$ sudo apt update && sudo apt install ssh
(Arch系のManjaro Linux)
opensshパッケージ
サーバー側設定 /etc/ssh/sshd_config を編集
Port xx # xx : SSHを受け付けるポート番号
# RSAAuthentication no # RSAを利用しない(ed25519を利用するので)不要。
PubkeyAuthentication yes # 公開鍵認証
AuthorizedKeysFile %h/.ssh/authorized_keys # %hはホームディレクトリを表現
次の記述は省略形で、効果は同じ。
AuthorizedKeysFile .ssh/authorized_keys
次の記述(.ssh/authorized_keys2)は不要
AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2
OpenSSHのバージョン3(2001年頃)以降、authorized_keys2 は非推奨(レガシー)となり、すべての公開鍵を通常の authorized_keys にまとめる仕様に変更された。
設定ファイルに記述されているのは、古いバージョンから引き継がれた後方互換性の名残り。
現在では基本的に .ssh/authorized_keys だけがあれば十分機能するため、意識して使用する必要はない。
設定ファイルに記述されているのは、古いバージョンから引き継がれた後方互換性の名残り。
現在では基本的に .ssh/authorized_keys だけがあれば十分機能するため、意識して使用する必要はない。
AllowUsers USER1 USER2 USER3 ## 複数のユーザーはカンマではなく空白で並べる
PermitRootLogin no # "PermitRootLogin prohibit-password"は公開鍵認証を許す設定
PermitEmptyPasswords no
PasswordAuthentication no
ChallengeResponseAuthentication について
サーバー側がクライアントに対して「質問(チャレンジ)」を送り、クライアントがそれに対する正しい「答え(レスポンス)」を返すことで本人確認を行う方式。
サーバー側からの動的な問いかけに対して応答する仕組み、あるいはキーボードから対話形式で入力を受け付ける仕組み(Keyboard-Interactive認証)。
パスワード認証の「抜け穴」になりやすい。
セキュリティ対策として PasswordAuthentication no(パスワード認証無効)に設定しても、ChallengeResponseAuthentication yes が有効なままだと、PAM経由のパスワード入力プロンプトが機能してしまい、結果的にパスワードでのログインができてしまうケースがある。そのため、完全なパスワードレス(公開鍵認証のみ)運用を目指す場合は、この項目も no に設定することが推奨される。
サーバー側がクライアントに対して「質問(チャレンジ)」を送り、クライアントがそれに対する正しい「答え(レスポンス)」を返すことで本人確認を行う方式。
サーバー側からの動的な問いかけに対して応答する仕組み、あるいはキーボードから対話形式で入力を受け付ける仕組み(Keyboard-Interactive認証)。
パスワード認証の「抜け穴」になりやすい。
セキュリティ対策として PasswordAuthentication no(パスワード認証無効)に設定しても、ChallengeResponseAuthentication yes が有効なままだと、PAM経由のパスワード入力プロンプトが機能してしまい、結果的にパスワードでのログインができてしまうケースがある。そのため、完全なパスワードレス(公開鍵認証のみ)運用を目指す場合は、この項目も no に設定することが推奨される。
KbdInteractiveAuthentication no
/etc/ssh/sshd_configのチェック
$ sudo systemctl status ssh.service
sshが稼働していなければ "$ sudo systemctl start .service"を実行する。
ssh.serviceの稼働を確認の上、次のコマンドを実行する。
$ sudo /usr/sbin/sshd -t
正常であれば何も表示されない。
(サーバ設定に関する参考ページ)
OpenSSH の ChallengeResponseAuthentication と PasswordAuthentication | CentOS | daily memorandum 3.0.0
SSHサーバーにTCP wrapper機構は使われなくなっているので、/etc/hosts.allow の編集は不要。
サーバー側ファイアウォール設定
$ sudo ufw enable
$ sudo ufw allow from any to any port 22 proto tcp # port 22は安全なものに変更すること
$ sudo ufw reload
$ sudo ufw allow from any to any port 22 proto tcp # port 22は安全なものに変更すること
$ sudo ufw reload
デーモン起動設定
$ sudo systemctl enable ssh.service
$ systemctl status ssh.service
(sshdが動いていなかったら)
$ sudo systemctl start ssh.service
鍵ファイル作成
サーバー上で、ログインを許す一般ユーザーで鍵を生成するので、rootユーザーになっていたら、一般ユーザーに切り替える。
$ mkdir ~/.ssh
$ chmod 700 ~/.ssh
$ ssh-keygen -t 暗号方式 -b bit長 -f 鍵ファイルパス [ -C "コメント" ] [ -N "パスフレーズ" ]
-N:付けなければインタラクティブに尋ねられるので、付けなくてよい。
-f:鍵のファイルパス。公開鍵と秘密鍵の2つを同時に作成するので拡張子を付けない。普通は ~/.ssh/ID-FILENAME
(例) -N オプションを付ける場合
$ ssh-keygen -t ed25519 -N "PASSPHRASE" -f ~/.ssh/SRV_HOST-CLI_HOST-USER-ed25519
$ ssh-keygen -t ecdsa -b 521 -N "PASSPHRASE" -f ~/.ssh/SRV_HOST-CLI_HOST-USER-ecdsa521
$ ssh-keygen -t rsa -b 4096 -N "PASSPHRASE" -f ~/.ssh/SRV_HOST-CLI_HOST-USER-rsa4096
$ ssh-keygen -t ed25519 -N "PASSPHRASE" -f ~/.ssh/SRV_HOST-CLI_HOST-USER-ed25519
$ ssh-keygen -t ecdsa -b 521 -N "PASSPHRASE" -f ~/.ssh/SRV_HOST-CLI_HOST-USER-ecdsa521
$ ssh-keygen -t rsa -b 4096 -N "PASSPHRASE" -f ~/.ssh/SRV_HOST-CLI_HOST-USER-rsa4096
公開鍵配置
サーバーの接続ユーザーの ~/.ssh/ ディレクトリに公開鍵を配置する。
公開鍵は
~/.ssh/authorized_keys と連結(追記)する必要がある。公開鍵がauthorized_keysに連結されていれば .pubファイルは削除してよい。authorized_keysの属性は644にしておく。$ cat ~/.ssh/SRV_HOST-CLI_HOST-USER-ed25519.pub >> ~/.ssh/authorized_keys
$ chmod 644 authorized_keys
$ chmod 700 ~/.ssh$ chmod 600 SRV_HOST-CLI_HOST-USER-ed25519
WindowsのSSHサーバーでも、公開鍵はauthorized_keysにする。
秘密鍵配置
Linuxのsshクライアントの場合
秘密鍵をsshクライアントの ${HOME}/.ssh/ ディレクトリに置く。
秘密鍵をsshクライアントの ${HOME}/.ssh/ ディレクトリに置く。
${HOME}/.sshの属性は 700 にする。
秘密鍵のファイル属性は600にする。
クライアントからサーバーへの接続
$ ssh -p PORT -i 秘密鍵ファイル USER@SERVER-IP-ADDRESS
複数の公開鍵が格納された、サーバー内の ~/.ssh/authorized_keys の中から特定の秘密鍵に対応する公開鍵を見つける方法
クライアントPCで ssh-keygen -lf ~/.ssh/YOURPRIVATEKEY を実行する。
サーバーで ssh-keygen -lf ~/.ssh/authorized_keys を実行する。
SHA256: 以降の文字列が一致する鍵を探す。
クライアント側での接続コマンド簡略化設定
~/.ssh/config ファイルに接続情報を記述する。
Host 接続名(任意)
HostName ホスト名
Port ポート番号
HostName ホスト名
IdentityFile 秘密鍵のパス
User ユーザー名Port ポート番号
(サンプル)
Host github.com
HostName github.com
IdentityFile ~/.ssh/srv_github-cli_pc12xubuntu2004_taro-ed25519
User git
Host bitbucket.org
HostName bitbucket.org
IdentityFile ~/.ssh/srv_bitbucket-cli_pc12xubuntu2004_taro-ed25519
User git
Port 22
TCPKeepAlive yes
IdentitiesOnly yes
~/.ssh/config作成時の接続コマンド
$ ssh Host行の接続名
Windowsクライアントでのパスフレーズ省略・秘密鍵不可視化設定
(1) [サービス]アプリを起動し、ssh-agent(Open SSH Authentication Agent)を自動実行登録し、その行を右クリックして"実行開始"する。
(2) 一般ユーザーコマンドプロンプトで鍵追加コマンド"ssh-add FullPathOfSecretKey"を入力する。
(3) 設定状況確認:> ssh-add -l
(4) ssh接続コマンド
ssh -p PORT USER@HOSTNAME
(5) 秘密鍵を削除する。
%userprofile%\.ssh フォルダーに 次の書式で config ファイルを作成する。
host ACCESSNAME
user USER
user USER
hostname SERVER.IP.ADDRESS
port SERVERPORT
簡略化されたSSH接続コマンドの入力
> ssh ACCESSNAME
%userprofile%\.ssh フォルダーに秘密鍵を置くなら、保管フォルダーの属性を他人からアクセスできないようにしておく。
失くした公開鍵復元
$ ssh-keygen -yf 秘密鍵名
$ ssh-keygen -yf 秘密鍵名