SVX日記

2004|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|

2005-09-20(Tue) sshの公開鍵を公開してみる

  朝っぱらから、起き抜けに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」じゃねーのかって? 今日はもう遅いから寝るのさ。ふぁ〜ぁ……というワケで、おやすみである。ぐぅ。

本日のツッコミ(全2件) [ツッコミを入れる]
2323 (2006-04-12(Wed) 22:01)

A-2となっている公開鍵の登録ですが、公開鍵を秘密に登録したいのではなく、安全な経路で登録したというのが本筋です。登録先が自分の思っているホストではなく、巧妙に詐称されたサイトであった場合の危険性くらいはわかりますよね。

フルタニアン(管理者) (2006-04-13(Thu) 09:24)

「危険性くらいは」と書かれるとカチンときますね。わかりません。どんな危険性がありますか?<br>初めて通信する相手が、確かに自分の意図する相手かどうかを確認する完全な方法なんてありません。極端なコトを言えば、CAに証明してもらったって、フロッピーを直接に突っ込んだって100%とは言えません。しかし通常は「初回にパスワードでリモートログインできた」という事実をもって、確認としては十分でしょう。<br>仮にホストの設置場所が遠隔地だった場合には、どうしたらよいとお考えですか? フロッピーで送付するのが安全な経路といえないことくらいはわかりますよね?