[ホスティング] SSHサーバーのホスト認証の仕組みを理解する

初めて接続するホストへssh接続を試みると、以下のようなメッセージが表示される。

OpenSSHではRSA鍵フィンガープリントを使ってホスト認証

OpenSSHでは、なりすまし(中間者攻撃)を防ぐホスト認証においてRSA鍵フィンガープリントが使われる。

入門OpenSSH / 第3章 OpenSSH のしくみ
http://www.unixuser.org/~euske/doc/openssh/book/chap3.html

RSA鍵フィンガープリントはホストのRSA公開鍵がベース

RSA鍵フィンガープリントは、ホストのRSA公開鍵からssh-keygenを使って表示される。

ホストのRSA公開鍵

公開鍵からフィンガプリントを表示

SSHサーバのRSA fingerprintの確認方法 | server-memo.net
http://www.server-memo.net/server-setting/ssh/rsa-fingerprint.html

クライアントはホストのRSA鍵フィンガープリントを記憶

冒頭のメッセージが表示されるのは、これまで接続したことが無いホストへ初めて接続したときである。このメッセージにyesと答えてホスト認証を通過すると、クライアントはホスト名とRSA鍵フィンガープリントのペアを~/.ssh/known_hostsに記録する。以降のアクセスでは、known_hostsに記録されているRSA鍵フィンガープリントと実際のホストが返すRSA鍵フィンガープリントが一致した場合には、そのホストは認証済みであると判断され確認メッセージは表示されない。

SSHの動作 — Fabric ドキュメント
http://fabric-ja.readthedocs.org/ja/latest/usage/ssh.html

RSA鍵フィンガープリントを無視することもできるが・・・

例えばバッチでscpを実行する場合など、確認メッセージに応えなければ先へ進めないのでは困る。sshやscpには、RSA鍵フィンガープリントの変更チェックをしないオプションも用意されている。しかし、無視することでホスト認証が行われないことになり、結果としてなりすまし(中間者攻撃)をチェックできなくなる。これはいただけない。

OpenSSHの警告メッセージを黙らせる | Siguniang’s Blog
https://siguniang.wordpress.com/2014/02/28/get-rid-of-openssh-warning-message/

SCP support for -o StrictHostKeyChecking=no broken | OpenSSH | Dev
http://www.gossamer-threads.com/lists/openssh/dev/54561

known_hostsを適切に維持更新するべき

脆弱性を生まないためには、確認メッセージが邪魔といった程度の理由でホスト認証をスキップしたりしないこと。確認メッセージが表示されること自体がイレギュラーなので、その理由をしっかり究明して適切な設定をするべき。

例えばバッチでscpを実行したい場合には、事前にコマンドを使ってknown_hostsを作っておけばよい。正しいknown_hostsが存在すれば、scp経由で初めてホストにアクセスしたときでも確認メッセージは表示されない。以後もし確認メッセージが表示されることがあれば、本来のホストになりすました別ホストへ本当に誘導されているのかもしれない。ホストの管理者にホストのRSA鍵フィンガープリントが本当に変わったのかを確認するべきだろう。

SSHのknown_hostsをスマートに更新する – Qiita
http://qiita.com/kawaz/items/20983ec286088a1ae5c7

ネットワーク管理の基本Tips:SSHサーバーの公開鍵管理を効率化するには? ssh-keyscanコマンド – @IT
http://www.atmarkit.co.jp/ait/articles/1507/28/news020.html

コマンド実行例

ホストのRSA鍵フィンガープリントを取得してknown_hostsに追加

記録されているRSA鍵フィンガープリントを削除

[Docker] ホストのディレクトリを操作するときには権限に気をつけよう

ちょっとハマッたので覚え書き。

Dockerでホストのディレクトリをマウントし、サブディレクトリやファイルを作成したところ、それらの所有者がホストに存在しないユーザになっていた。僕はこのホストのルート権限をもらっていないので、これらのファイルを削除するためには管理者に依頼する必要がある。管理はアウトソースしているので、それは面倒な話だ。

一時的な作業だったので、イメージもDockerfileも既に削除してしまっている。どうしたものかと思案した挙句、コンテナでシェルを実行したらルートユーザで接続されたので、そこでファイルの削除を試みたら成功。

Dockerでホストのディレクトリを操作するときには権限に気をつけよう。

[Docker] 不要なコンテナを一括削除する

不要なコンテナが溜まってきた。個別にコマンドを叩いて削除するのは面倒なので一括で削除したい。

方法1

ネットを検索したら以下の方法を発見。なるほど。

Dockerでいらなくなったコンテナを一括削除する – cpw’s diary
http://cpw.hatenadiary.jp/entry/2013/08/18/212630

方法2

さらに検索したら以下の方法を発見。短いほうがベター。

この方法はコンテナのステータスをチェックしていないけど大丈夫かいな。モノは試しでやってみたら、実行中のコンテナは以下のメッセージが表示されて弾かれた(Docker v.1.4.1)ので問題は無かった。

