Подтвердить что ты не робот

Bash с AWS CLI - не удалось найти учетные данные

У меня есть сценарий оболочки, который должен загружать некоторые файлы с S3 и монтировать диск ebs. Тем не менее, я всегда получаю "Невозможно найти учетные данные".

Я указал свои учетные данные командой aws configure а команды работают вне сценария оболочки. Может ли кто-нибудь, пожалуйста, сказать мне (желательно подробно), как заставить его работать?

Это мой сценарий

#!/bin/bash

AWS_CONFIG_FILE="~/.aws/config"

echo $1

sudo mkfs -t ext4 $1
sudo mkdir /s3-backup-test
sudo chmod -R ugo+rw /s3-backup-test
sudo mount $1 /s3-backup-test

sudo aws s3 sync s3://backup-test-s3 /s3-backup/test

du -h /s3-backup-test
ipt (short version):

Спасибо за любую помощь!

4b9b3361

ОТВЕТЫ

Ответ 1

sudo изменит каталог $HOME (и, следовательно, ~) на /root и удалит большинство переменных bash, таких как AWS_CONFIG_FILE, из среды. Убедитесь, что вы делаете все с помощью aws как root или как ваш пользователь, не смешивайте.

Убедитесь, что вы сделали sudo aws configure например. И попробовать

sudo bash -c 'AWS_CONFIG_FILE=/root/.aws/config aws s3 sync s3://backup-test-s3 /s3-backup/test'

Возможно, вы захотите удалить все sudo изнутри скрипта и просто sudo сам скрипт.

Ответ 2

Это не обязательно связано с исходным вопросом, но я натолкнулся на это, когда искал соответствующую проблему, поэтому я собираюсь написать ее на случай, если она может помочь кому-то еще. Я настроил aws на конкретного пользователя и протестировал его с помощью sudo -H -u thatuser aws..., но он не работал с awscli 1.2.9, установленным на Ubuntu 14.04:

  % sudo -H -u thatuser aws configure list
        Name                    Value             Type    Location
        ----                    -----             ----    --------
     profile                <not set>             None    None
  access_key                <not set>             None    None
  secret_key                <not set>             None    None
      region                us-east-1      config_file    ~/.aws/config

Мне пришлось обновить его, используя pip install awscli, в котором были pip install awscli новые версии awscli (1.11.93), boto и множество других вещей (awscli docutils botocore rsa s3transfer jmespath python-dateutil pyasn1), но это привело к вещам начиная работать правильно:

  % sudo -H -u thatuser aws configure list
        Name                    Value             Type    Location
        ----                    -----             ----    --------
     profile                <not set>             None    None
  access_key     ****************WXYZ shared-credentials-file
  secret_key     ****************wxyz shared-credentials-file
      region                us-east-1      config-file    ~/.aws/config

Ответ 3

Хотя у вас могут быть ваши учетные данные и файл конфигурации правильно расположенными в ~/.aws, он может не попасть в вашу учетную запись пользователя.

Запустите эту команду, чтобы проверить, установлены ли ваши учетные данные: aws configure list

Чтобы установить учетные данные, запустите эту команду: aws configure и введите учетные данные, указанные в файле ~/.aws/credentials.

Ответ 4

Ответ на случай, если кто-то наткнется на это, основываясь на названии вопроса.

У меня была та же проблема, когда по сообщениям CLI AWS unable to locate credentials.

Я удалил набор учетных credentials [default] из своего файла credentials как не использовал их и не думал, что они необходимы. Кажется, что они есть.

Я тогда преобразовал свой файл следующим образом, и это работало...

[default]
aws_access_key_id=****
aws_secret_access_key=****
region=eu-west-2

[deployment-profile]
aws_access_key_id=****
aws_secret_access_key=****
region=eu-west-2

Ответ 5

Глупый и предостерегающий хвост ржавого стропальщика:

Я определил переменную HOME в своем скрипте как место, где скрипт должен идти для построения платформы.

Эта переменная перезаписала env var, которая определяет пользователей оболочки $HOME. Таким образом, команда AWS не смогла найти ~/.aws/credentials поскольку ~ ссылался не на то место.

Ненавижу это признавать, но надеюсь, что это поможет кому-то сэкономить время.

Ответ 6

Если вы используете файл .aws/config с ролями, убедитесь, что ваш файл конфигурации правильно отформатирован. В моем случае я забыл поставить role_arn = перед arn. Профиль по умолчанию находится в .aws/credentials и содержит идентификатор ключа доступа и секретный ключ доступа идентификатора iam.

Файл конфигурации содержит детали роли:

[profile myrole]
role_arn = arn:aws:iam::123456789012:role/My-Role
source_profile = default
mfa_serial = arn:aws:iam::987654321098:mfa/my-iam-identity
region=ap-southeast-2

Вы можете быстро проверить доступ, позвонив

aws sts get-caller-identity --profile myrole

Если у вас включен MFA, как у меня, вам нужно будет ввести его при появлении запроса.

Enter MFA code for arn:aws:iam::987654321098:mfa/my-iam-identity:
{
    "UserId": "ARABCDEFGHIJKLMNOPQRST:botocore-session-15441234567",
    "Account": "123456789012",
    "Arn": "arn:aws:sts::123456789012:assumed-role/My-Role/botocore-session-15441234567"
}

Ответ 7

Эта ошибка возникала сегодня при запуске aws cli на EC2. В моих ситуациях я мог получить информацию об учетных данных при запуске aws configure list. Однако я работаю в корпоративной среде, которая требует таких вещей, как aws kms decrypt, PROXY. Как только я настрою прокси, информация об учетных данных aws исчезнет.

export HTTP_PROXY=aws-proxy-qa.cloud.myCompany.com:8099
export HTTPS_PROXY=aws-proxy-qa.cloud.myCompany.com:8099

Оказывается, мне также нужно установить NO_PROXY и иметь адрес метаданных ec2 в списке 169.254.169.254. Кроме того, поскольку вы должны проходить через конечную точку s3, у вас также должно быть .amazonaws.com в no_proxy.

export NO_PROXY=169.254.169.254,.amazonaws.com

Ответ 8

Я столкнулся с этим, пытаясь запустить команду aws-cli из root cron.

Поскольку учетные данные хранятся в $ HOME/.aws/credentials, а я инициализировал aws-cli через sudo, $ HOME по-прежнему/home/user/. При запуске из cron $ HOME - это /root/, поэтому cron не может найти файл.

Исправление состояло в том, чтобы изменить $ HOME для конкретной работы cron. Пример:

00 12 * * * HOME=/home/user aws s3 sync s3://...

(в качестве альтернативы можно переместить, скопировать или создать символическую ссылку .aws dir из /home/user/в /root/)