SSH・SFTP・公開鍵認証は一緒に使われることが多いものの、同じ機能ではありません。SSHは暗号化された接続の基盤、SFTPはその接続上でファイルを扱う仕組み、公開鍵認証は接続する利用者を確かめる方法です。
安全性は、公開鍵認証を選んだだけでは決まりません。最初に接続先のホスト鍵を確認し、秘密鍵を利用者の端末から外へ出さないことが重要です。担当者ごとに別の鍵を登録すれば、退職や端末紛失のときに該当する鍵だけを無効にできます。
SSH・SFTP・公開鍵認証は役割が違う
SSHの標準仕様では、SSHを安全でないネットワーク上でリモートログインや各種サービスを安全に利用するためのプロトコル群としています。コマンドを操作するシェル接続だけでなく、ファイル転送やほかの通信を保護する基盤にもなります。
| 用語 | 主な役割 | 確認すること |
|---|---|---|
| SSH | 通信の暗号化とサーバーへの安全な接続 | シェル操作が許可されるか、接続先とポートは何か |
| SFTP | SSH通信上でのファイル転送と操作 | 接続可能なディレクトリと書き込み範囲 |
| 公開鍵認証 | 鍵ペアを使った利用者認証 | 誰のどの端末の公開鍵が登録されているか |
SFTPは、FTP通信をTLSで暗号化するFTPSとは別の方式です。接続ソフトでSFTPを選んだ場合は、通常SSH用の接続先と認証方法を使います。名前だけを見てFTP用の設定を流用しないようにします。
レンタルサーバーでは、SFTPだけを許可し、SSHのシェル操作を制限することがあります。反対に、契約プランやアカウントによってSSHを利用できない場合もあります。管理画面と公式マニュアルで、利用可能な機能を先に確認します。
接続先のホスト鍵と利用者の鍵を分けて考える
SSH接続では、最初にサーバーがホスト鍵を提示します。これは利用者が「意図したサーバーへ接続しているか」を確認するための情報です。クライアントに表示されたフィンガープリントを、サーバー会社の管理画面や公式案内など別の経路で照合します。
利用者の公開鍵認証は反対方向です。利用者が秘密鍵で署名し、サーバーは登録された公開鍵で検証します。RFC 4252で定義されるpublickey方式でも、秘密鍵そのものをサーバーへ送る必要はありません。
ホスト鍵が突然変わったという警告は、サーバー移転や再構築でも表示されます。しかし、接続先の取り違えや中間者攻撃の可能性もあります。警告を消すために古い記録を削除する前に、変更理由と新しいフィンガープリントを確認します。
公開鍵は登録し、秘密鍵は端末から出さない
鍵ペアを作ると、公開鍵と秘密鍵の二つができます。公開鍵は接続先サーバーへ登録してよい情報です。秘密鍵は本人であることを証明する側に使うため、制作会社・サーバー会社・社内の共有フォルダーへ送らず、利用者の管理された端末に保管します。
秘密鍵にはパスフレーズを設定します。端末から鍵ファイルだけが流出した場合に、直ちに利用される危険を下げられます。パスフレーズを秘密鍵と同じテキストファイルへ保存せず、会社が認めるパスワード管理ツールを使います。
鍵は担当者または端末ごとに分けます。「制作会社用」の秘密鍵を複数人でコピーすると、誰の利用か追えません。一人が退職したときに全員分の鍵を作り直すことにもなります。公開鍵のコメントや権限台帳に利用者と端末を記録します。
初回接続は現在の入口を残したまま試す
新しい公開鍵を登録するときは、現在ログインできている管理画面や接続をすぐ閉じません。登録に誤りがあると、新しい鍵で入れず、修正する入口まで失う可能性があります。予備の管理者またはサーバー会社の復旧方法も確認します。
初回設定は次の順番で進めます。
- サーバーがSSHまたはSFTPへ対応するかを公式案内で確認する
- 利用者の端末で鍵ペアを作り、秘密鍵にパスフレーズを設定する
- 公開鍵だけを対象アカウントへ登録する
- ホスト鍵のフィンガープリントを別経路の情報と照合する
- 新しい接続で対象ディレクトリと操作範囲を確認する
- 成功後に不要なパスワード接続や古い公開鍵を見直す
鍵の種類や作成コマンドは、サーバーと利用するクライアントが対応する現行の公式手順に従います。特定のアルゴリズムを古い記事から固定すると、サーバー側で無効になっている場合があります。鍵を作った日と登録先を記録し、環境の更新時に互換性を確認します。
公開鍵認証だけで二要素認証になるとは限らない
公開鍵認証は、秘密鍵を持っていることを使う認証方式です。秘密鍵のパスフレーズは、通常クライアント端末で鍵を使える状態にするための保護です。サーバーが独立した二つの要素を検証していなければ、公開鍵とパスフレーズを使っても自動的に二要素認証になるとは限りません。
サーバー側で公開鍵に加えて別の認証要素を要求する構成もありますが、レンタルサーバーで利用できるかはサービスによって異なります。管理画面の二要素認証と、SSH接続の認証も別に設定されることがあります。どの入口がどの方式で守られるかを台帳へ分けて記録します。
パスワード認証を無効にする判断は、公開鍵で確実に接続でき、回復手段を確認してから行います。共有サーバーでは利用者が設定を変更できない場合もあります。サーバー会社の提供範囲を超えて設定ファイルを編集しません。
端末紛失や担当者変更では公開鍵を失効する
秘密鍵を保存した端末を紛失した場合は、サーバーに登録した対応する公開鍵を削除します。秘密鍵へパスフレーズがあっても、紛失を放置する理由にはなりません。接続ログを確認し、不審な利用があればファイル変更や認証情報の影響も調べます。
担当者変更では、新担当者が自分の端末で新しい鍵ペアを作ります。旧担当者から秘密鍵ファイルを受け取って引き継ぐのではありません。新しい接続を確認したあと、旧担当者の公開鍵とアカウントを無効にします。
権限台帳には、利用者・端末・接続先・公開鍵の識別情報・登録日・失効日を残します。秘密鍵やパスフレーズそのものは記載しません。定期的にサーバーの登録鍵と台帳を照合し、利用者が分からない鍵を調査してから削除します。
