Re: [mercurial-ja:1824] bitbucketのpipelines内から外部にhg push する場合のssh設定でフィンガープリントが取得できない場合がある

[Katsunori FUJIWARA]

藤原です。

確認作業に時間が取れず、返信が遅れてしまいました。

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 でのフィンガープリント取得が相変わらず駄目な場合、適当
に選んだ第３のリポジトリでの 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)

[ohira]

おおひらです。

削除すると再度取得できなそうなので、削除しての再取得はできない状況です。

登録されたエントリーをWebインターフェースで目視して、一つのホストのフィンガープリントが複数存在していて行がイレギュラーにつながっているように見えたのですが、

Dockerコンテナ内に生成されたファイルを確認すると通常のホスト名とハッシュのホスト名の2つのエントリーが生成されているだけで問題ないことがわかりました。

上の ~/.ssh/authorized_keys は、dockerコンテナ側ですよね。

フィンガープリントの取得はコンテナ側ではないと考えます。

また:

  - 無効なユーザ名指定による ssh 利用であっても、known_hosts への
    フィンガープリント受け入れ確認は、もう少し手前の段階で処理される

  - ssh-keyscan コマンドのような、「フィンガープリントの取得のみ」
    を行う処理の場合、そもそも上記の段階に至らない

であることも確認しました。

確認されていると思いますが、念のため

ユーザー名の表示は、デバックLevel2でログを出さないと表示されません。

デフォルトのログはもっと簡素なものです。

[shin@faith] ~% 
[shin@faith] ~% 
[shin@faith] ~% ssh sp11

 * Found existing ssh-agent (6036)

sp11% cat /service/sshd/run
#!/bin/sh
exec 2>&1
exec envdir /var/service/sshd/env \
tcpserver -vDHRl0 -XU -x rules/data.cdb \
0 ssh \
/usr/sbin/sshd -ei -f /etc/ssh/sshd_config-service.sshd
sp11% 

sp11% 
sp11% fgrep LogLevel /etc/ssh/sshd_config-service.sshd
#LogLevel INFO
#LogLevel VERBOSE
#LogLevel DEBUG
LogLevel DEBUG2
#LogLevel DEBUG3
sp11% 
sp11% 

 

もしかしたら、おおひらさんが at_2/escm11 の連携設定をしたまさにそ
の時に限って、たまたま以下のような実装が漏れ出てしまった可能性もあ
ります。

  無作為に生成した「おそらく存在しないであろうユーザ名」
  (この場合は 0e1e2be0-d661-48ca-9d0c-619575155a83) を使った ssh
  ログインを行うことで、接続先ホストの公開鍵フィンガープリントを取得

ユーザー名を生成しているのは、bitbuketです。

Web インターフェースで finger printの取得を実行したときに行われていて、

実行する毎に違ったユーザー名が使われます。

 

しかし、これまでに述べた事柄から、現状では、フィンガープリント取得
において、ユーザ名指定付きで認証実施段階に到達することはないように
見えます。

試しに、at_2 リポジトリでの escm11 のフィンガープリント取得を、
「SSH 鍵対の生成」無し (= ~/.ssh/authorized_keys への追加もなし)
で、再度行ってみてもらえますか？

また、at_2 でのフィンガープリント取得が相変わらず駄目な場合、適当
に選んだ第３のリポジトリでの escm11 のフィンガープリント取得も同じ
ように失敗するか、確認してみてもらえますか？

今日はbitbucketの調子が悪いようで、第三のリポジトリ作れませんでした、日をあらためて再度やってみます。

 

 ~/.ssh/authorized_keys は コンテナ側のものをさしていますか?

ホスト側のファイルはユーザーが確認する手段がありません。

自分が表示していたコンテナ側のものは

ユーザーが追加しているわけではなくて、Dockerのホスト側で取得したものが

勝手に追加されているのと、Dockerコンテナ内の hg pull で勝手に追加されたものが合わさったものです。

[ohira]

おおひらです。

bitbucketに at_3 リポジトリを新たに作成して、キーペアの設定を行わずに

フィンガープリントの取得を試しました。

新規にリポジトリ at_3 を作成して、キーペアの設定を行わない状態でbitbucketのWeb インターフェースから finger print の取得をためした時の

接続先のログです。

