質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

88.60%

公開鍵を使ったSSH接続で自分自身に接続するとパスワードを求められてしまう

解決済

回答 3

投稿 編集

  • 評価
  • クリップ 0
  • VIEW 6,176

310uk

score 12

 前提・実現したいこと

現在RHEL6.5で稼働しているWebアプリケーションのログを、Webサーバから他のサーバにSSHでファイル転送しています。
その動きの中で、(仕様の良し悪しは置いといて)自分自身にもSSHで繋いでファイル転送しています。
cronでバッチ(*.sh)を動かしているため、鍵交換方式でパスワード不要で接続できるようにしています。
※現在正常稼働中です

そのアプリケーションの検証環境を構築しようとしており、そちらはCentOS6.5を使っています。

稼働環境と検証環境の差異は、以下の通りです。

  • OS
    稼働環境⇒RHEL6.5
    検証環境⇒CentOS6.5
  • サーバ構成
    稼働環境⇒Webサーバ、DBサーバ、BKサーバが、それぞれオンプレサーバで稼働
    検証環境⇒Webサーバ、DBサーバ、BKサーバを1台のオンプレサーバで稼働
  • OpenSSHバージョン
    両環境共⇒OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013

 発生している問題

次に書くコマンドを実行して、鍵の生成と、自分自身への公開鍵の転送を行いましたが、SSH接続時にパスワードを求められてしまいます。

 実行したコマンド

#sh実行ユーザに切り替え
su - hoge

#鍵生成
#途中のプロンプトは全て空のままEnter
ssh-keygen -t rsa

#鍵を転送
ssh-copy-id -i /var/hoge/.ssh/id_rsa.pub hoge@localhost

#繋ぐとパスワードが求められてしまう
ssh hoge@localhost

 試したこと

  • ssh-copy-idコマンドで転送するサーバの指定とsshコマンドの接続先を、localhost以外に以下の3つも試しましたが変わりませんでした。
    ・127.0.0.1
    ・hostsに書いたホスト名
    ・ネットワーク上のIPアドレス
  • /var/hoge/.ssh/配下のauthorized_keysknown_hostsの各ファイルの内容を確認したところ、正しいと思える内容が追記されていました。
    ※4つのサーバ指定が全て記載されていた
  • ググっていたところ(teratail内にもありましたが)ホームディレクトリや.sshディレクトリおよび配下のファイルのアクセス権設定が不適切な可能性、という話が見つかったので、正常に動作している稼働環境のアクセス権と同一に設定し直しましたが、状況は変わりませんでした。
    ※補足情報参照
  • /etc/ssh/sshd_configの設定は、両環境共同一であることを確認済みです。
    PermitRootLoginを変更した以外はデフォルト
  • あえて/etc/ssh/sshd_configRSAAuthenticationPubkeyAuthenticationを有効にしてyesを指定してみましたが、ダメでした。
  • サーバの再起動もしました。変化ありません…

 補足情報

  • .sshディレクトリ配下の各ファイルのアクセス権は以下の通りです。
-rw------- 1 hoge hoge 3906 11月  9 10:32 2018 authorized_keys
-rw------- 1 hoge hoge 1675 11月  9 10:16 2018 id_rsa
-rw-r--r-- 1 hoge hoge  393 11月  9 10:16 2018 id_rsa.pub
-rw-r--r-- 1 hoge hoge 3537 11月  9 10:36 2017 known_hosts
  • /var/log/secureの出力内容は以下の通りです。
    鍵見に行ってない…
Nov  9 16:01:42 backup-t su: pam_unix(su-l:session): session opened for user hoge by root(uid=0)
Nov  9 16:01:54 backup-t sshd[3512]: Accepted password for hoge from ::1 port 40532 ssh2
Nov  9 16:01:54 backup-t sshd[3512]: pam_unix(sshd:session): session opened for user hoge by (uid=0)
Nov  9 16:01:57 backup-t sshd[3516]: Received disconnect from ::1: 11: disconnected by user
Nov  9 16:01:57 backup-t sshd[3512]: pam_unix(sshd:session): session closed for user hoge
Nov  9 16:01:59 backup-t su: pam_unix(su-l:session): session closed for user hoge
  • sshコマンドに-vスイッチを付けてデバッグモードで実行してみました。
    しかし何故パスワード認証に移行してしまうのかが分かりません…
