サーバA→Bにたいして、ユーザhoge(サーバBのユーザ)でSSH接続は可能ですが、鍵運用が上手くいきません。
※常にhoge@サーバBのパスワードを聞かれてしまう状態です。
hoge@サーバBの ~/.ssh/authorized_keys 内にサーバAの公開鍵を仕込みました。
公開鍵は、foo@サーバAの~/.ssh/id_rsa.pub です。
考えられる原因は何がありますか?
authorized_keysに書いてあるホスト名と、サーバAでIPアドレスからDNSを逆引きして得られるホスト名が異なるのが原因ではないでしょうか。
ホスト名の部分を、
など変えてみるといいかもしれません。
また、同じファイルのユーザ名の部分は(Aではなく)Bでのユーザ名を書く必要があります。
サーバのバージョンによってはauthorized_keysではなくauthorized_keys2というファイルを用いる場合もあります。
authorized_keyのパーミッションも確認してください。
http://www.openssh.com/ja/faq.html#3.14
サーバーBの authorized_keys のパーミッションを確認してみてください。
所有ユーザー以外に wがついてると公開鍵認証してくれません。
所有ユーザーのみに、rw権限がついてるのが好ましいです。
chmod 600 ~/.ssh/authorized_keys とやってみてください。
駄目なのであれば、
/etc/sshd/sshd_config(環境によって場所は変わります。)
で公開鍵認証が有効になっているかどうか
確認してみてください。
ご回答ありがとうございます。
1番目の方への返信にも書きましたが、authorized_keysは、オーナーがrootでパーミッション644だったので、hogeの600に変更しましたが、やはりNGでした。
以下(RHES4.0)を確認しました。鍵認証有効ということだと解釈しています。
/etc/ssh/ssh_config
Host *
GSSAPIAuthentication yes
ちなみに上手くいっている CサーバもRHES4.0ですし、いずれもSSH2で接続しています。
GSSAPIはたぶんKerberos用であって、SSHのRSA認証とは別物です。ここはまず、サーバBの /etc/ssh/sshd_config をそのままコピペしてここに提示されたらどうですか。
http://www.faqs.org/faqs/kerberos-faq/general/section-84.html
> サーバBの /etc/ssh/sshd_config をそのままコピペして
以下のみですが、これは上手くいっているサーバCと同じ(デフォルト)です。
Host *
GSSAPIAuthentication yes
ForwardX11Trusted yes
http://www.unixuser.org/~euske/doc/openssh/jman/sshd.html
プロトコル バージョン 2 の公開
鍵では、以下の項目が格納されています: オプション、鍵の種類、 base64エンコ
ードされた鍵本体、鍵のコメント。オプション項目はなくてもかまいません。
ということで、authorized_keysの行末の部分はコメントなので何を書いていても意味はありません。
チェックポイントとしては、
という感じでどうでしょうか?
> ssh -vでわからなければssh -vvやssh -vvvなどと
すごいですね。デバッグレベル3まで表示できるとは。
以下問題の箇所になります。
http://ccs.cla.kobe-u.ac.jp/98/maru/WWW/soturon/s3.htm
を参考に、サーバAにて DSA の鍵生成し、hoge@サーバB に
~/.ssh/authorized_keys2
で保存して試しましたが、NGでした。
どうもRSAだけでなくDSAの鍵が必要なため、認証できずにパスワード要求に
なっているということですね。
RSAは、上手く接続できるサーバCでも使用しているものですが、パスフレーズが
不明(作成担当者マター)です。パスフレーズは今回作成したDSAと一致しないと
まずいのでしょうか?
それと以下では、「no such identity: /home/foo/.ssh/identity」のため、
すでに作成済みのRSA(秘密鍵)、今回作成のDSA(秘密鍵)をそれぞれコピーして
みましたが、パスワード要求は変化せずでした。
少し状況が混沌としてきました。デバッグメッセージからの類推はこのような
感じですが、その対処に行き着けない状況です。
debug1: next auth method to try is publickey
debug1: userauth_pubkey_agent: testing agent key /home/foo/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: authentications that can continue: publickey,gssapi-with-mic,password
debug3: clear_auth_state: key_free 0x8090088
debug2: userauth_pubkey_agent: no more keys
debug2: userauth_pubkey_agent: no message sent
debug1: try privkey: /home/foo/.ssh/identity
debug3: no such identity: /home/foo/.ssh/identity
debug1: try pubkey: /home/foo/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: authentications that can continue: publickey,gssapi-with-mic,password
debug2: userauth_pubkey_agent: no more keys
debug2: userauth_pubkey_agent: no message sent
debug1: try pubkey: /home/foo/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: authentications that can continue: publickey,gssapi-with-mic,password
debug2: userauth_pubkey_agent: no more keys
debug2: userauth_pubkey_agent: no message sent
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: next auth method to try is password
$HOME, $HOME/.ssh のパーミッション、オーナーも変更しましたか?
コレで駄目だとすると、
パスフレーズを入力してしまっていた。ということしか思いつきません。。
だいたい以下のような手順だったと思うのですが、
どうでしょうか。
実は、会社で ES4.0 を使っていて
デフォルトの設定で公開鍵認証が使えるのは確認してます。
# パスフレーズを求められるが入力しない。 foo@serverA$ ssh-keygen -t rsa # 公開鍵をserverBにコピーする # サンプルなので、上書きしちゃってます。 foo@serverA$ scp ./.ssh/id_rsa.pub hoge@serverB:./.ssh/authorized_keys # ログインして、パーミッションの変更 foo@serverA$ ssh hoge@serverB hoge@serverB$ chown -R hoge ./.ssh hoge@serverB$ chmod 600 ./.ssh/*
DSAのパスフレーズは省略していますが、作成済みのRSAについては
不明な状況です。
そのほかの指摘箇所は、クリアしているはずです。
回答がずれていたらすみません。
よく読んでみるとDSA鍵を作られたのですよね?
でしたら、
~/.ssh/id_rsa.pub
ではなく
~/.ssh/id_dsa.pub
にしないといけないのではないでしょうか?
ご回答ありがとうございます。
ホスト名、FQDN、IPともに上手くいっているサーバCと同じ書き方で、原則サーバ設定は(BとCは)ニアリーイコールです。
このほか、以下も確認しましたがNGでした。
何か初歩的なところでミスっているような気はしています。
①Bでのユーザ名
サーバBのauthorized_keysの中にはfoo@サーバAで書かれています。
指摘が間違っているか私の解釈に誤りがありそうです。
②パーミッション
セキュリティがゆるすぎるとNGを調べましたが、問題なし(644ですがAから上手くいっているCサーバも同様)
③authorized_keys2
試しましたが、変化せず