【Docker】不要になったイメージ、コンテナを削除する – 子持ちプログラマーの日記
http://kouji1981.hatenablog.com/entry/%E3%80%90Docker%E3%80%91%E4%B8%8D%E8%A6%81%E3%81%AB%E3%81%AA%E3%81%A3%E3%81%9F%E3%82%A4%E3%83%A1%E3%83%BC%E3%82%B8%E3%80%81%E3%82%B3%E3%83%B3%E3%83%86%E3%83%8A%E3%82%92%E5%89%8A%E9%99%A4%E3%81%99%E3%82%8B

[ホスティング] 自力でメールサーバーを運営したくない理由

DigitalOceanのスタッフが書いた記事。クラウドホスティング会社のスタッフがそこまで言うか、と思わないでもないけれど、素人仕立てのメールサーバーが濫立されたらサポートだって大変だろうし。言ってることは的を凍てると思う。僕も自力でメールサーバーを運営するのは諦めたよ。

Why You May Not Want To Run Your Own Mail Server | DigitalOcean
https://www.digitalocean.com/community/tutorials/why-you-may-not-want-to-run-your-own-mail-server

[ホスティング] DNSに関する基本知識

Google Apps 管理者ヘルプにDNSに関する解説コーナーあり。初心者向けに丁寧に説明してあって、自分にとって役立ちそうだったので覚え書きリンク。

DNS レコード – Google Apps 管理者 ヘルプ
https://support.google.com/a/topic/2716885?hl=ja&ref_topic=2426592

オンラインツールとしてブラウザから実行できるdigも提供されている。ちょっとしたときに便利。

Dig (DNS lookup)
https://toolbox.googleapps.com/apps/dig/

[ホスティング] CentOSにPHP5.6をインストールする (CentOS 7.1)

デフォルトのリポジトリでPHPをインストールすると5.4が入る。

epelとremiを追加する。

PHP 5.6をインストールする。

確認。

参考サイト

CentOSにPHP5.6をインストール – Qiita
http://qiita.com/pakiln/items/645e8a97cde46b59f9f8

[Apache] バーチャルホスト設定の参考サイト

公式ドキュメント

Apache バーチャルホスト説明書 – Apache HTTP サーバ バージョン 2.4
http://httpd.apache.org/docs/2.4/ja/vhosts/

Apache の IP ベースのバーチャルホストサポート – Apache HTTP サーバ バージョン 2.4
http://httpd.apache.org/docs/2.4/ja/vhosts/ip-based.html

名前ベースのバーチャルホスト – Apache HTTP サーバ バージョン 2.4
http://httpd.apache.org/docs/2.4/ja/vhosts/name-based.html

解説記事

以下は古い記事だけど(執筆2000年~2002年) よくまとまってる。

ApacheによるWebサーバ構築(8):バーチャルホストによる複数サイトの同時運用 (1/2) – @IT
http://www.atmarkit.co.jp/ait/articles/0108/28/news001.html

「ApacheによるWebサーバ構築」最新記事一覧 – ITmedia Keywords
http://www.atmarkit.co.jp/ait/kw/apache_webserver_kouchiku.html

[Apache] 名前ベースのバーチャルホストでIPアドレスによるアクセスを除外する

名前ベースのバーチャルホストでは、扱うホストそれぞれに対して<VirtualHost>ブロックを記述し、リストの最初のバーチャルホストがデフォルトのバーチャルホストとなる。IPアドレスでアクセスされた場合には一致するホスト名が見つからないため、デフォルトのバーチャルホストが使われる。この仕組みを利用して、デフォルトのバーチャルホストを例えば以下のように記述しておけば、IPアドレスでアクセスされた場合には外部サイトへ強制的にジャンプさせることが可能になる。

公式ドキュメントにも説明がある。

リクエストが来ると、サーバはまず最初に <NameVirtualHost> にマッチする IP アドレスかどうかをチェックします。マッチすれば マッチした IP アドレスの <VirtualHost> のそれぞれのセクションの中から ServerName か ServerAlias に要求されたホスト名があるか探します。 見つかればそのサーバ用の設定を使います。マッチするバーチャルホスト が見つからなければ、マッチした IP アドレスの リストの最初にあるバーチャルホスト が使われます。

結果として、リストの最初のバーチャルホストが デフォルト の バーチャルホストになります。IP アドレスが NameVirtualHost ディレクティブにマッチした場合は、メインのサーバ の DocumentRoot は決して使われません どのバーチャルホストにもマッチしないリクエストに対して、 特別な設定をしたいのであれば、設定ファイル中の最初の <VirtualHost> コンテナにそれを記述してください。

名前ベースのバーチャルホスト – Apache HTTP サーバ バージョン 2.4
http://httpd.apache.org/docs/2.4/ja/vhosts/name-based.html