[hoge@backup-t ~]$ ssh -v localhost
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to localhost [::1] port 22.
debug1: Connection established.
debug1: identity file /var/hoge/.ssh/identity type -1
debug1: identity file /var/hoge/.ssh/identity-cert type -1
debug1: identity file /var/hoge/.ssh/id_rsa type 1
debug1: identity file /var/hoge/.ssh/id_rsa-cert type -1
debug1: identity file /var/hoge/.ssh/id_dsa type -1
debug1: identity file /var/hoge/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'localhost' is known and matches the RSA host key.
debug1: Found key in /var/hoge/.ssh/known_hosts:2
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_500' not found

debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_500' not found

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_500' not found

debug1: Next authentication method: publickey
debug1: Trying private key: /var/hoge/.ssh/identity
debug1: Offering public key: /var/hoge/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /var/hoge/.ssh/id_dsa
debug1: Next authentication method: password

恐れ入りますが、どなたかお知恵をお貸しいただければと思います。
よろしくお願いいたします。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 過去に投稿した質問と同じ内容の質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 3

checkベストアンサー

+1

ssh hoge@localhost


をrootユーザで実行していませんか

この場合、鍵を作成したhogeではなく自分の鍵(/root/.ssh/id_rsa)を使おうとします。
そのため、鍵認証できない→パスワード認証に移行となっています。

hogeユーザでコマンドを実行する(この場合、ssh localhostでいいのですが)

[hoge@hostname ~]$ ssh hoge@localhost


または、使用する鍵を指定します

[root@hostname ~]# ssh -i /home/hoge/.ssh/id_rsa hoge@localhost

ssh接続のときのログは /var/log/secure に記録されますので、こちらも参考するとどんな挙動しているか確認できます

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2018/11/09 19:07

    私もそれぞれ/home/**、/var/**で実施して同事象を確認していますので手順には問題ないと思います

    キャンセル

  • 2018/11/09 19:08

    試しましたが駄目でした…

    キャンセル

  • 2018/11/12 15:00

    @yukky1201さま

    今日、検証環境の該当ユーザのホームディレクトリを以下のように修正したところ、問題なく接続できるようになりましたので報告いたします。

    usermod -d /home/hoge/ -m hoge

    最初から正確な情報を提示できていればもっと解決が早かったかもしれません、余計なことをしてしまいました。
    ご丁寧にご対応いただき、ありがとうございました。

    キャンセル

0

自分にアクセスするわけですから ssh_config (d なし) の設定も関係するってことはないでしょうか?

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2018/11/09 19:26

    確かにそうですね。
    今日は退社してしまって実環境がもう見れないので、来週稼働環境と検証環境の差異がないか確認してみます。

    キャンセル

  • 2018/11/12 14:40

    せっかくご回答いただいたのに確認に時間が掛かってしまい申し訳ありませんでした。

    成功しているRHELと上手く行かないCentOSとで、/etc/ssh/ssh_configの内容を比較したところ、後者には暗号化形式(Ciphers,MACs)の記載がなかったので追記しました。

    結果、変わりなく繋がりませんでした。(汗)

    キャンセル

0

完全に解決しました。
結論を言うと、本質的な問題はホームディレクトリではなく、ただ単にSELinuxが有効になっていたせいでした。汗

getenforceコマンドを実行するとenforcingが返ってきたので、/etc/selinux/configを編集してdisabledに設定変更し直し、再起動後に同じことを試したら、パスワードを聞かれることなく接続できるようになりました。

お騒がせ致しました!!!

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2018/11/13 10:40

    盲点でした。auditログにもauthorized_keysのread拒否のログが出てました。

    /home/~と/var/~を比べてみました
    下記にてコンテキスト変更するとSELinux有効のままでもパスワード聞かれることなく認証できます
    chcon -R unconfined_u:object_r:ssh_home_t:s0 .ssh/

    キャンセル

  • 2018/11/13 11:43

    こちらもauditログ確認してみたら、同様に出ていました。

    chconというコマンドは初めて知りました。サンプルのご提示ありがとうございました。
    今回のシステムはSELinuxを有効にしておく必要はなさそうですので、無効化で対応します。<(_ _)>

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 88.60%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

同じタグがついた質問を見る