2017-10-31 19:18:38.319269500 tcpserver: status: 3/40
2017-10-31 19:18:38.319417500 tcpserver: pid 89680 from 104.192.139.229
2017-10-31 19:18:38.319515500 tcpserver: ok 89680 0:210.248.168.135:22 :104.192.139.229::58668
2017-10-31 19:18:38.323042500 tcpserver: status: 4/40
2017-10-31 19:18:38.323177500 tcpserver: pid 89681 from 104.192.139.229
2017-10-31 19:18:38.323290500 tcpserver: ok 89681 0:210.248.168.135:22 :104.192.139.229::36836
2017-10-31 19:18:38.328992500 debug1: inetd sockets after dupping: 3, 4
2017-10-31 19:18:38.329050500 debug1: res_init()
2017-10-31 19:18:38.329418500 Connection from 104.192.139.229 port 58668
2017-10-31 19:18:38.329497500 debug1: Client protocol version 2.0; client software version SSHD-CORE-1.2.0
2017-10-31 19:18:38.329516500 debug1: no match: SSHD-CORE-1.2.0
2017-10-31 19:18:38.329518500 debug1: Enabling compatibility mode for protocol 2.0
2017-10-31 19:18:38.329520500 debug1: Local version string SSH-2.0-OpenSSH_5.1p1 FreeBSD-20080901
2017-10-31 19:18:38.329532500 debug2: fd 3 setting O_NONBLOCK
2017-10-31 19:18:38.330431500 debug2: Network child is on pid 89682
2017-10-31 19:18:38.330433500 debug1: permanently_set_uid: 22/22
2017-10-31 19:18:38.330435500 debug1: list_hostkey_types: ssh-dss
2017-10-31 19:18:38.330437500 debug1: SSH2_MSG_KEXINIT sent
2017-10-31 19:18:38.332289500 debug1: inetd sockets after dupping: 3, 4
2017-10-31 19:18:38.332342500 debug1: res_init()
2017-10-31 19:18:38.332709500 Connection from 104.192.139.229 port 36836
2017-10-31 19:18:38.332782500 debug1: Client protocol version 2.0; client software version SSHD-CORE-1.2.0
2017-10-31 19:18:38.332805500 debug1: no match: SSHD-CORE-1.2.0
2017-10-31 19:18:38.332807500 debug1: Enabling compatibility mode for protocol 2.0
2017-10-31 19:18:38.332809500 debug1: Local version string SSH-2.0-OpenSSH_5.1p1 FreeBSD-20080901
2017-10-31 19:18:38.332821500 debug2: fd 3 setting O_NONBLOCK
2017-10-31 19:18:38.333566500 debug2: Network child is on pid 89683
2017-10-31 19:18:38.333568500 debug1: permanently_set_uid: 22/22
2017-10-31 19:18:38.333570500 debug1: list_hostkey_types: ssh-dss
2017-10-31 19:18:38.333572500 debug1: SSH2_MSG_KEXINIT sent
2017-10-31 19:18:38.438002500 debug1: SSH2_MSG_KEXINIT received
2017-10-31 19:18:38.438046500 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
2017-10-31 19:18:38.438061500 debug2: kex_parse_kexinit: ssh-dss
2017-10-31 19:18:38.438063500 debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
2017-10-31 19:18:38.438083500 debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
2017-10-31 19:18:38.438087500 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
2017-10-31 19:18:38.438089500 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
2017-10-31 19:18:38.438111500 debug2: kex_parse_kexinit: none,zlib@openssh.com
2017-10-31 19:18:38.438113500 debug2: kex_parse_kexinit: none,zlib@openssh.com
2017-10-31 19:18:38.438115500 debug2: kex_parse_kexinit: 
2017-10-31 19:18:38.438117500 debug2: kex_parse_kexinit: 
2017-10-31 19:18:38.438137500 debug2: kex_parse_kexinit: first_kex_follows 0 
2017-10-31 19:18:38.438139500 debug2: kex_parse_kexinit: reserved 0 
2017-10-31 19:18:38.438141500 debug2: kex_parse_kexinit: ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
2017-10-31 19:18:38.438144500 debug2: kex_parse_kexinit: ssh-dss
2017-10-31 19:18:38.438146500 debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,aes192-cbc,aes256-cbc
2017-10-31 19:18:38.438156500 debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,aes192-cbc,aes256-cbc
2017-10-31 19:18:38.438158500 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-sha1-96,hmac-md5-96
2017-10-31 19:18:38.438160500 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-sha1-96,hmac-md5-96
2017-10-31 19:18:38.438183500 debug2: kex_parse_kexinit: none
2017-10-31 19:18:38.438185500 debug2: kex_parse_kexinit: none
2017-10-31 19:18:38.438187500 debug2: kex_parse_kexinit: 
2017-10-31 19:18:38.438189500 debug2: kex_parse_kexinit: 
2017-10-31 19:18:38.438190500 debug2: kex_parse_kexinit: first_kex_follows 0 
2017-10-31 19:18:38.438192500 debug2: kex_parse_kexinit: reserved 0 
2017-10-31 19:18:38.438216500 debug2: mac_setup: found hmac-md5
2017-10-31 19:18:38.438218500 debug1: kex: client->server aes128-ctr hmac-md5 none
2017-10-31 19:18:38.438220500 debug2: mac_setup: found hmac-md5
2017-10-31 19:18:38.438222500 debug1: kex: server->client aes128-ctr hmac-md5 none
2017-10-31 19:18:38.441469500 debug1: SSH2_MSG_KEXINIT received
2017-10-31 19:18:38.441515500 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
2017-10-31 19:18:38.441534500 debug2: kex_parse_kexinit: ssh-dss
2017-10-31 19:18:38.441536500 debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
2017-10-31 19:18:38.441539500 debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
2017-10-31 19:18:38.441568500 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
2017-10-31 19:18:38.441571500 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
2017-10-31 19:18:38.441573500 debug2: kex_parse_kexinit: none,zlib@openssh.com
2017-10-31 19:18:38.441575500 debug2: kex_parse_kexinit: none,zlib@openssh.com
2017-10-31 19:18:38.441577500 debug2: kex_parse_kexinit: 
2017-10-31 19:18:38.441593500 debug2: kex_parse_kexinit: 
2017-10-31 19:18:38.441595500 debug2: kex_parse_kexinit: first_kex_follows 0 
2017-10-31 19:18:38.441597500 debug2: kex_parse_kexinit: reserved 0 
2017-10-31 19:18:38.441599500 debug2: kex_parse_kexinit: ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
2017-10-31 19:18:38.441602500 debug2: kex_parse_kexinit: ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
2017-10-31 19:18:38.441640500 debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,aes192-cbc,aes256-cbc
2017-10-31 19:18:38.441643500 debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,aes192-cbc,aes256-cbc
2017-10-31 19:18:38.441645500 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-sha1-96,hmac-md5-96
2017-10-31 19:18:38.441648500 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha2-512,hmac-sha1-96,hmac-md5-96
2017-10-31 19:18:38.441717500 debug2: kex_parse_kexinit: none
2017-10-31 19:18:38.441719500 debug2: kex_parse_kexinit: none
2017-10-31 19:18:38.441720500 debug2: kex_parse_kexinit: 
2017-10-31 19:18:38.441722500 debug2: kex_parse_kexinit: 
2017-10-31 19:18:38.441724500 debug2: kex_parse_kexinit: first_kex_follows 0 
2017-10-31 19:18:38.441726500 debug2: kex_parse_kexinit: reserved 0 
2017-10-31 19:18:38.441728500 debug2: mac_setup: found hmac-md5
2017-10-31 19:18:38.441737500 debug1: kex: client->server aes128-ctr hmac-md5 none
2017-10-31 19:18:38.441739500 debug2: mac_setup: found hmac-md5
2017-10-31 19:18:38.441741500 debug1: kex: server->client aes128-ctr hmac-md5 none
2017-10-31 19:18:38.441743500 no hostkey alg
2017-10-31 19:18:38.441754500 debug1: do_cleanup
2017-10-31 19:18:38.441756500 debug1: do_cleanup
2017-10-31 19:18:38.442170500 tcpserver: end 89681 status 65280
2017-10-31 19:18:38.442172500 tcpserver: status: 3/40
2017-10-31 19:18:38.645853500 debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
2017-10-31 19:18:38.651371500 debug2: monitor_read: 0 used once, disabling now
2017-10-31 19:18:38.651438500 debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
2017-10-31 19:18:38.681686500 debug2: dh_gen_key: priv key bits set: 134/256
2017-10-31 19:18:38.681732500 debug2: bits set: 1984/4096
2017-10-31 19:18:38.681748500 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
2017-10-31 19:18:38.915990500 debug2: bits set: 2058/4096
2017-10-31 19:18:38.947730500 debug2: monitor_read: 4 used once, disabling now
2017-10-31 19:18:38.947754500 debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
2017-10-31 19:18:38.947865500 debug2: kex_derive_keys
2017-10-31 19:18:38.947886500 debug2: set_newkeys: mode 1
2017-10-31 19:18:38.947910500 debug1: SSH2_MSG_NEWKEYS sent
2017-10-31 19:18:38.947925500 debug1: expecting SSH2_MSG_NEWKEYS
2017-10-31 19:18:39.221370500 debug2: set_newkeys: mode 0
2017-10-31 19:18:39.221394500 debug1: SSH2_MSG_NEWKEYS received
2017-10-31 19:18:39.221396500 debug1: KEX done
2017-10-31 19:18:39.429183500 debug1: userauth-request for user e4b683c7-278e-4818-b08f-b11f20e2dda4 service ssh-connection method none
2017-10-31 19:18:39.429207500 debug1: attempt 0 failures 0
2017-10-31 19:18:39.429531500 debug2: parse_server_config: config reprocess config len 239
2017-10-31 19:18:39.429786500 Invalid user e4b683c7-278e-4818-b08f-b11f20e2dda4 from 104.192.139.229
2017-10-31 19:18:39.430161500 debug2: monitor_read: 6 used once, disabling now
2017-10-31 19:18:39.430163500 input_userauth_request: invalid user e4b683c7-278e-4818-b08f-b11f20e2dda4
2017-10-31 19:18:39.430165500 debug2: monitor_read: 3 used once, disabling now
2017-10-31 19:18:39.430167500 debug2: input_userauth_request: try method none
2017-10-31 19:18:39.541427500 debug1: userauth-request for user e4b683c7-278e-4818-b08f-b11f20e2dda4 service ssh-connection method publickey
2017-10-31 19:18:39.541452500 debug1: attempt 1 failures 0
2017-10-31 19:18:39.541464500 debug2: input_userauth_request: try method publickey
2017-10-31 19:18:39.541466500 debug2: userauth_pubkey: disabled because of invalid user
2017-10-31 19:18:39.650089500 Connection closed by 104.192.139.229
2017-10-31 19:18:39.650119500 debug1: do_cleanup
2017-10-31 19:18:39.650373500 debug1: do_cleanup
2017-10-31 19:18:39.650518500 tcpserver: end 89680 status 65280
2017-10-31 19:18:39.650546500 tcpserver: status: 2/40

 

