8
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

gitにsshで接続するぞ!→ Why? Permission Denied...

Last updated at Posted at 2019-08-23

はじめに

主な作業用PCが変わったきっかけで、そのPCからgitをssh接続できるように構築しようと思ったのです。
そこからいい感じにドハマりし、どうやってトラブルシューティングしたのか、その軌跡を綴っていきます。

ssh接続するぞ!ということで諸々準備

1. rsa鍵ペアの生成

まずは認証用の鍵ペアを作らないとね…ということで以下のコマンドで作成。(-tで鍵の種類を指定できます。今回はrsa暗号です。)
ファイル名を指定しないとid_rsaになっちゃうので、ファイル名を指定して作成しました。
(諸々細かい設定は飛ばしてます :bow: )

$ ssh-keygen -t rsa -f hoge_rsa

そうすると、~/.ssh以下にこんな感じで2つのファイルが生成されます。

$ ls ~/.ssh
hoge_rsa  hoge_rsa.pub 

2. .ssh/configの設定

次にssh接続する際に、どのホストに、どの鍵を使って接続する?等の設定内容を~/.ssh/configに記載してあげます。自分用に使いやすくカスタマイズするイメージですね。
(色んなサイトにssh接続する場合はこのconfigに記載してあげると便利です。)

~/.ssh/config
Host [ 接続するホスト名。ここを見てパターンマッチングする ]
  HostName       [ 実際に接続するホスト名 ]
  User           [ ログイン時のユーザ名 ]
  IdentityFile   [ 鍵までのPATH 例: ~/.ssh/hoge_rsa ]
  IdentitiesOnly [ ファイルに格納された鍵のみを使うか、yes/no で記載 ]

こんな感じで設定してみました。他にもポート番号とか指定できますので、是非このページを参考にしてみてください。

そしてこの設定を勘違いしていたことから、見事にドツボにハマることになるのです。。。

3. 作成した公開鍵をgitに登録

何はともあれ、鍵ペアができたので接続したいgitに公開鍵の方を登録してあげます。
公開鍵は先ほど作ったものだと~/.ssh/hoge_rsa.pubになるので、これの中身をコピーします。

あとは自分のgit環境にコピーした公開鍵を登録してあげれば準備完了です。

gitからcloneするとPermission Denied...何故?

セットアップができたのでいよいよcloneします!

$ git clone git@[gitのHostname]:[コンテンツ名].git
Cloning into '[コンテンツ名]'...
git@[gitのHostname]: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

…???
何でPermission denied??とりあえず何かしらの理由でアクセスできなさそうということでSSH接続周りを探っていきます。

トラブルシューティングまでの道のり

上記のエラー(Permission denied (publickey,gssapi-keyex,gssapi-with-mic))で調べると、先人達の知恵が沢山出てきます。ありがたや…!

それらのヒントを元に色々試してみます。

ディレクトリの権限付与の問題?

