一連のイベントにより、2つのホスト間のSSH通信の整合性を確保することができます。
まず、クライアントが、適正なサーバーと通信していることを認識するように、安全なトランスポート層を作成します。次に、対称暗号を使ってクライアントとサーバー間の通信を暗号化します。
次に、所定のサーバーとの安全な接続を確立したら、クライアントが自分自身をサーバーに対して認証します。このとき、認証情報が漏れることを心配する必要はありません。Red Hat Linux上のOpenSSHは、デフォルトでは、DSA鍵またはRSA鍵と、バージョン2.0のSSHプロトコルを認証に使用します。
最後に、クライアントがサーバーに対して認証し終えると対話的ななシェルセッション、X11アプリケーション、トンネル化TCP/IPポートなどの各種サービスを、接続を介して安全に安心して使用できるようになります。
接続プロセス全体を通して、ローカルシステムで追加作業を実行する必要はほとんどありません。実際、SSHは、安全性に欠ける接続方法を利用しているユーザーを対象としているため、大抵の場合は問題なく動作します。
次の例では、クライアントシステム上のuser1がサーバーとSSH接続を開始しています。サーバーのIPアドレスは10.0.0.2ですが、IPアドレスではなくドメイン名を使用することもできます。サーバーに対するuser1のログイン名はuser2です。次のようなsshコマンドを実行します。
[user1@machine1 user1]$ ssh user2@10.0.0.2 |
OpenSSHクライアントは、秘密鍵を復号するための、ユーザーの秘密鍵のパスフレーズを要求し、これを使って認証を行います。ただし、秘密鍵のパスフレーズは、クライアントとサーバー間の安全な接続上で送られるのではありません。パスフレーズは、id_dsaファイルのロックを解除し、署名を生成して、その署名をサーバーに送信する場合に使用します。サーバーが、署名を確認する場合に使用できるユーザーの公開鍵のコピーを持っていれば、ユーザーは認証されます。
この例で、ユーザーはDSA鍵（もちろん、RSA鍵でもかまいません）を使用しているので、次のプロンプトが表示されます。
Enter passphrase for DSA key '/home/user1/.ssh/id_dsa': |
何らかの理由により（おそらく、パスフレーズをタイプミスしたか、認証情報がまだサーバー上にないことが原因です）公開鍵認証に失敗した場合は、通常は別のタイプの認証が試みられます。この例では、OpenSSHサーバーは、送信された署名と、user2が格納した公開鍵とが一致していないので、user1に対し、user2のパスワードを使って自分自身を認証することを認めます。
user2@machine2's password: |
パスワードを正しく入力すると、シェルプロンプトが表示されます。もちろん、user2が、10.0.0.2マシン上のアカウントを持っていなければ、パスワード認証は失敗します。
Last login: Mon Apr 15 13:27:43 2001 from machine1 [user2@machine2 user2]$ |
これで、ユーザーは、telnetやrshの場合と同じようにシェルと対話することができます。異なる点は、通信が暗号化されているということだけです。
scpとsftpのその他のSSHツールも、それぞれ、安全性に欠けるrcpとftpと同じように動作します。その他のSSHコマンドの使用法とその例については、オフィシャル Red Hat Linux カスタマイズガイドを参照してください。