Bitbucket Cloud・Pipelines・2026年11月2日に確認

Bitbucket Pipelines：「Host key verification failed」と「Permission denied (publickey)」

ステップで ssh・scp・rsync・SSH の git を使うには、2つが要ります。ビルドの known_hosts に相手のホストがあること、そしてホストが受け付ける鍵です。1つ目が無いと、ssh は鍵を出す前に止まります。

Host key verification failed.

2つ目が無いと、ホストの側が断ります。

deploy@203.0.113.10: Permission denied (publickey).

Host key verification failed

Atlassian の Linux で Pipelines SSH キーをセットアップするでは、既知のホストは鍵と同じ画面で持ちます。Repository settings の Pipelines の下の SSH keys でホストのアドレスを入れ、Fetch で指紋を出します。サーバーが自分で示す指紋と見比べてから、ホストを足します。以後のビルドは、その指紋でホストを確かめます。

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub   # サーバーの上で

Bitbucket と GitHub の指紋は、Pipelines が全部のビルドに自分で入れます（画面の一覧には出ません）。2026年10月からは、SSH の Git の移り先の ssh.bitbucket.org も入っています（移行の日程）。Atlassian は BCLOUD-24132 を10月20日に「Added ssh.bitbucket.org to known hosts list」（ssh.bitbucket.org を既知のホストの一覧に追加）として、直したことにして閉じました。それまでは、ssh -T git@ssh.bitbucket.org を打つステップがここで止まっていました。

サーバーを入れ直したり、ホスト鍵を作り直したりすると、保存した指紋と合わなくなり、ssh は同じように止まります。一覧からそのホストを消し、新しい指紋を確かめて、もう一度 Fetch します。

既知のホストが届かないところ

docker build や Docker Compose の中。Pipelines が既知のホストを書くのは Build setup のときのビルド用コンテナだけで、docker サービスが起こすコンテナには書きません。Atlassian の記事 Pipelines: host key verification failed while cloning private repository with docker-in-docker（英語・2025年9月25日更新）は、Dockerfile のクローンの前で足しています。Dockerfile の中の npm install・yarn install・composer install がプライベートなリポジトリから依存を取ってくる場合も同じです。
```
RUN mkdir ~/.ssh && curl https://bitbucket.org/site/ssh >> ~/.ssh/known_hosts
```
セルフホストのランナーから、プライベートなアドレスへ。Fetch が届くのは公開のホストとアドレスだけです。Atlassian の記事 Troubleshooting "Host key verification failed" error on Bitbucket Cloud Pipeline Runners（英語・2025年9月26日更新）は、代わりにステップの中で読み取っています。
```
- step:
    runs-on:
      - self.hosted
      - linux
    script:
      - ssh-keyscan -H 172.20.40.175 >> ~/.ssh/known_hosts
```

スクリプトの ssh-keyscan は、そのとき答えた相手をそのまま信じます。Atlassian の Bitbucket Pipelines で SSH キーを使用するも例では使っていますが、StrictHostKeyChecking=no で確認を切ると中間者攻撃を受けうる、と注意しています。一度確かめたホストから作った known_hosts のファイルをリポジトリに入れておけば、どちらも避けられます（パイプラインで複数の SSH キーを使用する）。

- mkdir -p ~/.ssh
- cat my_known_hosts >> ~/.ssh/known_hosts

Permission denied (publickey)

鍵も同じ設定の画面にあります。Generate keys は Bitbucket で鍵の組を作り、Use my own keys は自分で作った組を Private key と Public key の欄に貼って Save key pair で保存します。Atlassian のマシンと Linux のランナーで動くステップでは、Pipelines が秘密鍵を ~/.ssh/config の既定の鍵にします。ステップの ssh は、-i を付けなくてもそれを使います。

公開鍵が、つなぐユーザーのところにあるか。サーバーのそのユーザーの ~/.ssh/authorized_keys に入れます。ssh-copy-id でも足せます。ファイルを新しく作るとき、Atlassian のページは chmod 700 ~/.ssh と chmod 600 ~/.ssh/authorized_keys にしています。
設定の鍵と、サーバーの公開鍵が同じ組か。保存した鍵は直せず、消して新しく足すよう書かれています。足し直したり、もう一度 Generate keys を押したりした後は、新しい公開鍵を入れるまでサーバーにあるのは古い鍵です。
コマンドが、鍵のある場所で動いているか。鍵が入るのはビルド用コンテナの ssh の設定です。docker build に鍵を渡せるのは --ssh default=$BITBUCKET_SSH_KEY_FILE だけで、BITBUCKET_SSH_KEY_FILE は鍵の場所を持つ既定の変数です。ほかの渡し方は、Pipelines が断るオプションに入ります（「authorization denied by plugin pipelines」）。
別の Bitbucket リポジトリには、そのリポジトリの Access keys に公開鍵を足します（サブモジュール）。ビルドが動くリポジトリへ push し返すのは別の話です（「Permission denied to update branch」）。

