とりあえず安全に活用するためにおもいつくまま、書いてみました。 具体的な設定例は、次の機会に紹介したいと思います。
私の場合、秘密鍵は USBメモリで管理しています。ここで紹介した内容では、秘密鍵を所有するのは、メインサーバーとなります。通常、起動している状態にあるメインサーバー 側に ssh の秘密鍵を置いておくのは良くありませんので USB メモリで管理しています。必要なときは、ユーザーからマウントさせ( sudo でマウント許可を与えておく)、サブシステムへ同期を行うようにしています。 つまり、USBメモリがなければ、メインシステムからサブシステムへ接続出来ないようにします。
デフォルトでは~/.ssh ディレクトリに保存されますが、これをマウントしたメディアに変更するか、シンボリックで対応します。マウントコマンドに関する知識が必要になります。マウントポイントとなるディレクトリを作成し、定義します。
今回は Linux 同士のディレクトリの同期でしたが、 Windows からSSHでリモート接続を行う場合もUSBメモリなど外部メディアを活用することで安全性が高まります。この辺は、Linux と違って、あまり難しく考える必要がありません。
やっている事は原始的に思えますが、外部メディアで管理する方法は、公開鍵による認証、特にパスフレーズを要求しないケースでは有効です。ノートパソコ ンなど盗難にあう確立の高い端末からの操作においても安全性が高まります。デスクトップにおいても、他人が触ってしまう可能性がある仕事場でも有効です。
最も基本的なのが、iptables による port 22 への制限です。sshは、port22 が Well known ポートとなっています。Wrapper 経由で接続元を制限することは出来ますが、SSHトンネリングの利用を考えた場合、やはりパケットフィルタリングによるファイアーウォールで弾くようにし た方が細かな制限が行なえます。
ちなみに CentOS4/FedoraCore4 は sshd は常駐するデーモンとしてインストールされています。アクセス制限はsshdの設定だけでなく iptabls を併用するようにします。
例えば、このようなネットワーク構成の場合で、ローカルホストがインターネット経由でウイルスに感染した場合、適切なファイアーウォールが構築されていな いと、内側から直接、メンテナンス・検証用のサブシステムに直接SSHへアクセスされてしまいます。iptables や、ネットワーク型IDS を使ってメンテナンスサーバのeth1 port22 の間口は右のメインサーバー eth1 にのみ解放する事で、リスクは低減されます。
保険として、特定のアドレスからのport22への接続要求は Snort の FlexResp を用いて通信終了パケットを強制的に送りつけアタックができないようにします。
sshd が同時にコネクションが行えるユーザー数を制限します。以下で紹介されています。
http://www.itmedia.co.jp/help/tips/linux/l0541.html
ユーザー単位で ssh の利用を不許可にする事も出来ます。
参照 => @IT:sshの利用をユーザー単位で許可/不許可するには
SSHのログイン情報は /var/log/secure に記録されます。ソースからは/var/log/auth.log だったと思います。ディストリビューションによっても違うかもしれません。例え、管理者のみと使用が限られるとしても、Swatch等のログ監視ツールを 使用してログイン状況を常に把握しておく事は大切です。ファイアーウォールだけでなく、常日頃からログを監視しするようにして下さい。ファイアーウォール 下にある守られたネットワークだからといって安心するのは良くありません。
初心者が始めてコンソールを使ったリモートコントロールを行なう場合、特に注意したいのが root 権限の使用です。メンテナンスを行なうためにSSHログイン後、root権限を"su"で取得しなければならないケースもあります。root権限で誤って 操作をしてしまうと取り返しの付かないことになります。単純なコピーコマンドであっても重要なディレクトリを上書きしてしまうといった事も十分考えられます。
このように、su/sudo を使用してroot権限を取得して操作する場合、誤って操作をしてしまわないよう、事前に特定のコマンドを制限、禁止しておく事も大切です。これは Linux 操作全般に関する基本的な事なので、ここでは説明しません。興味があれば、以下が解り易いと思います。
学習リソース => 不正侵入の手口と対策
学習リソース => 分かりやすい所有権の話
学習リソース => 止められないUNIXサーバのセキュリティ対策 ( sudo を使ったコマンドの制限について)