作成した鍵や、それを格納しているフォルダ等の権限が誤っている場合ですね。
.sshディレクトリは700、中のファイルは600に変更します。
(権限のリファレンスはこちら

$chmod 0700 ~/.ssh
$chmod 0600 ~/.ssh/config
$chmod -v 0600 ~/.ssh/hoge*

権限が変わってるかチェックしてみます。

$ ls ~/.ssh -l -al
total 8
drwx------ 0 user-name user-name  512 Jul 26 16:33 .
drwx------ 0 user-name user-name  512 Jul 26 16:33 ..
-rw------- 1 user-name user-name  146 Jul 26 16:33 config
-rw------- 1 user-name user-name 1679 Jul 16 17:20 hoge_rsa
-rw------- 1 user-name user-name  405 Jul 16 17:20 hoge_rsa.pub
-rw-r--r-- 1 user-name user-name  884 Jul 11 17:14 known_hosts

問題無さそうなので、さっそく再接続してみました!(ssh接続してみます。)

$ ssh git@[gitのHost名]
git@[gitのHost名]: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

何でじゃ…orz
権限云々はあまり関係無かったようでした。他のところも確認してみます。

サーバ側の問題?

もしやサーバ側(git環境)でssh接続が機能できていない?とも思い、以前の作業端末から試しに接続を試みたところ、問題なくできました。
というわけで、やはりUser側で設定ミスがありそうなので、もう少し細かく見ていくことにしました。

デバッグログで地道に調査

ssh接続時にデバッグログを出しながら、何が起きているのか追跡してみました。

$ ssh -vT git@[gitのHost名]
OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n  7 Dec 2017
debug1: Reading configuration data /home/user-name/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to [gitのHost名] [gitのIPアドレス] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/user-name/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user-name/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user-name/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user-name/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user-name/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user-name/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user-name/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user-name/.ssh/id_ed25519-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000
debug1: Authenticating to [gitのHost名]:22 as 'git'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: diffie-hellman-group-exchange-sha256
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-ctr MAC: umac-64@openssh.com compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: umac-64@openssh.com compression: none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<3072<8192) sent
debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: got SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: ssh-rsa SHA256:********
debug1: Host '[gitのHost名]' is known and matches the RSA host key.
debug1: Found key in /home/user-name/.ssh/known_hosts:1
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
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
No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1000)

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1000)

debug1: Next authentication method: publickey
debug1: Trying private key: /home/user-name/.ssh/id_rsa
debug1: Trying private key: /home/user-name/.ssh/id_dsa
debug1: Trying private key: /home/user-name/.ssh/id_ecdsa
debug1: Trying private key: /home/user-name/.ssh/id_ed25519
debug1: No more authentication methods to try.
git@[gitのHost名]: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

じっと1行目から見ていくと、不穏な動作をしていることが分かります。
↓に注目すべきところをピックアップしてみました。

debug1: Reading configuration data /home/user-name/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to [gitのHost名] [gitのIPアドレス] port 22.
…
debug1: identity file /home/user-name/.ssh/id_rsa type -1

デバッグログ上部では/home/user-name/.ssh/configの中身を見に行った後、/etc/ssh/ssh_configの中身も見に行って、/etc/ssh/ssh_config内の19行目でマッチしたと書いてあります。
そして下部でid_rsaファイルを読みに行こうとしております。

…あれ、私が作ったファイルはhoge_rsaでは???

どうやら私の設定したconfigファイルに誤記があり、代わりにssh_configファイル内の19行目に記載されていた情報で接続しようとして失敗していた…ということが分かりました。

※ちなみに、/etc/ssh/ssh_configはシステム全体にわたる設定ファイルらしく、ユーザが設定するファイル(/home/user-name/.ssh/config)で指定されなかった値を提供したり、デフォルト値としての役割も果たしてくれるそうです。

configを見直してみた

それでは再度、configファイルを見てみましょう。

~/.ssh/config
Host githoge [接続するホスト名。ここを見てパターンマッチングする]
  HostName       git.hoge.com
  User           moritaro
  IdentityFile   ~/.ssh/hoge_rsa
  IdentitiesOnly yes

そして、私が打っていたコマンドは以下の通りでした。

ssh git@git.hoge.com

…もうお分かりですかね。パターンマッチングをするHost部分が実際に打っていたHost名と違っていたためにエラーとなっておりました。つらい…。
ちゃんと設定する変数はそれぞれどのような役割を持っているのか、理解した上で使いなはれという良い教訓になりましたorz

今回は仕事の都合上、HostにもHostNameと同じ値を設定するようにしました。
(もちろんssh接続するときにssh git@githogeとしてあげる、も正解です。)

おわりに

今回のトラブルシューティングをするにあたって、マッドサイエンティストな尊敬する先輩にとても助けられました。。
その先輩から、小さなトラブルを積み上げれば、問題の切り分けや解決スキルがアップしていくよと言われました。まさにその通りです!本当にありがとうございました:sob:
本記事はその先輩から頂いたお言葉を結びとさせていただきます。
ウェルカムトラブル!!:bomb:

感謝感激…!参考にしたページ

いつも皆様にはお世話になっております :bow:

8
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
8
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?