はじめに
こんにちは！
ＢＦＴ名古屋支店・インフラ女子（？）のやまぐちです。
名古屋市内の小規模飲食店を対象に無償で混雑状況見える化サービス「こんどる？」を提供するにあたって、店舗内には複数の機能を実装したラズパイを設置しています。
先日３台中１台が突然gitに接続できないという現象に見舞われました。根本原因はまだわかっていませんが、接続できない時のトラブルシュートとしてSSHはとてもわかりやすいので情報を残しておくことにします。
gitでレスポンスが返ってこない時のトラブルシュート
何が起こっていたのか
- gitコマンドを実行してもレスポンスが返ってこない
- 他の2台のラズパイは特に問題なくgitコマンドを実行できている
- ＝GitLab側は特に問題ない
- 問題が発生しているラズパイには遠隔からログインしている
- ネットワークは繋がっている
- 接続情報を記載している設定ファイルが更新・削除された形跡はない
接続先（GitLab）には問題はなく、ラズパイがインターネットに出れていないというわけでもありません。gitコマンドでレスポンスが返ってこないので途中で何が起こっているか確認する必要があります。
SSHでのトラブルシュート
SSHで接続できない場合、「-vvv」をつけてみてログを見るのが鉄則です。
vの数はデバッグのレベルと対応しており、一つならデバッグレベル1、二つならデバッグレベル2ですが最初からvvvとデバッグレベルは3にしておく方がいいです。ログはたくさん出ますが必要に応じて少なくして見やすいようにします。
冒頭部分を抜き出します。「Connection established.」とあるので、名前解決はできていてgitlabとSSH接続ができていることがわかります。
CondorU@SHR-001:~ $ ssh -T git@gitlab.com -vvv OpenSSH_7.9p1 Debian-10+deb10u2+rpt1, OpenSSL 1.1.1d 10 Sep 2019 debug1: Reading configuration data /home/CondorU/.ssh/config debug1: /home/CondorU/.ssh/config line 1: Applying options for gitlab.com debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug2: resolving "gitlab.com" port 22 debug2: ssh_connect_direct debug1: Connecting to gitlab.com [2606:4700:90:0:f22e:fbec:5bed:a9b9] port 22. debug1: Connection established. ~略~
ログは長いですが、以下のログを見て認証も通っていることが分かります（つまり秘密鍵は正しい）。
~略~ debug2: we sent a publickey packet, wait for reply debug3: receive packet: type 52 debug1: Authentication succeeded (publickey). Authenticated to gitlab.com ([2606:4700:90:0:f22e:fbec:5bed:a9b9]:22). ~略~
そして最後は以下のようなログが続き、接続はできているのに何も起こらない状態が続きます。
~略~ debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1 debug3: send packet: type 100 debug3: receive packet: type 98 debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1 debug3: send packet: type 100 ~略~
ログに直接的なエラーが見あたらない場合は、正常に接続できている側と比較します。
いきなり大きな違いが。
左側が正常に接続できているラズパイ、右側が接続できないラズパイの実行結果です。接続できないラズパイはIPv6で接続していることがわかります。
その他、差異として出てきたのはIPv4ではなくIPv6で接続している箇所でした。GitLabがIPv6に対応していないのか？と思いつつも調べてみると対応している様子。
しかし私たちと同様に「いきなりIPv6が原因で接続できなくなった」という記事も（2016年と古いが）見つかりました。
突然Bitbucketにgitで接続できなくなったらIPv6関連を疑ってみるとよいかも 2016/07/20 - Qiita
対処にサービス影響はないことを確認し、接続情報設定ファイルを修正します。
gitへのSSH接続をIPv4に固定する
gitの設定で上の記事にあるような「AddressFamily」が見当たらなかったのですが、どうやらSSHのオプションらしく、sshd_configに書かれているようです（デフォルトでIPv4, IPv6どちらも使う）。gitで接続する時にそのオプションを上書きすべく、接続情報設定ファイルを修正していきます。
$ cd /home/CondorU/.ssh/ $ cp -p config config_`date "+%Y%m%d"` $ vi config ※「AddressFamily inet」を追記 $ diff config config_`date "+%Y%m%d"` 7d6 < AddressFamily inet $ cat config Host gitlab.com HostName gitlab.com User dev_konzatsu IdentityFile ~/.ssh/gitid_rsa TCPKeepAlive yes IdentitiesOnly yes AddressFamily inet
もう一度SSHで接続してみます。
$ ssh -T git@gitlab.com
Welcome to GitLab, @a-yamaguchi1!
Welcome言われました！これで問題なさそうですね（上のコマンドを打つ前に「-vvv」入れて実行確認してます）。
事象発生前は確認していないため、IPv4で接続していたのかはわかりません。また、SSHの設定ではIPv4, IPv6どちらも使う設定のため、IPv6でダメならIPv4に接続するのでは？という疑問も浮かびます（IPv6はIPv4よりも優先される）。接続に時間がかかる（IPv6で一度接続しようとして失敗、IPv4で接続している）対応としてIPv4に固定するという記事もありました。
これはRaspberry Pi OSの特性で、sshd_configに明示的にanyを入れれば解決するかもしれません。他のラズパイで発生していないので一旦この件はクローズとしました。
終わりに
結論：SSHで接続できない時は「-vvv」をつけてログを見てみましょう。ログを見てもわからない場合は、うまくできているものと比較ですね。
以上、ここまで読んでいただきありがとうございました～ ^ ^
