![[OpenSSH]](../images/smalltitle.gif){kind=small}
1.0 - OpenSSH ってなに? どこで手に入るの?
- 1.1 - OpenSSH ってなに? どこからダウンロードできる?
- 1.2 - OpenSSH を使うと何がうれしいの?
- 1.3 - どんなオペレーティングシステムに対応しているの?
- 1.4 - 著作権や取り扱い、特許についてはどうなってるの?
- 1.5 - 困ったらどこに質問すればいい?
2.0 - 一般的な質問
- 2.1 - なぜ ssh/scp は小さい番号のポートからコネクションを張ろうとするの。ファイヤウォールにはねられるんだけど。
- 2.2 - なんで ssh クライアントは setuid root されているの?
- 2.3 - なぜ SSH 2.3 は OpenSSH 2.1.1 と相互運用するときに問題が生じるの?
- 2.4 - OpenSSH で「Dispatch protocol error: type 20」と怒られた。なぜ?
- 2.5 - 古いバージョンの商用 SSH では、ホスト鍵を IDEA で暗号化してるんだけど。
- 2.6 - キーの長さで警告メッセージが出る。
- 2.7 - X11 転送やエージェント転送がきかない。
- 2.8 - OpenSSH をアップグレードしたら、SSH2 が使えなくなった。
- 2.9 - ssh は問題ないのに、sftp/scp が接続に失敗する。
- 2.10 - scp に (なにかの機能) を追加してくれない?
- 2.11 - ポート転送機能はどうやって使うの?
- 2.12 - なにもしないで N 分たつと ssh 接続が固まるか、切れるかするんだけど。
- 2.13 - コロン (:) が入った名前のファイルを scp でコピーするには?
- 2.14 - なぜ OpenSSH はクライアントにバージョン番号を教えるの?
3.0 - 移植版 OpenSSH に関する質問
- 3.1 - 偽の PAM 認証メッセージがログに残るんだけど。
- 3.2 - PAM 認証では、空のパスワードは許されないの?
- 3.3 - ssh(1) が接続する、あるいはログインするのに時間がかかる。
- 3.4 - Linux で、ログに "Can't locate module net-pf-10" というメッセージが残るんだけど。
- 3.5 - (Slackware 7.0 や Red Hat Linux 6.x などで) パスワード認証がうまくいかない。
- 3.6 - Configure や sshd に、 RSA あるいは DSA がサポートされていない、と文句を言われるんだけど。
- 3.7 - "scp: command not found" エラーがでる。
- 3.8 - パスフレーズが入力できない。
- 3.9 - 'configure' がない、あるいは make に失敗する。
- 3.10 - ssh が終了時に固まって(ハングして)しまう。
- 3.11 - なぜ ssh は終了時に固まる(ハングする)の?
- 3.12 - OpenSSH 3.1 にアップグレードしたら、X11 転送が効かなくなった。
- 3.13 - OpenSSH 3.8 にアップグレードしたら、いくつかの X11 プログラムが動かなくなった。
- 3.14 - 公開鍵を authorized_keys にコピーしたんだけど、まだ公開鍵認証がうまくいかない。
- 3.15 - OpenSSH のバージョンと PAM のふるまいについて。
- 3.16 - AIX 5.x で、ssh 経由でログインしているユーザが "w" または "who" で表示されないんだけど。
OpenSSH は、SSH プロトコルを使用するネットワーク接続ツールの フリーな 実装です。 インターネット上の増加しつつある人々が、これらのツールを信頼するようになっています。 Telnet, rlogin, ftp などのプログラムを使っている多くのユーザは、 自分のパスワードがネット上を暗号化されないまま流れていることに 気づいていないかもしれません。でも、実際にはそうなのです。 OpenSSH はパスワードを含むすべての通信を暗号化し、盗聴やネットワーク接続の乗っ取り、 その他のネットワークレベルの攻撃を効率的に排除します。
OpenSSH 一式は、以下のものを含んでいます。 rlogin および telnet に代わる ssh(1) プログラムと、 ftp(1)、 rcp(1) に代わる scp(1)。 sftp(1) と sftp-server(8) も加わりました。これはより簡単にファイル転送を行う 機構を提供するもので、 IETF ドラフト secsh-filexfer (英語) に基づいています。
OpenSSH はいくつものプログラムから構成されています。
OpenSSH は 2つの配布形態をとっています: ネイティブな OpenBSD 専用 の配布と、 複数のプラットフォームに対応した 移植版 の配布です。 最新の OpenBSD、またはその組み込み製品用の OpenSSH が欲しい場合は、 おそらく OpenBSD 専用 のほうが望ましいでしょう。 いっぽう OpenSSH を別のプラットフォームで使いたい場合、 あるいは古い OpenBSD 上で OpenSSH を使いたい場合は、 おそらく 移植版 が必要になります。
ダウンロードの際は、お住まいの地域の近くにある ミラーサイト をお使いください。
OpenSSH は、安全なネットワーク接続を支援する ツールの一式で、以下のような機能をもっています:
現在、コンピュータネットワークにおけるほとんどの通信は 暗号化されていません。その結果、あるネットワークに接続されている マシンのどれかにアクセスできる人物は誰でもその通信を盗聴できて しまいます。これはクラッカーや、詮策好きな管理者や、雇用者、 犯罪者、産業スパイ、そして政府などによって行われていることです。 ネットワークによっては、遠距離からでも十分盗聴できてしまうような 電磁波を放射していることもあります。
あなたがログインするとき、あなたが入力したパスワードはそのままの 形でネットワーク上を流れています。よって、盗聴者は誰でもあなたの アカウントを使って悪いことがなんでもできてしまいます。 このような事件は世界中で多く起きています。知識がない所有者の ワークステーション上で、クラッカーがネットワークを盗聴し パスワードを収集するプログラムを走らせているのです。 このようなプログラムはインターネット上で手に入りますし、 有能なプログラマなら数時間で作ることができるものです。
ビジネスの世界ではさまざまな秘密があります。取り引き上の機密や 準備段階の特許、価格情報や下請けの情報、顧客情報に人事データ、 財務情報などなど。現在、ネットワーク (そのネットワーク上のいずれかの マシン) にアクセスできる人間は、誰でもそのネットワークに流れる データを盗聴できます。通常のアクセス制限に関係なくです。
多くの企業は、情報がこのように、いとも簡単にネットワークから 復元できてしまうということに気づいていません。彼らは自分たちのデータが 安全であると信じています。なぜなら誰もそんな重要な情報が ネットワーク上を流れているとは知らないだろうし、あるいはネットワーク上には それ以外のデータだって大量に流れていると思っているからです。 これは、安全な考え方とはいえません。
OpenSSH は OpenBSD 用に 開発されたにもかかわず、実に多様なオペレーティングシステム用の 移植版が存在しています。移植版の OpenSSH は Damien Miller によって開発が統括されています。移植版 OpenSSH についての 簡単な概要は http://www.openssh.com/portable.html を ご覧ください。現在サポートされている OS の一覧は以下のとおりです:
OpenSSH をディストリビューションに含んでいるベンダーの一覧は、 www.openssh.com/users.html にあります。
OpenSSH の開発者たちは、OpenSSH をいかなる特許や著作権問題からも 自由でありつづけるようにするために、多大な努力を払ってきました。 このため、いくつかのオプション、特許のあるアルゴリズムを 使うためのオプションは、OpenSSH から削除されています。
OpenSSH は特許のある転送アルゴリズムはまったくサポートしていません。 SSH1 モードでは、3DES および Blowfish だけが使用可能なオプションです。 SSH2 モードでは、3DES, Blowfish, CAST128, Arcfour および AES を 選ぶことができます。特許がある IDEA アルゴリズムはサポートされていません。
OpenSSH は SSH1 および SSH2 両方のプロトコルをサポートしています。
RSA の特許が切れたので、RSA アルゴリズムを使った ソフトウエアを使用するのはもうまったく問題がなくなりました。 OpenSSH も含めて。
助けを得るための場所はたくさんあります。 OpenSSH のメインサイト のほかにも、 参加する価値のあるメーリングリスト(英語)が沢山あります。 メーリングリストで尋く前に、まずすべてのメーリングリストで アーカイブを探してみてください。あなたの質問は、すでに誰かが 答えているかもしれません。OpenSSH のメーリングリストは アーカイブに収集されており、それらは検索できるような形で marc.info (英語) に記録されています。
OpenSSH 関連のメーリングリストに参加するための より詳しい情報については www.openssh.com/list.html をご覧ください。
バグレポートを提出するさいの情報は、 OpenSSH の バグ報告 ページにあります。
Rhosts 認証や rhosts-RSA 認証を使う場合、OpenSSH クライアントは 小さい (1024未満の) 番号のポートを使います。 これはサーバがクライアントによって送られてきたユーザ名を信用する 必要があるからです。小さい番号のポートを使わないようにするには、 ssh_config か ~/.ssh/config に以下の行を追加してください:
UsePrivilegedPort no
あるいは、 ssh(1) のコマンドラインに -o オプションをくわえてもいいでしょう:
$ ssh -o "UsePrivilegedPort no" host.com
前の質問 (2.1) と関連することですが、 OpenSSH は rhosts 認証 を使うときに特権ポート (1024番未満のポート) を bind する必要があります。このため root 権限が必要なのです。 特権ポートはまた、古い SSH リリースで rhosts-rsa 認証を使うときにも必要です。
加えて rhosts-rsa 認証 (プロトコル バージョン 1) や hostbased 認証 (プロトコル バージョン 2) を使うさいには、 ssh クライアントはサーバに対して自分のマシンを認証するため ホスト秘密鍵 にアクセスする必要があります。
OpenSSH バージョン 3.3 以前は、これを利用するためには
ssh 実行ファイルに setuid ビットが必要でした。
これらの認証方法を使わないのなら setuid ビットはなくても問題ありません。
OpenSSH バージョン 3.3 から、ssh はデフォルトでは
setuid されなくなりました。特権を必要とするホスト鍵の読み込みには
ssh-keysign が使われ、
ssh はデフォルトでは特権ポートを送信元として使わないようになりました。
現在では特権ポートを送信元として使いたい場合、手で ssh を
setuid する必要があります。
SSH 2.3 およびそれ以前のバージョンは、HMAC の実装に欠陥が あるのです。これらのコードはダイジェストからのデータブロックを フルで渡さずに、いつも 128ビットを渡しています。もっと長い ダイジェストでは、SSH 2.3 では OpenSSH と相互運用できなくなって しまいます。
OpenSSH 2.2.0 は SSH 2.3 がこの欠陥を持っていることを検出します。 このバグは、SSH の最近のバージョンでは直っています。 あるいは、SSH 2.3 の sshd2_config にこう加えることでも 対処できます:
Mac hmac-md5
このような相互運用の問題が起こるのは、古いバージョンの OpenSSH が rekeying をサポートしていないためです。 しかし 商用 SSH 2.3 はこの機能を使おうとするので、 接続が止まってしまったり、 "Dispatch protocol error: type 20" というエラーメッセージが表示されるという経験をお持ちかもしれません。 この問題を解決するには、最近の OpenSSH リリースにアップグレードするか、 商用 SSH 2.3 の sshd_config にrekeying を禁止する以下の行を 追加します:
RekeyIntervalSeconds 0
古いバージョンの SSH では /etc/ssh/ssh_host_key を 暗号化するのに特許のあるアルゴリズムを使っています。これにより sshd(8) でホスト鍵が読めないという問題が発生します。これを解決するには、 以下のコマンドでお使いの ssh_host_key を、3DES を使用したものに 変換します。 注意: 商用 SSH の ssh-keygen(1) プログラムをご使用ください。以下の例は OpenSSH 用では *ありません*。
# ssh-keygen -u -f /etc/ssh/ssh_host_key
商用 SSH の ssh-keygen(1) プログラムにはバグがあって、ときどき最上位ビット (MSB) がセットされていない Pubkey (RSA または DSA) 認証鍵を生成してしまいます。 このような鍵はほとんどの場合、公称の長さよりも実際の鍵が短くなっています。
OpenSSH はこういった鍵を見つけると警告メッセージを出力します。 これが出ないようにするには、自分の known_hosts ファイルを 編集して、違っている鍵の長さ (ふつうは "1024") を正しい長さ (ふつうは "1023") に直します。
ssh_config と sshd_config をご確認ください。 デフォルトの設定ファイルでは、認証エージェントや X11 の 転送は禁止されています。これを許可するには、 まず以下の行をsshd_configに加えます:
X11Forwarding yes
次に、以下の行をssh_configのほうに加えます:
ForwardAgent yes
ForwardX11 yes
X11 の転送には、きちんと動作する xauth(1) バイナリが必要です。OpenBSD では、これは xbase ファイルセットに含まれていますが、 ほかのプラットフォームではたぶん違っているでしょう。移植版 OpenSSH では、 xauth の位置は configure の段階で検出されるか、あるいは sshd_config(5) や ssh_config(5) 設定ファイルの XAuthLocation 項目で指定することができます。
エージェントの相互運用に関する注意: SSH2 プロトコルの中には 2つの異なった、互いに相互運用できない エージェント転送のための機構が用意されています。OpenSSH はつねに 元々の SSH1 エージェント要求の拡張版を使いますが、商用製品の中には 異なる、フリーでないエージェント転送プロトコルを使うものもあります。 つまり、これらの製品と OpenSSH の間ではエージェント転送をおこなうことは できません。
注意: Linux Mandrake 7.2 のユーザへ。 Mandrake では /etc/skel/.bashrc 内で XAUTHORITY 環境変数を変更してから bash ユーザの ホームディレクトリを変更します。でもこの変数は OpenSSH が 使用するので、上のオプションがうまく動作するためには以下の行を コメントアウトする必要があります:
# export XAUTHORITY=$HOME/.Xauthority
このバージョンアップのとき、デフォルトの sshd_config や ssh_config も変更されたからです。OpenSSH のバージョンを アップグレードしたときは、必ずこれらの設定ファイルの違いも チェックするようにしてください。OpenSSH 2.3.0 以降では、 次の項目を sshd_config に追加する必要があります:
HostKey /etc/ssh_host_dsa_key
HostKey /etc/ssh_host_rsa_key
シェルの初期化ファイル (.profile, .bashrc, .chsrc など) が、 対話的でないセッションのときに何か出力すると sftp や scp は失敗します。このような出力は sftp/scp クライアントを 混乱させてしまうのです (訳注: sftp や scp はファイルの受け渡しに 標準入出力を使っているため)。お使いのシェルがそうなっているか どうかは、以下のコマンドを実行することで確かめることができます:
ssh yourhost /usr/bin/true
もし上のコマンドを実行してみて何らかの出力がされるようなら、 お使いのシェルの初期化ファイルを修正する必要があります。
簡単な答え: だめです。
長めの答え: scp は標準化されていないのです。これにもっとも近いのは「rcp が何をやるか」という 仕様だけです。これは接続の両側で同じコマンドが使われるため、機能やオプションを追加すると 異なる実装の間で相互運用できなくなる危険性があります。
新しい機能は sftp のほうが追加されやすいでしょう。なぜならこのプロトコルは 標準化されていますし (まあ、 ドラフト標準ですが)、 拡張可能であり、クライアントとサーバが別々になっているからです。
リモート側のサーバで sshd(8) が走っていれば、ある種のサービスを ssh 経由で「トンネリング」することが可能です。これはたとえば POP や SMTP などの接続を、たとえそのソフトウエアが直接には暗号化された 通信をサポートしていなくても、暗号化して使いたい場合に有効です。 トンネリングはクライアントとサーバ間に接続を張るためにポート転送を使用します。 これがうまくいくためには、クライアント側のソフトウエアは標準でないポート番号を 指定しても接続できるようになっている必要があります。
基本的なアイデアは、ユーザがリモートホストに接続して ssh を使用するときに、 クライアント側のマシンのどのポートがリモート側のサーバに接続を 転送するために使われるかを指定します。こうしておけば、クライアントマシンの ssh に渡したローカルなポート番号上で暗号化されたサービス (fetchmail や irc など) を動かすことができ、そこへの接続は ssh 経由で トンネリングされます。デフォルトでは、ポート転送をおこなっている サーバはそのマシン自身による (訳注: loopback からの) 接続のみを受けつけます。
トンネリングのさいにもっともよく使われるオプションは -L と -R オプションです。 これはユーザが接続を転送できるようにし、-D オプションは動的なポート転送を可能にします。 また -g オプションを使うと、他のマシンからの接続も受け付けるようになります。 また -f オプションを使うと、ssh クライアント自身を認証後にバックグラウンドで走らせることが できるようになります。これらのオプションの詳細については ssh(1) のマニュアルページを参照してください。
以下の例では、IRC のセッションをローカルなクライアントマシン ``127.0.0.1'' (localhost) からリモートのサーバ ``server.example.com'' にトンネリングしています:
ssh -f -L 1234:server.example.com:6667 server.example.com sleep 10
irc -c '#users' -p 1234 pinky 127.0.0.1
この例では、接続を IRC サーバ server.example.com にトンネリングし、 ニックネーム ``pinky'' をつかってチャンネル ``#users'' に join しています。 ここで使われているローカル側のポートは 1234 です。この値が 1024 以上で、 それがすでに使われているポートと同じでなければ、どの番号を使ってもかまいません (注意: ポート番号が 1024 未満のポートにソケットを開けるのは root だけです)。 IRC サービスの標準ポート番号は 6667 なので、この接続はリモート側の サーバのポート番号 6667 に転送されます。
リモート側のコマンド ``sleep 10'' は、トンネリングするサービスを 開始するまでにかかる許容時間を指定しています (この例では 10秒としています)。 もし指定された時間の間に接続が行われなければ、ssh は終了します。 より長い時間が必要な場合は、sleep(1) の値を増やすか、あるいは、 上の例にはユーザのシェル関数を追加することもできます。ユーザ定義関数については ksh(1) あるいは csh(1) マニュアルを参照してください。
-N オプションを指定することもできます。これはポート転送をおこなうさいに便利です。 -N が指定されると、特定のリモート側コマンド (上の例では ``sleep 10'') を 指定する必要がありません。しかし、このオプションを使うと ssh は (リモート側のコマンドが完了すれば抜けるのとは違って) 永久に終了しなくなりますので、 ユーザが後でそのプロセスを kill(1) するなどの処置が必要となります。
これはふつう、通信がないと TCP 接続をタイムアウトさせてしまう パケットフィルタか NAT デバイスの影響です。サーバ側の sshd_config にある ClientAliveInterval を許可するか、あるいはクライアント側の ssh_config にある ServerAliveInterval を許可してください。
上のいずれかのオプションを許可し、送信間隔をその接続のタイムアウト時間よりも 短く設定することで、接続テーブル内でつねにその接続を「新鮮」に保つことができるようになります。
$ scp ./source:file sshserver:
ほかの多くの SSH 実装と同様に、OpenSSH もクライアントが接続したときに その名前とバージョン番号をクライアントに伝えます。たとえば:
SSH-2.0-OpenSSH_3.9
この情報は、相手側の実装の細かいプロトコル上の変更やバグ、欠落した機能などの 差異を吸収するためにクライアントとサーバによって使われます。 このバージョン番号のチェック機能は、いまだ必要です。 なぜなら SSH プロトコルは未だ RFC として定められてはおらず、 そうなる前にさらなる互換性のない変更が行なわれる可能性があるからです。
移植版 OpenSSH は、ログインするたびに偽の認証失敗メッセージを 生成します。たとえばこんな感じです:
"authentication failure; (uid=0) -> root for sshd service"
これは OpenSSH が、まずそのユーザのログインに認証が必要かどうかを 調べるためです (例: パスワードをつけていないなど)。不幸にも PAM は認証関係のイベントをとにかくぜんぶ残したがるので、 これもそのひとつです。
もし、これがかなりイラつくようなら sshd_config で "PermitEmptyPasswords no" を指定してください。 これでエラーは出なくなりますが、かわりにパスワードが設定されていない アカウントではログインできなくなります。OpenSSH に付属の sshd_config を使っている場合、これはデフォルトになっています。
PAM つきで作成した OpenSSH のバージョンで、空のパスワードを 許可するには、/etc/pam.d/sshd ファイルにある パスワード検査モジュールの最後に nullok フラグを追加する 必要があります。たとえば:
auth required/lib/security/pam_unix.so shadow nodelay nullok
これに加えて、sshd_config ファイルで "PermitEmptyPasswords yes" を指定しておかなければいけません。
PAM 認証で空のパスワードを使うときに、ひとつ注意しておくことが あります: パスワードが空の場合、PAM は どんな パスワードでも 認証を通してしまいます。これは、 sshd(8) がこのアカウントに パスワード設定がついているかどうか調べるチェックを突破してしまい、 PermitEmptyPasswords で指定されているポリシーにかかわらず そのアカウントにアクセスしてきたユーザすべてを通してしまうことになります。 このため、PAM の設定ファイルに nullok 指令をつけ加えるのは、 空のパスワードを通したいという特別な理由がないかぎりやめたほうがよいでしょう。
ひじょうに長い遅延 (10秒以上) はふつうホストの名前解決によって ひきおこされます:
nslookup コマンドを使って、お互いの名前と IP アドレスを
検索してみてください。さらに、クライアントの IP 名検索で返された名前をサーバ側で検索します。
sshd_config 設定ファイルに UseDNS no を加えることで
ほとんどのサーバ側の DNS 検索を抑えることができます。
10秒よりも短い遅延はそれ以外の問題がある場合があります。
ssh に
欠陥があり、本来意図したよりも大きなモジュロを要求するようになっていました
(これが上の問題と合わさったときに極端な速度低下をもたらします)。
クライアントのバージョンを 3.8 あるいはそれ以上にアップグレードすれば、
この問題は解決します。ssh-rand-helper によって呼ばれるエントロピー生成プログラムのひとつが
ハングしてしまう場合があります。これは ssh-rand-helper を
デバッグモードで走らせることによって調べることができます:
極端な遅延は調査して修正するか、あるいは 遅いコマンドを ssh_prng_cmds から削除する必要があります。
/usr/local/libexec/ssh-rand-helper -vvv
通常の環境では、SSH のログイン速度はクライアントとサーバの CPU 速度に
依存します。比較対象として、以下に 「time ssh localhost true」
を実行したときの典型的な接続時間をのせておきます。鍵は 1024ビットの
RSA 鍵で、とくにそれ以外に負荷のかかっていないホストで実行したものです。
OpenSSH および OpenSSL は gcc 3.3.x でコンパイルしてあります。
| CPU | 時間 (SSHv1)[1] | 時間 (SSHv2) |
|---|---|---|
| 170MHz SPARC/sun4m | 0.74 秒 | 1.25 秒 |
| 236MHz HPPA/8200[2] | 0.44 秒 | 0.79 秒 |
| 375MHz PowerPC/604e | 0.38 秒 | 0.51 秒 |
| 933MHz VIA Ezra | 0.34 秒 | 0.44 秒 |
| 2.1GHz Athlon XP 2600+ | 0.14 秒 | 0.22 秒 |
Linux カーネルは (modprobe を介して) プロトコルファミリー 10 (IPv6) を使うモジュールを検索します。 適切なカーネルモジュールを読み込むか、 /etc/modules.conf に 正しい alias を入力するか、あるいは /etc/modules.conf で IPv6 を禁止するかのいずれかを行ってください。
いくつかのおバカな理由により、 /etc/modules.conf は /etc/conf.modules という名前になっていることもあり得ます。
パスワードを正しく入力したのにログインが拒否される場合、 よくあるケースは、お使いのシステムが MD5 形式のパスワードを使うよう 設定されているのにもかかわらず、sshd の使っている crypt(3) 関数が それを理解できていないというものです。
このような場合に影響を受けるアカウントは、/etc/passwd あるいは /etc/shadow 中のパスワード文字列が $1$ で始まっています。 古くからあるアカウントではパスワード認証に成功するのに、 新しく作成したアカウント、または最近できたアカウントでは失敗するという ケースでしたら、おそらくこれが犯人でしょう。
これが起こる要因は、あるバージョンの OpenSSL にある crypt(3) 関数が md5 パスワードを理解できておらず、さらに sshd をリンクする際の順序により OpenSSL の crypt(3) がシステムの crypt(3) よりも優先されて使われるためです。 OpensSSH の configure はこの順序を正しくしようとしますが、これがつねに 成功するとは限りません。
とりうる解決策はいくつかあります:
sshd をビルドする際、MD5 パスワードのサポートをビルトインする。
./configure --with-md5-passwords [オプション]
この方法では sshd がそれぞれのアカウントに対して正しいアルゴリズムを 自動的に選ぶので、パスワードが両方のタイプで暗号化されているときでも安全です。
お使いのシステムに個別の libcrypt ライブラリがある場合 (Slackware 7 など) は、 LIBS のリストに -lcrypt を 手動で追加することでこちらが OpenSSL の関数のかわりに 使われます:
LIBS=-lcrypt ./configure [オプション]
お使いのシステムが PAM をサポートしている場合、sshd にそれを使わせることも できます (3.15 節 を参照)。こうするとパスワードは sshd 自身が 検証するのではなく、あらかじめ設定された PAM モジュールに検証が委ねられることになります。
OpenSSL が内部で、あるいは RSAref 経由で RSA あるいは DSA を サポートした状態で作成されていることを確認してください。
scp(1) は、クライアント側、サーバ側の両方でデフォルトの PATH に含まれている 必要があります。場合によっては、(Configure 時に) --with-default-path オプションを使ってサーバが scp を探す カスタムパスを指定する必要があるかもしれません。 このオプションはデフォルトのパスを置き換えるので、scp が インストールされるディレクトリも含めて、現在のすべての パスを指定する必要があります。たとえば:
$ ./configure --with-default-path=/bin:/usr/bin:/usr/local/bin:/path/to/scp
注意: サーバ側の管理者による設定は、--with-default-path オプションの設定よりも 優先されます。これは /etc/profile で設定されている PATH を無効にし、 AIX における /etc/environment の PATH や、 (3.7p1 以上のバージョンでは) Solaris または Reliant Unix における /etc/default/login での PATH も含みます。
オペレーティングシステムによっては、/dev/tty が不適切な モードに設定されています。このためパスワードの読み取りが失敗し、 以下のようなエラーが出ることがあります:
You have no controlling tty. Cannot read passphrase.
(制御できる tty がありません。パスフレーズが読み取れません。)
これに対する解決法は、まず /dev/tty のパーミッションを 0666 に 設定しなおして、つぎにお使いの OS ベンダーにこのエラーをバグとして 報告することです。
ダウンロードした tar.gz ファイル中に「configure」ファイルがなかったり、 あるいは "missing separator" エラーが出て make できなかったりした 場合は、おそらく OpenBSD 用の OpenSSH を別のプラットフォーム上で コンパイルしようとしたためでしょう。そのような場合は、 移植版 リリース の情報を見てください。
OpenSSH では、終了時に固まってしまうことがあります。 これはバックグラウンドでアクティブなプロセスが走っているときに 起こることがあり、今のところ Linux と HP-UX 上で発生することが 知られています。これが発生するかどうかは、次のコマンドを 実行させて確かめることができます:
このようなことが起こる場合は、次のようにして対処してください:
$ sleep 20 & exit
$ sleep 20 < /dev/null > /dev/null 2>&1 &
Bash ユーザなら、/etc/bashrc か ~/.bashrc のどちらかに つぎの一行 「shopt -s huponexit」を入れておくことで 問題を解決できます。それ以外の方はお使いのシェルのマニュアルを参照して、 アクティブなジョブが終了するときに HUP シグナルを発行するようなオプションを 設定してください。これ以外の回避方法については、 bug #52 を参照してください。
を実行したとき、ssh はハングする 必要があります。 なぜなら ssh は以下のことを待つ必要があるからです:
$ ssh host command
command がこれ以上入力を必要としないと確信できること。
command がこれ以上なにも出力しないと確信できること。
command が終了すること。
なぜなら sshd はその command の終了状態を
ssh に送らなければいけないからです。
一般的に X11 R6 を使っている X11 クライアントは、 このデフォルトの設定で動くはずです。HP を含むいくつかのベンダは X11 クライアントを R6 および R5 のライブラリとともに出荷しています。 なのでいくつかのクライアントは動くが、別のクライアントは 動かないといった事態が発生します。この現象は HP-UX 11.X で起こります。
3.8 リリースノート に記されている通り、
新しい ssh はデフォルトでは信頼されない X11 クッキーを使うようになりました。
以前のふるまいに戻したい場合は、ssh_config 設定ファイルで
ForwardX11Trusted yes を設定してください。
具体的に起こる現象としては、以下のようなものがあります:
BadWindow (invalid Window parameter)
BadAccess (attempt to access private resource denied)
X Error of failed request: BadAtom (invalid Atom parameter)
Major opcode of failed request: 20 (X_GetProperty)
典型的な原因は、$HOME, $HOME/.ssh または $HOME/.ssh/authorized_keys が、 sshd がデフォルトで許可するよりもゆるいパーミッションで置かれていることです。
このような場合は、サーバ側でつぎのようなコマンドを実行してください。
$ chmod go-w $HOME $HOME/.ssh
$ chmod 600 $HOME/.ssh/authorized_keys
何らかの事情でこれが不可能な場合は、代替措置として sshd_config で StrictModes no に設定するという方法があります。 しかし、これはおすすめできません。
PAM を使う場合、最低限このオプションはビルド時に指定する必要があります。 PAM が組み込まれた場合の実行時のふるまいは 移植版 OpenSSH のバージョンによって 違います。新しいバージョンの場合は sshd_config で UsePAM を yes に設定しておく必要があります。
./configure --with-pam [オプション]
PAM を使っている場合、妥当な認証を選ぶ方法については以下の表を見てください。
| バージョン | UsePAM の値 | PasswordAuthentication | ChallengeResponseAuthentication |
|---|---|---|---|
| <=3.6.1p2 | 存在せず | PAM を使う | PAMAuthenticationViaKbdInt が許可されていれば PAM を使う |
| 3.7p1 〜 3.7.1p1 | デフォルトは yes | PAM を使わない | UsePAM が許可されていれば PAM を使う |
| 3.7.1p2 - 3.8.1p1 | デフォルトは no | PAM を使わない [1] | UsePAM が許可されていれば PAM を使う |
| 3.9p1 | デフォルトは no | UsePAM が許可されていれば PAM を使う | UsePAM が許可されていれば PAM を使う |
[1] いくつかのベンダ、とりわけ Redhat/Fedora では、3.9p1 の PasswordAuthentication 部分をベンダが提供している 3.8x ベースのパッケージに バックポートしています。これらのベンダが提供しているパッケージを お使いの場合は、ベンダのドキュメントを参照してください。
移植版 OpenSSH PAM インターフェイスには、まだいくつかのモジュールで問題があります。 問題の数は将来にわたって減少することを期待してはいますが。3.9p1 リリースの時点で 判明している問題は以下のとおりです:
AIX 4.3.3 と AIX 5.x とでは wtmp 構造体の形式が変わっています。 このため AIX 4.x でビルドされた sshd のバイナリを AIX 5.x で実行すると、 wtmp エントリが正しく更新されません。これは単に sshd を AIX 5.x システムで 再コンパイルすることにより修正されます。
www@openbsd.org