おやじ様 ご無沙汰しております。たかしです。
おやじ様はSSHは使用されていないようなので
ここで質問すべきかどうかためらったのですが
（適切な質問でない場合は無視してください）
windowsOSから公開鍵暗号基盤を使った認証方法（PKC認証）
が失敗します。
詳細を説明すると、CentOS4.4標準のsshdを使用しており
ssh-keygenコマンドを使って
RSA1024ビットの鍵対を生成して、秘密鍵をコンソール端末
にエクスポートしました。公開鍵については
ホスト側で.ssh配下のauthorized_keyに含めました。
コンソール端末から、UTF8対応の最新TeraTermを使って
秘密鍵を指定してログインを試みると、失敗してしまいます。
ログを確認すると以下のエラーがでているので、
authorized_keyのパーミッション設定を見直したのですが
ちょっと原因がわからず困っています。
Authentication refused: bad ownership or modes for file /home/xxxxxx/.ssh/authorized_key
どなたか、同じ症状を体験した方おられます？
> おやじ様 ご無沙汰しております。たかしです。
こん○○は。
> おやじ様はSSHは使用されていないようなので
> ここで質問すべきかどうかためらったのですが
> （適切な質問でない場合は無視してください）
> windowsOSから公開鍵暗号基盤を使った認証方法（PKC認証）
> が失敗します。
いえいえ、全体把握をしたいときはGUIのほうが早いので適宜使い分けていますが、普通はteratermを使用してますよ。
> 詳細を説明すると、CentOS4.4標準のsshdを使用しており
> ssh-keygenコマンドを使って
> RSA1024ビットの鍵対を生成して、秘密鍵をコンソール端末
> にエクスポートしました。公開鍵については
> ホスト側で.ssh配下のauthorized_keyに含めました。
>
> コンソール端末から、UTF8対応の最新TeraTermを使って
> 秘密鍵を指定してログインを試みると、失敗してしまいます。
> ログを確認すると以下のエラーがでているので、
> authorized_keyのパーミッション設定を見直したのですが
> ちょっと原因がわからず困っています。
>
> Authentication refused: bad ownership or modes for file /home/xxxxxx/.ssh/authorized_key
32ビットWindowsのVMware上のCentOS4.4の環境では、デフォルトのsshd_configのまま、パーミションは600で何もエラーは発生しませんね。SuSE9.3/10.1でも同様ですし、644でも良いかは別としてOKです。
おやじは、このエラーは経験がないのでわかりませんが、想像ですがrootで鍵を作ったりしてません？ パーミッションというより、オーナがおかしいのでは？
> 32ビットWindowsのVMware上のCentOS4.4の環境では、デフォルトのsshd_configのまま、パーミションは600で何もエラーは発生しませんね。SuSE9.3/10.1でも同様ですし、644でも良いかは別としてOKです。
ウチでは644でした。600に変更しましたが。
> おやじは、このエラーは経験がないのでわかりませんが、想像ですがrootで鍵を作ったりしてません？ パーミッションというより、オーナがおかしいのでは？
ということで試してみました。
sshd_configでLogLevelをDEBUGに設定してsshdをrestart。
authorized_keysのオーナーをrootにしてPoderosaで公開鍵認証を実施。
/var/log/secureには以下のようなログが残りました。
Nov 8 01:07:49 server sshd[6731]: debug1: temporarily_use_uid: 500/500 (e=0/0)
Nov 8 01:07:49 server sshd[6731]: debug1: trying public key file /home/setoppu/.ssh/authorized_keys
Nov 8 01:07:49 server sshd[6731]: debug1: restore_uid: 0/0
Nov 7 11:07:49 server sshd[6734]: Failed publickey for setoppu from 192.168.1.2 port 2030 ssh2
ということで、こんなログが残っていたらオーナーが正しくないと思われます。
# Failed行がヘンな時間になっているのはご愛敬？
ご返答ありがとうございます。
> ウチでは644でした。600に変更しましたが。
私も644にしています。おそらくパーミッションは
問題ないかと。。。
ちなみに、このパーミッションはリモートホスト上の
公開鍵ファイルのパーミッションですよね？
>
> > おやじは、このエラーは経験がないのでわかりませんが、想像ですがrootで鍵を作ったりしてません？ パーミッションというより、オーナがおかしいのでは？
ここに関しては、確実にteraterm使用ユーザで鍵を作成しました。
鍵作成後に、ls -la コマンドでオーナー確認を行っても
teraterm使用ユーザ名になっていたので問題ないかと思います。
>
> ということで試してみました。
> sshd_configでLogLevelをDEBUGに設定してsshdをrestart。
> authorized_keysのオーナーをrootにしてPoderosaで公開鍵認証を実施。
> /var/log/secureには以下のようなログが残りました。
>
> Nov 8 01:07:49 server sshd[6731]: debug1: temporarily_use_uid: 500/500 (e=0/0)
> Nov 8 01:07:49 server sshd[6731]: debug1: trying public key file /home/setoppu/.ssh/authorized_keys
> Nov 8 01:07:49 server sshd[6731]: debug1: restore_uid: 0/0
> Nov 7 11:07:49 server sshd[6734]: Failed publickey for setoppu from 192.168.1.2 port 2030 ssh2
>
> ということで、こんなログが残っていたらオーナーが正しくないと思われます。
>
>
ありがとうございます。おそらくオーナーの問題ではないと
思われますが、DEBUGモードのログでもう一度確認してみます。
確認までに、Teratermの方に特殊な設定が必要 ということは
特にないですよね？
> > ウチでは644でした。600に変更しましたが。
>
> 私も644にしています。おそらくパーミッションは
> 問題ないかと。。。
> ちなみに、このパーミッションはリモートホスト上の
> 公開鍵ファイルのパーミッションですよね？
エラーは、現在でも当初の下記のとおりなのですよね。
Authentication refused: bad ownership or modes for file /home/xxxxxx/.ssh/authorized_key
であれば、原因がわかりました。原因は、パーミッションの設定ミスです。
上記のとおりなら、authorized_keyのgroupとotherのどちらかか両方が書き込み可になっているはずです。
$ ls -al /home/xxxxxx/.ssh/authorized_key
で見てみてください。
後、同様に ~/ 以下で、groupとotherの書込みが可になっていると駄目です。
通常、デフォルトではそうはならないので何かの都合で変更したのだと思いますが、動かしたいなら、下記でw属性を落としてください。普通はいらないはずなので支障はないはずです。
$ chmod go-w ~/
$ chmod -R go-w ~/.ssh
これで駄目なら、何かおかしいです。
PKCログインが可能になりました！
本当にありがとうございます！
>
> $ ls -al /home/xxxxxx/.ssh/authorized_key
>
> で見てみてください。
> 後、同様に ~/ 以下で、groupとotherの書込みが可になっていると駄目です。
>
過去に都合で chmod -R 665 xxxx ~
とコマンドをうっていたのでパーミッションが変化していた
ようでした。（見落としていました。。。。。）
groupとotherが書き込みのパーミッションをもっていると
ブロックされるのは、やはりSSHのセキュリティ上の問題なのでしょうか？
とりあえず、助かりました。
本当にありがとうございます。