ssh接続におけるPermission denied (publickey,gssapi-keyex,gssapi-with-mic). で見落としていたこと。

ssh接続でPermission deniedがでた時は、よくパーミッションの問題か、クライアント側の鍵とサーバ側のauthorized_keysが一致していないことが多いとされています。

しかし、自分の場合パーミッションが適切に設定されており、authorized_keysの内容も問題ありませんでした。

% ssh -p 10022 -i id_dsa.pub <username>@192.168.56.102
<username>@192.168.56.102: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

今回は試したことや見落としていた点について述べていきます。

/var/log/secureを確認する

/var/log/secureとは、認証やセキュリティ関連のあらゆるログが記録されているファイルです。

ssh接続に失敗したら、接続先のコンピュータにて/var/log/secureを確認します。

lessコマンドで開いた後、/sshdで検索をし、ログを見つけ出します。手がかりがここから得られるそうですが、自分の場合だと

この情報しか得られず、、、

sshコマンドに-vvvオプションをつけて実行する

sshコマンドの-vオプションを使うことによってクライアント側でデバッグメッセージを見ることができます。また、vの数が多くなるにつれて、詳細に表示されます。

今回の自分の場合、このように表示されました。(一部省略)

debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Next authentication method: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
<username>@192.168.56.102: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

上から3行目のwe did not send a packet……が重要かと思い、ググって情報収集。

するとどの記事もauthorized_keysに正しく鍵が登録されていない原因によるものでした。(接続元の鍵の値と接続先の鍵の値が異なっているなど)

参考: we did not send a packet, disable method | あらぶるトラブル

参考: SSHでPermission deniedが解決しないと思ったらauthorized_keysに”\n”が紛れ込んでいた – Qiita

一応確認してみることにします。

% ssh-keygen -lf id_dsa.pub

-lオプションはフィンガープリント(識別用の値)を表示、-fは鍵ファイルを指定しています。このコマンドで得られたフィンガープリントと、接続先で以下のコマンドを実行した値を比べてみます。

% cat ~/.ssh/authorized_keys

するとやはり同じ値で問題ありませんでした。さらに謎は深まります。

パーミッションを確認する

ssh接続が失敗する原因として一番多いのがパーミッション設定ミスみたいですね。。

参考:sshの公開鍵認証がうまく行われない時の原因3個とその対処法

まずは接続先の~/.sshと~/.ssh/authorized_keysのパーミッションから確認してみます。

~/.ssh —–> 700(drwx——)

~/.ssh/authorized_keys ——> 600(-rw——-)

無事大丈夫そうです。ちなみにここが所有者以外も書き込み可能(w)だと,

Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys

と先ほどの/var/log/secureに表示されて弾かれるようです。

参考: SSH で Permission Denied となる傾向と対策 -Qitta

RSA鍵ではSSH接続することができる

ここまで試してきても原因がわからなかったため、そもそも鍵の問題ではないか?と思い、RSAで鍵を作成してみると、無事に接続できました。

ここでDSAが使えないようになっているのではないか?と思いググります。

DSAは非推奨でデフォルトでは使えない

やっとここで答えにたどり着きました。

DSAは1994年に登場した暗号で、RSAと同じくライブラリは充実しているとのこと。しかし、DSAのセキュリティは完全ではありません。DSAでは乱数mを鍵生成において使い捨てで使用するナンス値として使用しますが、DSAではこのmを秘匿する必要があるため、使い捨てであるはずのナンス値が性質上は鍵と近いものになるとのこと。かつ、完全な乱数を生成することは難しく、プログラムの実装ミスで一定の法則を持った値をmとして使用してしまうこともあるため、mの解析を通して暗号を突破されてしまうこともあります。このためDSAはOpenSSH 7.0からはデフォルトで無効化されています

SSHの公開鍵暗号には「RSA」「DSA」「ECDSA」「EdDSA」のどれを使えばよいのか?

引用元: SSHの公開鍵暗号には「RSA」「DSA」「ECDSA」「EdDSA」のどれを使えばよいのか?

どうやら、openssh7.0からDSAがデフォルトで使用できないようになっていたようです。

非推奨であることはわかっていたんですが、デフォルトで無効にされているとは、、。

まとめ

非推奨だから使うなってことなんですが、興味本位で使ってハマり、原因解析に時間を浪費したわけです。

しかし、エラーを分析する手順や方法を色々と試せたのはいい勉強になりました。

わざわざDSA鍵でssh接続するしようとする人はいないかもしれませんが、参考になれば幸いです。

Comments

Copied title and URL