Atlassian は、リポジトリに書き込める人は全員、この鍵で相手のホストに入れることになる、とも書いています。

2本目の鍵と「Load key ... invalid format」

Pipelines の SSH キーは、1つのリポジトリに1つです。パイプラインで複数の SSH キーを使用するは、ほかの鍵をリポジトリの保護された変数（Secured）に入れています。変数は改行を持てないので、秘密鍵を先に base64 にします。

base64 -w 0 < deploy_key     # macOS では base64 < deploy_key

ステップでは、自分だけが読めるファイルに戻し、-i で渡します。

- (umask 077; echo $DEPLOY_KEY | base64 --decode > ~/.ssh/deploy_key)
- ssh -i ~/.ssh/deploy_key deploy@203.0.113.10 'echo ok'

同じページは、保護された変数もリポジトリに書き込める人なら取り出せること、リポジトリの変数はビルドが起こす子のプロセスにも渡ることを注意しています。勧めているのは、個人の鍵ではなく Pipelines 用に作った鍵です。使える人を絞るなら、デプロイの変数とデプロイの権限を組み合わせます。

Atlassian のパイプは、SSH_KEY を渡さなければリポジトリの Pipelines の鍵を使います。SSH_KEY に入れる鍵も、同じように base64 にしておく必要があります。そのまま貼ると、次のように止まります（Atlassian の記事 Bitbucket Cloud Pipe "atlassian/scp-deploy" error、英語・2025年9月26日更新）。

debug1: Trying private key: /root/.ssh/pipelines_id
Load key "/root/.ssh/pipelines_id": invalid format
debug1: No more authentication methods to try.
user@xx.xx.xx.xx: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

自分のイメージを使うとき

Docker のイメージには、SSH のクライアントが入っていないものもあります。Pipelines の既定のイメージには入っています。自分のイメージなら、スクリプトで入れます。たとえば apt-get update -y と apt-get install -y ssh です（Atlassian の Linux のページ）。入っていないと、ステップは ssh: command not found で止まります。

IntelliJ IDEA で Bitbucket Pipelines を見る

Pipeline Inbox for Bitbucket Pipelines は、Lesstep が作っている JetBrains IDE（2024.1 以降）のプラグインです。Bitbucket Cloud の全部のリポジトリのパイプラインを IDE のツールウィンドウに並べ、ステップ、失敗したステップと止まったコマンド、Bitbucket が書くそばから伸びるステップのログを見せます。一覧・ステップ・ログは無料。パイプラインの実行・やり直し・停止は Pro（月 US$1.50・30日の無料試用つき）。

JetBrains Marketplace で入れる

Atlassian・Bitbucket・Bitbucket Pipelines は Atlassian の商標、Docker は Docker, Inc. の商標、GitHub は GitHub, Inc. の商標、IntelliJ IDEA は JetBrains s.r.o. の商標です。このページは Atlassian・Docker・GitHub・JetBrains のいずれとも提携しておらず、承認も受けていません。

ほかに：「Cannot connect to the Docker daemon」 · 「authorization denied by plugin pipelines」（Docker） · 「Container 'docker' exceeded memory limit.」 · push したのに Pipelines が動かない · 「Container 'Build' exceeded memory limit.」 · 「Exceeded build time limit of 120 minutes」 · キャッシュが効かない · 「unexpected system error」 · 「command not found」 · サブモジュールを取ってこない · 「We couldn't clone the repository」 · 「No online runner available」 · 「No space left on device」 · 「Step exceeded processing limits」 · 次のステップにアーティファクトが無い · 前は通ったビルドが今は落ちる · Build setup に時間がかかる · ビルド時間を使い切った · 「Permission denied to update branch」 · 「You have reached your pull rate limit」（Docker Hub） · 「There is an error in your bitbucket-pipelines.yml」 · 「This pipeline was paused」（デプロイ） · 変数が空になる · テストの結果が出ない · IntelliJ IDEA の Bitbucket Pipelines 用プラグインの比較 · English