Q&A
.sshにauthorized_keysとid_rsaを入れているのにパスワードを要求されるのは、.sshを認識していないからではないということですか？
sshの時に毎回パスワードを要求されるので、新たにid_rsaやauthorized_keysを置きたいと思っています。
ネットで検索すると、接続先の~/.ssh/にそれらのファイルを置けば良いみたいなのですが、
この~/がマウントされた場所にあるため、どこに置いたらいいかわかりません。
sshで外部サーバーAに接続し、そこからさらにもう一度sshで別のサーバーBに飛んでいます。
sshでAからBに飛んだ時、AのホームディレクトリがそのままBのホームディレクトリになっています。
つまり、最初にAにsshするときに使用する.sshがそのままBでも残ってしまっています。
このような場合、.sshはどこに置くべきなのでしょうか？
（すみません、本当にマウントされているかどうかはよくわからないです。ただ、AからBにsshすると強制的にAのホームディレクトリに飛ばされるということです）
回答2件
0
ちょっと質問文を読んで混乱したのですが、
要は、同一ディスクスペース上で複数の鍵を運用するにはどうすればいいかという話だと理解していいのでしょうか。
authorized_keysは実態はテキストファイルで、鍵情報はふつうに改行して追記していけば良いです。
秘密鍵は適当にリネームしておけばいいでしょう。たとえばid_rsa-local2A id_rsa-A2Bみたいにしておけば混乱なく併存可能です。
Aへのログインの際はssh -i ~/.ssh/id_rsa-local2A ...、
AからBへログインするときはA上でssh -i ~/.ssh/id_rsa-A2B ...という感じで。
投稿2018/09/21 10:26
総合スコア13671
0
ベストアンサー
そのような環境であれば、.sshは共有することになりますね。
mountされているということは、そのように使うことを想定されているはずです。
投稿2018/09/21 10:10
総合スコア1167
パスフレーズではなくパスワードが要求されるのでしょうか？
公開鍵認証によるsshログインでも秘密鍵がパスフレーズ付きであれば、パスフレーズは原則毎回要求されますよ。
server-name's password:
と表示されます。
秘密鍵のid_rsaはパスフレーズ無しで設定しているので、
おかしいですね・・・。
なるほど。それはパスワードを聞かれていますね。
とすると、.sshが認識されていない可能性もありますが、それ以外にもいろいろと可能性があります。
鍵が不正だったり、owner やパーミッションが不正だったり、場合によってはＢの sshd の設定も関係してくるかもしれません。
Ｂのサーバにはパスワードを入れればログインは可能なのでしょうか？
もし可能であれば、Bのサーバ内の /var/log/secure 等でBのサーバにsshログインした際のログを確認してみることをおすすめします。
おじゃまします。
念のため確認ですが、
ファイルのパーミッションは600になっていますよね？
AサーバにいるときとBサーバにいるときは自分のuidは同じですよね？
uidをコマンドidによって調べたところ、一緒でした。id_rsaとauthorized_keysはchmod 600をしています。
/var/log/secureというファイルはなかったです。
/var/log/ないのファイルは権限がないようでcatしても表示できませんでした。
id_rsa は 400 にしてください。
Ａで ssh を実行する際に何かメッセージが出ないですか？
/var/log が見れないということは、Ｂサーバではroot権限にはなれないのですかね？
すみません。id_rsaが400でないといけないのは環境によるようです。
もう１つあり得るとすればユーザー名ですが、ユーザー名はすべてのマシンで同一ですか？
id_rsaを400にしてもダメでした。
whoamiで調べたところ、ユーザー名はサーバーA, サーバーB間で同じでした。
自分はAサーバーでもBサーバーでもroot権限にはなれないです。
AからBにsshするときは特にメッセージはでないです。(server-name's password:を除く）
-vをつけて実行すると次のログが得られました。
OpenSSH_6.0p1 Debian-4+deb7u7, OpenSSL 1.0.1t 3 May 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to <server-name> [<server-address>] port 22.
debug1: Connection established.
debug1: identity file /home/<my name>/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/<my-name>/.ssh/id_rsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.10
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.10 pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u7
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: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA b0:54:48:4c:9a:e9:4b:48:f3:73:55:c1:78:41:d2:fd
debug1: Host '<host-name>' is known and matches the ECDSA host key.
debug1: Found key in /home/<my-name>/.ssh/known_hosts:1
debug1: ssh_ecdsa_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_1099' not found
debug1: Unspecified GSS failure. Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1099' 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_1099' not found
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/<my-name>/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: password
Offering RSA public keyというのが気になったので少し調べてみたら、こんな情報が出てきました。
http://blog.yuryu.jp/2014/01/ssh-auth-fails-with-different-public-key.html
どうでしょう？
すみません、質問の本題とかなり外れてきた感じがするので、質問自体は解決済みにしました。
記載されたリンクに従って.ssh内の*.pubを削除したところ、Offerfing RSA public.keyというのはなくなりました。
ただまだパスワードは要求されます・・・。-vvvで実行したところ
ログは次のようになりました。
(publickeyのところだけ抜粋）
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/<my name>/.ssh/id_rsa
debug1: read PEM private key done: type RSA
debug3: sign_and_send_pubkey: RSA c7:8b:10:20:8b:59:25:55:8b:21:3e:8d:8e:b6:db:88
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
うーん、クライアントのログとしては普通ですね。
サーバ側のログが見れないとピンポイントでは判断できなさそうです。
整理すると、
・サーバＡへは鍵認証でログインできている
・サーバＡログイン時に使用した id_rsa をサーバＡの ~/.ssh/id_rsaとして置いている
・サーバＡの .ssh, authorized_keys, id_rsa の ownerとパーミッションは問題ない
・サーバＢでは home ディレクトリがサーバＡと同一。ユーザー名、uidも同じ
であれば、普通に鍵認証が有効になるはずだと思うんですけどね。。。
すみません。これ以上はわからないです。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2018/09/21 10:36
2018/09/21 11:21