[Katsunori FUJIWARA]

藤原です。

2017年10月31日 18:45 ohira <shin....@gmail.com>:

済みません。この文脈で、いきなり「docker コンテナ側～」という話が
出てきて面食らっています。

私の認識では:

- escm11 は、おおひらさんが保有するサーバ (物理か仮想かは問いません)

- 「bitbucket ⇒ escm11」という接続方向において、bitbucket 側が
escm11 上の sshd のフィンガープリントを取得できない (ケースがある)

- 取得できないケースでは "input_userauth_request: invalid user xxxxxx"
というログが出力されている

というものなので、あくまで (おおひらさんのケースにおける) escm11
において、件のような問題が発生するとしたら、原因として何が想定でき
るか？という点にのみ着目しています。

ですから、~/.ssh/ や ~/.ssh/authorized_keys も、bitbucket の
pipelines の設定で、ssh フィンガープリント取得時に接続されるホスト
(おおひらさんのケースなら escm11) 上のものを想定しています。

もしかして、この段階で私の問題認識が間違っていたりします？


ちなみに、escm11 は PCBSD と思われますが、OS 種別等はメールの都度
明記してもらえますか？過去メールを検索すれば何とか特定できますが、
流石に我々は「escm11 ⇒ PCBSD」とは即座に連想できませんので（笑）

