AWS Vault と AWS CLI のエラー対処｜ネスト・GPG・時刻ズレの解決

はじめに

AWS CLI と AWS Vault は、一度設定すれば快適に使えるツールですが、導入初期や久しぶりに使う際にエラーへ遭遇することがあります。とくに Linux（Ubuntu / WSL）環境では、GPG などのバックエンド設定や時刻同期が絡むため、原因の切り分けに手間取りがちです。

本記事では、AWS CLI および AWS Vault の利用中に遭遇しやすい代表的なエラーと、その対処をまとめます。現在エラーが出ている場合は、以下の一覧から症状の近いものを探してみてください。

要点を先に整理すると、AWS Vault 側のエラーの多くは Linux のバックエンド（GPG / pass）設定に起因し、AWS CLI 側のエラーは権限（IAM）か時刻ズレが主な原因です。まず「Vault の問題か、CLI の権限・時刻の問題か」を分けて考えると、原因にたどり着きやすくなります。

AWS Vault 関連のエラーと対処

AWS Vault は安全性が高い反面、Linux 環境（Ubuntu / WSL）ではバックエンド（pass / GPG）との連携でつまずくことがあります。ここでは代表的な 3 つのパターンを取り上げます。

サブシェルのネスト: running in an existing aws-vault subshell

エラーメッセージ

aws-vault: error: exec: running in an existing aws-vault subshell; 'exit' from the subshell or unset AWS_VAULT to force

なお、旧バージョンではこのエラーが aws-vault sessions should be nested with care, unset $AWS_VAULT to force という文言で表示されていました。現行版では上記の文言に変わっています。

原因

このエラーは、aws-vault exec で起動したサブシェルの中で、さらに aws-vault exec を実行しようとした場合に発生します。サブシェルがすでに認証情報（環境変数 AWS_VAULT）を保持しているため、入れ子での起動が抑止されます。

対処

基本的には、現在のサブシェルから抜けると解消します。

# 現在のサブシェルを終了する
exit

サブシェルから抜けてもエラーが続く場合は、環境変数 AWS_VAULT が残っている可能性があります。以下で解除します。

# 環境変数を解除する（$ は不要）
unset AWS_VAULT

参考: 99designs/aws-vault（cli/exec.go のエラー定義）
https://github.com/99designs/aws-vault/blob/master/cli/exec.go

GPG / pass 関連: decryption failed / Inappropriate ioctl for device

エラーメッセージ

gpg: decryption failed: No secret key
# または
Inappropriate ioctl for device

原因

これらは Ubuntu や WSL 環境で多いエラーです。AWS Vault が認証情報を読み書きする際、バックエンドの GPG がパスフレーズ入力画面（pinentry）を正しく表示できないことで発生します。

対処

~/.bashrc や ~/.zshrc に以下を追記し、GPG が現在の端末（TTY）を認識できるようにします。

export GPG_TTY=$(tty)

追記後は source ~/.bashrc で反映します。なお、pass や GPG の初期設定が未完了の場合は、バックエンドの構築から見直す必要があります。手順は関連記事『AWS Vault を Ubuntu に導入する手順』のバックエンド構築のセクションを参照してください。

プロファイルの有効期限切れ: 作業途中の AccessDenied

症状

長時間のスクリプト実行中や作業の途中で、認証エラー（AccessDenied）が突然発生する。

原因

AWS Vault が発行する一時認証情報（STS トークン）には有効期限があります。aws-vault の既定では 1 時間で、これを超えるとセッション中でも権限を失います。

対処

長時間の作業が見込まれる場合は、--duration オプションで有効期限を延ばして実行します。

# 12 時間有効なセッションを開始する例
aws-vault exec my-profile --duration 12h -- aws s3 ls

ただし、延長できる上限は認証方式によって異なります。IAM ユーザーのセッション（GetSessionToken）は最大 36 時間まで、ロールの引き受け（AssumeRole）はそのロールに設定された最大セッション期間（1〜12 時間）までです。ロール側の上限を超える値を指定すると Maximum duration for assumed roles is 1h0m0s のようなエラーになるため、その場合は AWS 側のロール設定（最大セッション期間）を確認することをおすすめします。

AWS CLI 共通のエラーと対処

AWS Vault を使っているかどうかにかかわらず発生する、AWS CLI 一般のエラーです。aws コマンドが見つからない、またはバージョンが古くてオプションが使えない場合は、インストール自体を見直す必要があります。導入手順は関連記事『AWS CLI インストール手順 Windows と Ubuntu』を参照してください。

時刻ズレ: SignatureDoesNotMatch

エラーメッセージ

