第6章 ネットワークアプリケーション

スパム（迷惑メール）問題にさらされるのを最小化するために、現代的なメールサービスには様々な制約があります。

なぜなら:

Debian 上のいくつかのプログラムは、UNIX システム上のメールサービスが歴史的に以下のように機能したため、デフォルト設定でもカスタマイズ設定でも /usr/sbin/sendmail コマンドにアクセスして以下のようにして電子メールを送ることを期待します:

OpenSSH SSH デーモンは SSH プロトコル2のみをサポートします。

"/usr/share/doc/openssh-client/README.Debian.gz" と ssh(1) と sshd(8) と ssh-agent(1) と ssh-keygen(1) と ssh-add(1) と ssh-agent(1) を参照下さい。

	警告
	OpenSSH サーバーを実行したい場合には、"/etc/ssh/sshd_not_to_be_run" が存在してはいけません。 rhost に基づく認証を有効化してはいけない (/etc/ssh/sshd_config 中の HostbasedAuthentication )。

クライアントから ssh(1) 接続を開始するには以下のようにします。

ローカルホストとリモートホストで同じユーザ名を使っている場合は "username@" と打たなくてもよいです。

"PubkeyAuthentication" (SSH-2 プロトコル) を使うと、リモートシステムのパスワードを覚えなくてもよくなります。

リモートシステムの "/etc/ssh/sshd_config" 中に対応する項目 "PubkeyAuthentication yes" を設定します。

次に示すように、ローカルで認証鍵を生成しリモートシステム上に公開鍵をインストールします。

$ ssh-keygen -t rsa
$ cat .ssh/id_rsa.pub | ssh user1@remote "cat - >>.ssh/authorized_keys"

ホストを制限したり特定コマンドを実行したりするには "~/.ssh/authorized_keys" 中の項目にオプションを追加します。sshd(8) の "AUTHORIZED_KEYS FILE FORMAT" を参照下さい。

SSH の認証鍵をパスフレーズで保護する方がより安全です。もしパスフレーズが設定されていない場合には "ssh-keygen -p" で設定できます。

上記のようにパスワードを使って接続したリモートホスト上の "~/.ssh/authorized_keys" 中にあなたの公開 SSH 鍵 (例えば "~/.ssh/id_rsa.pub") を設定します。

$ ssh-agent bash
$ ssh-add ~/.ssh/id_rsa
Enter passphrase for /home/username/.ssh/id_rsa:
Identity added: /home/username/.ssh/id_rsa (/home/username/.ssh/id_rsa)

今後、次のコマンドにリモートパスワードは必要ありません。

$ scp foo username@remote.host:foo

ssh-agent のセッションを終了するのに ^D を押します。

X サーバーの場合、普通の Debian の起動スクリプトは親プロセスとして ssh-agent を実行します。だから ssh-add は1回だけ実行すれば十分です。詳細は ssh-agent(1) と ssh-add(1) を参照下さい。

適切な DNS 設定がなされたサーバに SSH アカウントを持っている場合、リモートサーバから真に送られたメールとして、ワークステーションからメールを送信することができます。

ssh を通して localhost のポート 4025 から remote-server のポート 25 へと、localhost のポート 4110 から remote-server のポート 110 へと接続するパイプを設定するには、ローカルホスト上で以下のように実行します。

# ssh -q -L 4025:remote-server:25 4110:remote-server:110 username@remote-server

このようにするとインターネット経由で SMTP/POP3 サーバーへとセキュアーに接続できます。リモートホストの "/etc/ssh/sshd_config" 中の "AllowTcpForwarding" エントリーを "yes" と設定します。

問題があるときは設定ファイルのパーミッションを確認し、ssh を"-v" オプションとともに実行します。

root でファイアーウォールと問題を起こした場合には、"-p" オプションを使います; こうするとサーバーポートの 1 — 1023 を使うのを回避します。

リモートサイトへの ssh 接続が急に動作し無くなった際は、システム管理者による変更、特に可能性が高いのはシステムメンテナンス中に "host_key" が変更された結果かもしれません。実際にこういう状況で誰も洒落たハックでリモートホストとしてなりすまそうとしていないことを確認した後に、"host_key" エントリーをローカルホストの "~/.ssh/known_hosts" から削除すると再び接続できるようになります。