また、今回のようなケースなら sshd のバージョン情報も併記してもらえ
ると助かります。

先述したように、私が認識している問題は「フィンガープリント取得で
bitbucket ⇒ escm11 の接続が失敗する」というものなので、主語は概ね
「(フィンガープリントを fetch しようとしている) bitbucket」です。

上記の挙動 (= 名前の生成 + ssh ログイン) の主語も bitbucket です。

>> しかし、これまでに述べた事柄から、現状では、フィンガープリント取得
>> において、ユーザ名指定付きで認証実施段階に到達することはないように
>> 見えます。
>>
>> 試しに、at_2 リポジトリでの escm11 のフィンガープリント取得を、
>> 「SSH 鍵対の生成」無し (= ~/.ssh/authorized_keys への追加もなし)
>> で、再度行ってみてもらえますか？
>>
>> また、at_2 でのフィンガープリント取得が相変わらず駄目な場合、適当
>> に選んだ第３のリポジトリでの escm11 のフィンガープリント取得も同じ
>> ように失敗するか、確認してみてもらえますか？
>
> 今日はbitbucketの調子が悪いようで、第三のリポジトリ作れませんでした、日をあらためて再度やってみます。
>
> ~/.ssh/authorized_keys は コンテナ側のものをさしていますか?

先述したように、私が認識している問題は「フィンガープリント取得で
bitbucket ⇒ escm11 の接続が失敗する」というものなので、~/.ssh は
escm11 上のものです。


