SSH・SFTP・公開鍵認証の違いと安全な使い方

SSHは暗号化した遠隔接続、SFTPはその接続を使ったファイル転送、公開鍵認証は鍵で利用者を確かめる方法です。例えばSFTPソフトで公開鍵認証を選ぶと、SSHで守られた通信を使い、自分の秘密鍵で認証してファイルを扱います。

秘密鍵はサーバーへアップロードせず、対応する公開鍵だけを登録します。また、利用者の鍵とは別に、接続先が正しいか確認するための「ホスト鍵」があります。

SSH・SFTP・公開鍵認証は役割が違う

SSHの標準仕様では、SSHを安全でないネットワーク上でリモートログインや各種サービスを安全に利用するためのプロトコル群としています。コマンドを操作するシェル接続だけでなく、ファイル転送やほかの通信を保護する基盤にもなります。

SFTPは、FTP通信をTLSで暗号化するFTPSとは別の方式です。接続ソフトでSFTPを選んだ場合は、通常SSH用の接続先と認証方法を使います。名前だけを見てFTP用の設定を流用しないようにします。

レンタルサーバーでは、SFTPだけを許可し、SSHのシェル操作を制限することがあります。反対に、契約プランやアカウントによってSSHを利用できない場合もあります。管理画面と公式マニュアルで利用可能な機能を確認し、制作会社へ渡すアカウントの権限も必要な範囲に絞ります。

接続先のホスト鍵と利用者の鍵を分けて考える

SSH接続では、最初にサーバーがホスト鍵を提示します。これは利用者が「意図したサーバーへ接続しているか」を確認するための情報です。クライアントに表示されたフィンガープリントを、サーバー会社の管理画面や公式案内など別の経路で照合します。

利用者の公開鍵認証は反対方向です。利用者が秘密鍵で署名し、サーバーは登録された公開鍵で検証します。RFC 4252で定義されるpublickey方式でも、秘密鍵そのものをサーバーへ送る必要はありません。

ホスト鍵が突然変わったという警告は、サーバー移転や再構築でも表示されます。しかし、接続先の取り違えや中間者攻撃の可能性もあります。警告を消すために古い記録を削除する前に、変更理由と新しいフィンガープリントを確認します。

公開鍵は登録用、秘密鍵は本人だけが使う

鍵ペアを作ると、公開鍵と秘密鍵の二つができます。公開鍵は接続先サーバーへ登録してよい情報です。秘密鍵は本人であることを証明する側に使うため、制作会社・サーバー会社・社内の共有フォルダーへ送らず、利用者の管理された端末に保管します。

秘密鍵にはパスフレーズを設定します。端末から鍵ファイルだけが流出した場合に、直ちに利用される危険を下げられます。パスフレーズを秘密鍵と同じテキストファイルへ保存せず、会社が認めるパスワード管理ツールを使います。

鍵は担当者または端末ごとに分けます。「制作会社用」の秘密鍵を複数人でコピーすると、誰の利用か追えません。一人が退職したときに全員分の鍵を作り直すことにもなります。公開鍵のコメントや権限台帳に利用者と端末を記録します。

初回接続は現在の入口を残したまま試す

新しい公開鍵を登録するときは、現在ログインできている管理画面や接続をすぐ閉じません。登録に誤りがあると、新しい鍵で入れず、修正する入口まで失う可能性があります。予備の管理者またはサーバー会社の復旧方法も確認します。

初回設定は次の順番で進めます。

1. サーバーがSSHまたはSFTPへ対応するかを公式案内で確認する
2. 利用者の端末で鍵ペアを作り、秘密鍵にパスフレーズを設定する
3. 公開鍵だけを対象アカウントへ登録する
4. ホスト鍵のフィンガープリントを別経路の情報と照合する
5. 新しい接続で対象ディレクトリと操作範囲を確認する
6. 成功後に不要なパスワード接続や古い公開鍵を見直す

鍵の種類や作成コマンドは、サーバーと利用するクライアントが対応する現行の公式手順に従います。特定のアルゴリズムを古い記事から固定すると、サーバー側で無効になっている場合があります。鍵を作った日と登録先を記録し、環境の更新時に互換性を確認します。

SFTPの初回接続は一覧表示までで確認する

鍵を登録したら、最初はファイルを書き換えずに接続先を確認します。ここではOpenSSHのsftpコマンドを例にします。GUIソフトでは、同じ情報を接続設定の各欄へ入力します。

sftp -P 2222 -i ~/.ssh/example_key example-user@sftp.example.com

これは入力形式の例です。2222は既定のポート番号ではなく、ユーザー名・ホスト名・秘密鍵のパスとともに契約先の設定へ置き換えます。OpenSSHのsftpマニュアルでは、大文字の-Pで接続ポート、-iで使用する秘密鍵を指定します。サーバーへ登録した公開鍵ファイルと取り違えないようにします。

初回のホスト鍵は前述の方法で照合し、一致を確認してから進めます。接続後はpwdで現在のディレクトリ、lsで内容を表示し、byeで終了できます。意図したサイトの場所へ入れたことを確かめてから、別途退避とアップロードの手順へ進みます。

接続できない場合も、鍵を作り直したり権限を一括変更したりする前に、どの段階で止まったかを確認します。

最後の行はログイン認証とは別の問題です。ファイル権限の確認方法に沿って、変更が必要な対象を絞ります。サーバー側の制限であれば、利用者側で設定を緩めず管理者へ確認します。

公開鍵認証だけで二要素認証になるとは限らない

通常のSSH公開鍵認証では、登録した公開鍵に対応する秘密鍵を使えることを確認します。秘密鍵ファイルのパスフレーズは、端末内の鍵を保護するためのものです。保存済みの鍵やエージェントから使える構成もあるため、パスフレーズを付けたというだけで接続のたびに二要素を要求しているとは言えません。

一方、セキュリティキーなどの認証器内でPINや生体認証を要求する方式は、多要素として扱える場合があります。サーバーがパスワードを別途受け取ることだけが二要素認証の条件ではありません。利用している認証器と、サービス側が要求する認証の組み合わせで判断します。

サーバー側で公開鍵に加えて別の認証要素を要求する構成もありますが、レンタルサーバーで利用できるかはサービスによって異なります。管理画面の二要素認証と、SSH接続の認証も別に設定されることがあります。管理画面で二要素認証を有効にしても、SFTPの認証設定まで同時に変わるとは限りません。

パスワード認証を無効にする判断は、公開鍵で確実に接続でき、回復手段を確認してから行います。共有サーバーでは利用者が設定を変更できない場合もあります。サーバー会社の提供範囲を超えて設定ファイルを編集しません。

端末紛失や担当者変更では公開鍵を失効する

秘密鍵を保存した端末を紛失した場合は、サーバーに登録した対応する公開鍵を削除します。秘密鍵へパスフレーズがあっても、紛失を放置する理由にはなりません。接続ログを確認し、不審な利用があればファイル変更や認証情報の影響も調べます。

担当者変更では、新担当者が自分の端末で新しい鍵ペアを作ります。旧担当者から秘密鍵ファイルを受け取って引き継ぐのではありません。新しい接続を確認したあと、旧担当者の公開鍵とアカウントを無効にします。

公開鍵に利用者や端末が分かる名前を付けておくと、失効させる鍵を選びやすくなります。誰のものか分からない鍵を一括削除すると、現在使っている接続まで止めるおそれがあるため、用途を確かめてから扱います。秘密鍵そのものを引き継ぎ資料に載せる必要はありません。