SVX日記

　 朝っぱらから、起き抜けにFedoraである。ずっと、床に座ってキーボードを叩くのも疲れるので、リモートログインして作業ができるように、sshの設定から始めるのである。

　 sshの説明はあちこちにあるので、オイラはちょっと変わった説明をしてみたいと想う。sshとは、サーバにログインするための「認証」と「認証後の経路の暗号化」を組み合わせた、セキュリティ的に安全なリモートアクセスサービスのコトである。具体的には、クライアントの情報をサーバに登録し、登録されたクライアントからはパスワードなしでサクッとリモートログインできるようにする。それが、一般的な使い方である(少なくともオイラはそう思っている)。

　 で、この場合、事前に、(A-1)クライアントの鍵ペア(秘密鍵、公開鍵)を作り、(A-2)サーバにクライアントの公開鍵を登録する、という設定が必要となる。いわば、秘密鍵とは「指」であり、公開鍵とは「指紋」である。

　 サーバへ登録後のログインの際は、(B-1)クライアントがサーバに公開鍵を渡す、(B-2)サーバはその公開鍵の登録を確認し、乱数を公開鍵で暗号化して返す、(B-3)クライアントは受け取った暗号を秘密鍵で復号してサーバに返す、(B-4)サーバは受け取った数値が最初の乱数と同じなら認証成功となる。

　 しかし、ちょっと不思議なのが、多くのサイトに(A-2)の過程で「フロッピー等でサーバに公開鍵を登録すること」という記述のあるコトだ。「ssh フロッピー 公開鍵」でググれば、いくらでも出てくる。なんで「公開する鍵」を、秘密的な手段で運搬する必要があるんだ？　こんなもの、セキュリティ的に安全でないtelnet接続経由でも構わないのである。ほれほれ。ウチの公開鍵だぞ。

　 公開してもいいからこそ、公開鍵なのである。公開鍵を盗まれたトコロで、それから秘密鍵を得ることは不可能なのである。公開鍵を悪用しようにも、それをサーバに登録すれば、そのサーバにクライアントを招待するだけのコトしかできないのだ。

　 まぁ、Windows(クライアント)上で鍵ペアを作るのが難しいから、Linux(サーバ)上で鍵ペアを作り、秘密鍵をクライアントにフロッピーで運ぶ、という本来と逆の作業手順から広まった誤解なのであろうが、まるでsshを理解していないというコトがバレバレである。こんなチュートリアルを書いている管理者自体がセキュリティホールであるといえよう。

　 オイラ的に危険なコトを挙げると、1)サーバ上で秘密鍵を作ることが危険である、2)フロッピーで持ち出すことが危険である、3)秘密鍵をWindows上に置いておくことが危険である。逆に安全なコトを挙げると、1)sshを利用したリモートからの秘密鍵の登録は安全である、2)公開鍵の公開は安全である(^^;)。1)で注意しなければならないのは、ssh上からftpを利用しては意味がないないということだ。画面上をマウスでドラッグしてペーストしたり、scpを使う必要がある。意味のワカんない人は、危険を覚悟でフロッピーで秘密鍵を運んでください。たまにはスパイごっこも楽しいモノである。F-14で秘密鍵を運べば、気分はアフターバーナーIIである。

　 余談はさておき、クライアント側で「ssh-keygen -t rsa」を実行(あ、オイラのクライアントマシンにはcygwinが導入済みだ)、パスワードはリターン空打ちで、.ssh以下に、秘密鍵「id_rsa」と公開鍵「id_rsa.pub」を生成する。一度「ssh byakko -l furuta」として、パスワード入力によりFedoraにログインし、~furuta直下に.sshディレクトリを作成、その下に「authorized_keys」という名前でファイルを作成、その中に先ほどの公開鍵「id_rsa.pub」の中身を貼り付ける。一度ログアウトして、再度「ssh byakko -l furuta」として、ログインできればオッケーだ。