先のメールでも言及しましたが、escm11 との連携が上手くいかない状況
が続くようであれば、bitbucket の公式 issue tracker に報告した方が
良いと思います。(OS/sshd バージョン明記をお忘れなく)

https://bitbucket.org/site/master/issues?status=new&status=open
https://bitbucket.org/site/master/wiki/Home

> ホスト側のファイルはユーザーが確認する手段がありません。
> 自分が表示していたコンテナ側のものは
> ユーザーが追加しているわけではなくて、Dockerのホスト側で取得したものが
> 勝手に追加されているのと、Dockerコンテナ内の hg pull で勝手に追加されたものが合わさったものです。
>>
>>
>> > 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
>>

> --
> from Mercurial 日本語コミュニティ <mercur...@googlegroups.com>
> ※ ヘルプ表示は http://groups.google.com/group/mercurial-ja?hl=ja
> ---
> このメールは Google グループのグループ「mercurial-ja」に登録しているユーザーに送られています。
> このグループから退会し、グループからのメールの配信を停止するには mercurial-ja...@googlegroups.com
> にメールを送信してください。
> その他のオプションについては https://groups.google.com/d/optout にアクセスしてください。



--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)

[ohira]

2017年10月31日火曜日 21時22分31秒 UTC+9 FUJIWARA Katsunori:

dockerコンテナ側ならパスの確認しようもあるのですが、そうじゃないとすると具体的にどのようなパスになりますか?

接続先のホストのファイルなら実在しないユーザーのホームディレクトリはないはずだし、、、

無作為に生成したユーザー名が接続先に存在するわけではないので

~/ はどこになるのでしょうか。

[Katsunori FUJIWARA]

藤原です。

2017年11月8日 11:02 ohira <shin....@gmail.com>:

改めて私の推測を以下にまとめますが、ここで「~/.ssh を確認」しよう
としているのは、「escm11 上の sshd」です (存在しないから当然エラー
になります)。

escm11 に対する bitbucket からの SSH 接続が、「escm11 の公開鍵
情報の取得」手順を通り越して、接続時に指定した (＝ 存在しない
筈の) ユーザの ~/.ssh を確認する段階まで進んでしまっている (+
確認失敗をもって公開鍵取得も失敗とみなしている) ように見える。

公開鍵情報の取得を主眼とする処理において、「指定ユーザの
~/.ssh 所在確認」手順まで進んだ上に、そこでのエラーをもって
「公開鍵情報取得の失敗」とみなしているのは、(bitbucket 側とし
ても) 想定外の挙動なのでは？

おおひらさんに対して「(存在しないユーザの) ~/.ssh の確認」等々をお
願いしている訳ではないです (存在しないユーザのものですから、確認し
ようがありません)。


少なくとも Linux 上の Open SSH 実装では、「sshd ホスト側公開鍵の取
得」時点では、接続時に指定したユーザの ~/.ssh 所在の確認等は行って
いるようには見えません。

プロトコル仕様によって、ある程度挙動が定まりますから、sshd の実装
によって極端に挙動が異なることは無いとは思いますが、特定条件下で継
続的に問題が発生するのであれば、環境依存性のある問題として、
bitbucket 側に報告した方が良いのでは？というのが私の見解です。

--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)