公開鍵認証で入力しなかったパスワードを要求されるのをなくして接続したい

現状説明

raspberry pi 4 にubuntu server22.04をインストールして、update、upgrade、openssh-serverのインストールの作業をしました。また、raspberry pi imager の初期設定でパスワードでのssh接続の設定をし、teratermを使って接続できました(ラズパイ内のコードの実行は直接行い、ssh接続ではしていません)。
次に公開鍵認証での接続をしたいと思いサイトのリンク、サイトのステップ1、ステップ2の「公開鍵を手動でコピーする」の方法をとり、現在ステップ3でwindowsPCからpowershellでサイトに従いながら、進めてみたところパスワードを要求され、

$ssh-keygen  #powershellで実行

の際に↓のパスワードを入力したものだと考え入力したのですが、さらに↓のようになりました。ラズパイでのユーザーパスワードもダメでした。空白のままも同様。

#Output
Enter passphrase (empty for no passphrase):

permission denied, please try again.
コード

サイトのステップ３に

秘密の鍵にパスフレーズを入力しなかった場合、直ちにログインされます。鍵を作成したときに秘密の鍵にパスフレーズを入力した場合、直ぐに入力するように求められます（セキュリティのためにキーストロークは端末セッションには表示されません）

とあるので二回目として、ssh-keygenの際に要求されたパスワードを入力しない方法をとったのですが、前回同様、接続の際にパスワードを要求され、結果も一回目と同様でした。(空白、一回目のパスワード、ログインパスワード)
公開鍵はこれまでteratermでつくって転送する方法を試していたのですが、何度やってもできないので今回のようにpowershellでためしてみました。ご教授お願い致します。長文失礼しました。

・サイトのコードの入力場所

ステップ1はすべてpowershell(コマンドプロントはcatができませんでしたのでなし)
ステップ2は三つの手段のうち一番したの「公開鍵を手動でコピーする」を試し、白枠のコードをpowershell、黒枠をraspberry pi内でsshを使わずに直接実行しました。

修正

現在ステップ3でwindowsPCからpowershellでサイトに従いながら、進めてみたところパスワードを要求され、

#powershellで実行
$ssh [username]@[hostname]

#output
[username]@[hostname]'s password:
Permission denied, please try again

#3回間違えてしまう場合
[username]@[hostname]: Permission denied (publickey,password).
コード

quickquip

2022/07/08 14:35

> 現在ステップ3でwindowsPCからpowershellでサイトに従いながら、進めてみたところパスワードを要求され、ここの部分、自分で解釈するのはなく、どう表示されているかをそのままコピーするべきです。

gagagalu

2022/07/09 03:26

指摘ありがとうございます。直ぐに訂正させていただきます。

行動規範の内容に同意します

回答3件

plain
1[username]@[hostname]'s password:

がでているなら、鍵は使われずにスキップして、パスワード認証にチャレンジしている状態になっています。
秘密鍵のパスフレーズの問題ではありません。

鍵が正しく使われる時は、-v(verbose) オプションを使って、

shell
1ssh -v [username]@[hostname]

の結果をみると、

plain
1debug1: Will attempt key: /xxxx/some_user/.ssh/id_rsa RSA SHA256:xxxxxxx/xxxxxx/xxxxxx
2debug1: Will attempt key: /xxxx/some_user/.ssh/id_dsa
3debug1: Will attempt key: /xxxx/some_user/.ssh/id_ecdsa
4debug1: Will attempt key: /xxxx/some_user/.ssh/id_ecdsa_sk
5debug1: Will attempt key: /xxxx/some_user/.ssh/id_ed25519
6debug1: Will attempt key: /xxxx/some_user/.ssh/id_ed25519_sk
7debug1: Will attempt key: /xxxx/some_user/.ssh/id_xmss
8debug1: SSH2_MSG_EXT_INFO received
9debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
10debug1: SSH2_MSG_SERVICE_ACCEPT received
11debug1: Authentications that can continue: publickey,password,keyboard-interactive
12debug1: Next authentication method: publickey
13debug1: Offering public key: /xxxx/some_user/.ssh/id_rsa RSA SHA256:xxxxxxx/xxxxxx/xxxxxx
14debug1: Server accepts key: /xxxx/some_user/.ssh/id_rsa RSA SHA256:xxxxxxx/xxxxxx/xxxxxx
15Enter passphrase for key '/xxxx/some_user/.ssh/id_rsa':

みたいになるはずです。
（これは秘密鍵にパスフレーズがセットしてある例です。手許の秘密鍵の パスフレーズ(passphrase) の入力を促されています。質問に載せられている状況は サーバのパスワード(password) を問われています。まずこの違いを認識してください）

鍵は使われない理由は、ありとあらゆる可能性が、山ほど考えられます。
サーバアドレスが違う、アカウント名が違う、アカウントが有効でない、サーバ側公開鍵の置き場所が違う,ファイル名(authorized_keys)が違う,所有者が違う,パーミッションが適切でない、クライアント側秘密鍵の置き場所が違う,パーミッションが適切でない、etc,,,

何かを間違えたら起こる、としか言いようがありません。
質問者さんが"やったこと"を、誤解なく、曖昧なく、漏れなく、質問に載せない限り第三者には指摘は難しいです。
クライアント側 ssh -v の結果を見る、管理者権限があるならサーバ側のサービスのログを見る(/var/log/auth.logでしょうか)とかをするとヒントがあるかもしれません。

投稿2022/07/10 04:22

編集2022/07/10 12:51

quickquip

総合スコア11038