　 ……だが、オッケーじゃない。相変わらずパスワードを要求されてしまう。なんでだ？　この状況は前にもあった気がしたが忘れた。メモらないから忘れる。とりあえず「ssh -v byakko -l furuta」として、デバッグモードで走らせてみるが、公開鍵認証に失敗しているコトしかワカらない……思い出した!!　「authorized_keys」のパーミッションがダメなんだ。グループの書き込み権限がある664になっている。644ならオッケーらしい。ログイン先の「/var/log/secure」を見てみると「byakko sshd[xxxxx]: Authentication refused: bad ownership or modes for file /home/furuta/.ssh/authorized_keys」と確かに出ている。

　 しかし、なんでデフォルトが664なんだ？　たしか、デフォルトで作るファイルのパーミッションの設定がどこかあったような……なんだっけ？　「man mkdir」してみる。お。思い出した「umask」である。これにパーミッションをビット反転したものを設定するんだった。

　 設定がどこにあるのかわからないので、/etcの配下で「grep umask *」してカーペットボンビング(じゅうたん爆撃)。「bashrc」が引っかかった。これかな？　確認すると……

if [ $UID -gt 99 ] && [ "`id -gn`" = "`id -un`" ]; then
    umask 002
else
    umask 022
fi

　 ……なんて書いてある。ユーザIDが100以上で、ユーザ名とグループ名が同じなら664になるようになっている。余計なお世話だっつーの。んなもん常に644でよろし。022に修正。ログインしなおして「touch hoge」する。パーミッションは644になった。解決。

　 さて、そんなこんなでsshでのログインができるようになったトコロで、基本的な設定の続きをする。

　 sshで入ったトコロで「ls -lrt」すると漢字の「合計」の文字が化ける。これはFedoraがUTF-8を基本とするためらしい。別に英語ロケールにしておいても困りはしないが、気持ち悪いのでEUCに切り替えておこう。まずは、日本語ロケールを「locale -a | grep j」でリストアップ「vi /etc/sysconfig/i18n」で「LANG="ja_JP.UTF-8"」を「LANG="ja_JP.eucjp"」に変更する。ログインしなおせば、とりあえず、漢字が出るようになる。

　 しかし、manが文字化けする。どうやら、これはmanの漢字コードがUTF-8だかららしい。試しに「cp /usr/share/man/ja/man1/ls.1.gz .」し、展開して中身を開いても読めない。けっ。manが漢字で出なければ、日本語が出るようにした意味がねーじゃねーかよ。まぁいいや。

　 と、ここでいきなりキーボードが気になりだした。サーバに直結されているキーボード「FKB8579」から「`」が入力できなかったのだ。インストール時に「アメリカ合衆国」と「U.S.インターナショナル」で迷った挙句に「U.S.インターナショナル」を選んだのが裏目ったか？　「view anaconda-ks.cfg」してインストールログを確認してみると「keyboard us-acentos」という文字列があった。コイツだ。

　 例によって、設定がどこにあるのかわからないので、/etcの配下で「grep us-acentos *」「grep us-acentos */*」してダブルカーペットボンビー。出てきた。「sysconfig/keyboard」だ。「KEYTABLE="us-acentos」とある。今度は「KEYTABLE」というキーワードでググる……/libのどこかに設定があるらしい。例によってカーペットボンビングして、/lib/kbd/keymaps/i386/qwertyの存在を確認。ファイル「us-acentos.map.gz」と「us.map.gz」がキーマップの設定ファイルらしい。

　 興味本位に、両方のファイルをホームに持ってきて展開し「diff us-acentos.map us.map」として差分を取ってみる……おい、ヤケクソ違うぞ。まいっか。「vi /etc/sysconfig/keyboard」として「KEYTABLE="us-acentos"」を「KEYTABLE="us"」に修正する。

　 これは完全な再起動が必要な予感がするので「shutdown -h now」する。……ん？「shutdown -r now」じゃねーのかって？　今日はもう遅いから寝るのさ。ふぁ〜ぁ……というワケで、おやすみである。ぐぅ。