An error occurred (SignatureDoesNotMatch) when calling the ListBuckets operation: Signature expired: ...

原因

AWS の API リクエストには、現在時刻が含まれています。クライアント（手元の PC）の時刻が AWS サーバー側と 5 分以上ずれていると、リクエストは不正とみなされて拒否されます。とくに WSL（Windows Subsystem for Linux）や仮想マシン（VM）では、ホストがスリープから復帰した際に Linux 側の時刻が遅れたままになることがあります。

対処

まず、現在の同期状況を確認します。

timedatectl status
# 「System clock synchronized: yes」「NTP service: active」を確認する

現行の Ubuntu（24.04 など）は systemd-timesyncd で時刻を同期します。同期が無効な場合は有効化し、必要に応じてサービスを再起動します。

# NTP 同期を有効化する
sudo timedatectl set-ntp true

# すぐに同期させたい場合はサービスを再起動する
sudo systemctl restart systemd-timesyncd

WSL で時刻が大きくずれた場合は、Windows 側のハードウェアクロックと同期させる方法が手軽です。

sudo hwclock -s

より高精度な同期や、ネットワークが不安定な環境では chrony を利用する方法もあります。

sudo apt update && sudo apt install -y chrony
# インストール後はサービスが自動で起動し、時刻を継続的に補正する

なお、以前広く使われていた ntpdate は、Ubuntu 24.04 以降では削除され、互換用の transitional パッケージのみが残る状態です。新規の環境では timedatectl（systemd-timesyncd）または chrony を使う方法をおすすめします。

参考: Ubuntu Server ドキュメント（About time synchronisation）
“chrony now regularly checks and keeps your local time in sync”
（chrony は定期的に確認し、ローカルの時刻を同期し続けます。）
https://documentation.ubuntu.com/server/explanation/networking/about-time-synchronisation/

権限不足: AccessDenied

エラーメッセージ

An error occurred (AccessDenied) when calling the PutObject operation: Access Denied

原因

「権限がない」という内容ですが、原因はいくつか考えられます。

• IAM ポリシー不足: その操作（例: s3:PutObject）が許可されていない。
• MFA 未認証: ポリシーで MFA が必須なのに、MFA トークンなしでアクセスしている。
• 別の認証情報で実行: 意図しないプロファイルや、以前の認証情報が残っている。

対処

AM ポリシーを変更する前に、まず「現在どの主体として認識されているか」を確認すると切り分けやすくなります。

aws sts get-caller-identity

出力例:

{
    "UserId": "AROA1234567890EXAMPLE:botocore-session-123",
    "Account": "123456789012",
    "Arn": "arn:aws:sts::123456789012:assumed-role/MyRole/botocore-session-123"
}

この Arn を見て、期待した IAM ロール／ユーザーになっているか、スイッチロールに失敗して元のユーザーのままになっていないかを確認します。期待と異なる場合は、プロファイル指定（--profile）や AWS Vault の実行方法を見直すと解決することがあります。

解決しない場合のデバッグ

ここまでのパターンに当てはまらない場合は、詳細なログ（デバッグ情報）から原因を絞り込みます。

–debug で通信内容を確認する

AWS CLI には、リクエストとレスポンスの詳細を表示する --debug オプションがあります。コマンドの末尾に付けて実行すると、どのようなリクエストを送り、AWS からどのような応答（またはエラー）が返ったかを確認できます。

aws s3 ls --debug

出力例（抜粋）:

... botocore.endpoint - DEBUG - Making request for OperationModel(name=ListBuckets) ...
... botocore.parsers - DEBUG - Response: {'Error': {'Code': 'InvalidAccessKeyId', 'Message': '...'}} ...

このログを見ると、通信は成立しているがキーが無効（InvalidAccessKeyId）なのか、そもそも通信がタイムアウトしている（ConnectTimeout）のかを切り分けられます。

まとめ

本記事では、AWS CLI と AWS Vault でよく遭遇するエラーと、その対処を解説しました。Linux（WSL を含む）環境では、GPG や時刻同期といった OS 側の設定が原因になりやすく、まず Vault の問題か CLI の権限・時刻の問題かを切り分けることが解決の近道です。エラーメッセージとデバッグログを手がかりに、原因を順に絞り込んでいくと対処しやすくなります。

• ネストエラーの文言は現行版で変更済み
• サブシェルから exit するか AWS_VAULT を解除
• GPG 系エラーは GPG_TTY の設定で回避
• 時刻ズレは timedatectl で同期、ntpdate は廃止
• AccessDenied はまず get-caller-identity で確認
• 解決しない場合は –debug でログを確認
• Vault か CLI かの切り分けが解決の近道

以上、最後までお読みいただきありがとうございました。