藤原です。
確認作業に時間が取れず、返信が遅れてしまいました。
2017年9月27日 15:55 ohira <
shin....@gmail.com>:
> いつもお世話になっております。
> おおひらです。
>
>
> pipelinesのsshキー設定でフィンガープリントが取得できない場合があります、
> みなさんのところではおなじような問題発生していませんか?
>
>
> 説明
>
> 現在下のような構成で使用しています。
>
> 現状の接続
> ローカルPC(hg push) -> escm11(hg push) -> bitbucket
>
> 最近bitbucketの機能がアップしていますので、bitbucket の
> pipelines を使用して以下のような流れにできればreviewをbitbucket
> で行なったりJIRAと連携したブランチ管理を行なったり、ブランチのア
> クセス制限をつけたりと便利に使えるのではないかと考えました。(デ
> プロイについては 現状も escm11 から行なっているのでそのまま変更
> 無しで使えるのもメリットです)
>
> 新しい接続
> ローカルPC(hg push) -> bitbucket(hg push) -> escm11-> デプロイ先
>
> (現状の接続も新しい接続も公開鍵認証をつかってssh経由で通信することにします)
>
>
> bitbucketからescm11にhg push ssh://hg@escm11 するための下準備
>
> 1. bitbucketにテスト用のリポジトリを作成
> 2. テスト用のリポジトリをローカルPCにclone
> 3. ローカルPCのリポジトリをescm11にclone
> 4. bitbucketのテスト用リポジトリの設定->ssh keys で キーペアを生成
> 5. 生成されたキーペアの公開鍵をescm11のhgadminでユーザーhgのキーとして追加
> 6. bitbucketのpipelinesの接続元IPアドレスとフィンガープリント取得時の接続元IPアドレスを全てescm11への接続許可アドレスとして登録
> 7. bitbucketのテスト用リポジトリの設定->ssh keys -> fingerprintのfetch
> 8. bitbucketのpipelines設定ファイルに hg push --new-branch ssh://
h...@escm11.mxfw.net/<リポジトリ名>を追加
>
Bitbucket が提示している手順では:
https://confluence.atlassian.com/bitbucket/use-ssh-keys-in-bitbucket-pipelines-847452940.html
1. SSH 鍵対の生成
2. known_hosts の更新 (= 接続先公開鍵のフィンガープリント取得)
3. 接続先アカウントの .ssh/authorized_keys への公開鍵追加
ということになっていますが、(2) が (3) よりも先になっていることから、
(2) の手順は「ユーザ認証 (= 実際のログイン) 段階には至らない (or
至る必要がない)」ことがわかりますので、(1) を飛ばして (2) を実行
しても大丈夫な筈、と推測しました。
実際に (1) を飛ばして (2) を実行したところ、私の環境との連携では、
フィンガープリントを問題無く取得できています (何回か繰り返してみま
したが、挙動は安定していました)。
またこの際に、invalid user 云々といったエラーは、sshd のログ出力を
見る限りでは発生していません。
> 下準備が終わったら
>
> ローカルPCからbitbucketへpushするとescm11のリポジトリも更新され
> るのが確認できました。
>
> ところが2つ問題がありまして、
>
> 連携テスト用リポジトリat_1では問題なく連携できたが、同じように設
> 定したat_2ではフィンガープリントのフェッチができないのです。
(これに関しては後述)
> さらに正常に動作しているat_1で取得済みのknown_hostsを表示してみ
> るとescm11の部分に異常が見られました。
これに関しては情報がないので何とも言えませんが、登録したエントリ
を一旦削除して、フィンガープリントの再取得を行っても壊れたままなの
でしょうか?
> pipelinesのキーペア設定やフィンガープリントの取得はリポジトリ毎
> に行う必要がありat_1 では正常にできたのに同じように設定したat_2
> では動作しないのです。特にフィンガープリントが取得できないので困っ
> ています。
>
> at_2 でのフィンガープリント取得時のescm11側のログ
> (少し時間をあけて二回おこないました。二回ともat_2を使っています)
> (正常にpipelinesからssh経由のhg pushができているっぽいat_1の
> フィンガープリント時のログはもう消えてしまいました)
>
> 二回のテストとも invalid userのエラーが発生しているようにみえます。
(snip)
> 0e1e2be0-d661-48ca-9d0c-619575155a83 service ssh-connection method none
> 2017-09-27 12:20:36.086857500 debug1: attempt 0 failures 0
> 2017-09-27 12:20:36.087131500 debug2: parse_server_config: config reprocess config len 239
> 2017-09-27 12:20:36.087373500 Invalid user
> 0e1e2be0-d661-48ca-9d0c-619575155a83 from 104.192.139.229
> 2017-09-27 12:20:36.087530500 debug2: monitor_read: 6 used once, disabling now
> 2017-09-27 12:20:36.087548500 input_userauth_request: invalid user 0e1e2be0-d661-48ca-9d0c-619575155a83
上記の "input_userauth_request: invalid user xxxxxx" が出力されているのは:
- 0e1e2be0-d661-48ca-9d0c-619575155a83 がユーザ名として明示されていて、
- 且つ認証実施の段階 (= ~/.ssh の存在確認) まで処理が進んでいる
という状況を表している筈です。
手元の環境で確認した限りでは、有効なユーザ名でのアクセスの場
合、~/.ssh のモード違反とか、~/.ssh/authorized_keys の内容不正での
接続拒否の場合は、別なエラーとして検出されていました (sshd 実装の
差異の可能性も捨てきれませんが……)。
また:
- 無効なユーザ名指定による ssh 利用であっても、known_hosts への
フィンガープリント受け入れ確認は、もう少し手前の段階で処理される
- ssh-keyscan コマンドのような、「フィンガープリントの取得のみ」
を行う処理の場合、そもそも上記の段階に至らない
であることも確認しました。
もしかしたら、おおひらさんが at_2/escm11 の連携設定をしたまさにそ
の時に限って、たまたま以下のような実装が漏れ出てしまった可能性もあ
ります。
無作為に生成した「おそらく存在しないであろうユーザ名」
(この場合は 0e1e2be0-d661-48ca-9d0c-619575155a83) を使った ssh
ログインを行うことで、接続先ホストの公開鍵フィンガープリントを取得
しかし、これまでに述べた事柄から、現状では、フィンガープリント取得
において、ユーザ名指定付きで認証実施段階に到達することはないように
見えます。
試しに、at_2 リポジトリでの escm11 のフィンガープリント取得を、
「SSH 鍵対の生成」無し (= ~/.ssh/authorized_keys への追加もなし)
で、再度行ってみてもらえますか?
また、at_2 でのフィンガープリント取得が相変わらず駄目な場合、適当
に選んだ第3のリポジトリでの escm11 のフィンガープリント取得も同じ
ように失敗するか、確認してみてもらえますか?
それでも駄目なら、公式の issue tracker に報告した方が良いと思います
(escm11 環境の OS および sshd の版情報等も含めた方が良いでしょう)。
https://bitbucket.org/site/master/wiki/Home
> 2017-09-27 12:20:36.087582500 debug2: monitor_read: 3 used once, disabling now
> 2017-09-27 12:20:36.087708500 debug2: input_userauth_request: try method none
> 2017-09-27 12:20:36.193670500 debug1: userauth-request for user
> 0e1e2be0-d661-48ca-9d0c-619575155a83 service ssh-connection method publickey
> 2017-09-27 12:20:36.193689500 debug1: attempt 1 failures 0
> 2017-09-27 12:20:36.193721500 debug2: input_userauth_request: try method publickey
> 2017-09-27 12:20:36.193739500 debug2: userauth_pubkey: disabled because of invalid user
> 2017-09-27 12:20:36.299544500 Connection closed by 104.192.139.229
> 2017-09-27 12:20:36.299563500 debug1: do_cleanup
> 2017-09-27 12:20:36.299745500 debug1: do_cleanup
> 2017-09-27 12:20:36.299885500 tcpserver: end 85278 status 65280
> 2017-09-27 12:20:36.299887500 tcpserver: status: 3/40
--
----------------------------------------------------------------------
FUJIWARA Katsunori(
flying...@gmail.com)