РЕДАКТИРОВАТЬ: Если вы столкнулись с этой проблемой, мы будем признательны за вашу помощь в устранении неполадок. Я обновляю этот комментарий, чтобы лучше понять действия по устранению неполадок.

Исправление проблем

Первым шагом для устранения этой проблемы является определение того, связана ли проблема с самими учетными данными или с интерфейсом командной строки. Чтобы проверить это, попробуйте использовать эти учетные данные в других SDK AWS (javascript, ruby, java и т. Д.). Чтобы помочь с этим, я создал тестовый скрипт, который использует AWS SDK для python и javascript, который доступен здесь: https://github.com/jamesls/aws-creds-test . После клонирования просто запустите make install , make test . Он запросит учетные данные (аналогично интерфейсу командной строки) и вызовет API sts.GetCallerIdentity .

/tmp $ mkdir /tmp/repro-cli-602
/tmp $ cd /tmp/repro-cli-602/
/tmp/repro-cli-602 $ git clone git://github.com/jamesls/aws-creds-test
Cloning into 'aws-creds-test'...
...
/tmp/repro-cli-602 $ cd aws-creds-test/
/tmp/repro-cli-602/aws-creds-test (master u=) $ make install
npm install
[email protected] /private/tmp/repro-cli-602/aws-creds-test
├─┬ [email protected]
...
pip install -r requirements.txt
Requirement already satisfied: botocore<2.0.0,>=1.5.0 in /usr/local/lib/python2.7/site-packages (from -r requirements.txt (line 1))
...



/tmp/repro-cli-602/aws-creds-test (master u=) $ make test
./test-creds.sh
Testing python...
Access Key:
Secret Access Key:
AKID   hash: 4e7c36343646e1fa7495092bffcd4b9b7dd00f2f5014a189ab81f326e6472a62
AKID length: 20

SAK    hash: 941a655993caccb1a1218883b97a88b6f41762c6d03902f1cdd1e2a5de5fd82e
SAK  length: 40
Successfuly made an AWS request with the provided credentials.

Testing javasript...
Access Key: ********************
Secret Access Key: ****************************************
AKID   hash: 4e7c36343646e1fa7495092bffcd4b9b7dd00f2f5014a189ab81f326e6472a62
AKID length: 20


SAK    hash: 941a655993caccb1a1218883b97a88b6f41762c6d03902f1cdd1e2a5de5fd82e
SAK  length: 40
Sucessfully made an AWS request with the provided credentials.

Тем, кто сталкивается с этой проблемой, запустите тестовый сценарий и поделитесь результатами.

Это должно помочь нам лучше понять, где возникает эта проблема:

• Если приведенный выше сценарий подходит как для python, так и для javascript, но не работает при использовании интерфейса командной строки, скорее всего, это проблема интерфейса командной строки.
• Если сценарий не работает для python, но проходит для javascript, вероятно, проблема с ботокором (который использует CLI).
• Если приведенный выше сценарий не работает как для python, так и для javascript, вероятно, проблема с фактическими учетными данными.

Заранее благодарим всех, кто может помочь нам в устранении этой проблемы. Дайте мне знать, если возникнут вопросы.

Вот как это выглядит:

thomas<strong i="6">@iMac</strong>:~ $ echo $AWS_ACCESS_KEY_ID
AKIAXXXXXXXXXXXXXXXX
thomas<strong i="7">@iMac</strong>:~ $ echo $AWS_SECRET_ACCESS_KEY
abcaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa+0
thomas<strong i="8">@iMac</strong>:~ $ aws configure list
      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                <not set>             None    None
              env    AWS_ACCESS_KEY_ID
              env    AWS_SECRET_ACCESS_KEY
    region                eu-west-1              env    AWS_DEFAULT_REGION

Есть новости по этой проблеме? Я также сталкиваюсь с этой ошибкой, и мой файл учетных данных не изменился.

У меня похожая проблема. Плагин Jenkins s3 может помещать объект, используя мои учетные данные, но aws-cli выдает мне ошибки ниже.

aws s3 cp s3://my-bucket/folder/test.txt test.txt
A client error (Forbidden) occurred when calling the HeadObject operation: Forbidden Completed 1 part(s) with ... file(s) remaining

aws s3api get-object --bucket my-bucket --key folder/test.txt test.txt
A client error (SignatureDoesNotMatch) occurred when calling the GetObject operation: The request signature we calculated does not match the signature you provided. Check your key and signing method.

Я столкнулся с той же проблемой. Если я придумываю секрет, это дает мне другую ошибку (AuthFailure).

[[email protected]]]$ aws configure list
      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                <not set>             None    None
access_key     ****************AMKA              env    AWS_ACCESS_KEY_ID
secret_key     ****************jPU2              env    AWS_SECRET_ACCESS_KEY
    region                us-west-2              env    AWS_DEFAULT_REGION

Это меня полностью останавливает. Я могу кое-что сделать с помощью утилит ec2-blah-stuff, указав сертификаты x509, но в справке сказано, что это устарело, поэтому я не хочу зависеть от этого. Любая помощь по устранению неполадок или то, что действительно будет оценено.

Первый шаг - убедиться, что ваши ключи доступа / секретные ключи действительно действительны. Несколько вещей, которые стоит попробовать:

• Работают ли эти же учетные данные доступа / секретного ключа с другими инструментами? (SDK для java / javascript / ruby ​​/ python?)
• У вас работают другие команды, кроме "aws s3"? "Aws ec2 description-instance" по-прежнему генерирует ошибки аутентификации?

Они не работают с другими инструментами (например, ec2-description-instance).

Я думаю, что у меня есть соответствующие права, так как использование сертификатов работает. Чтобы убедиться, что это не рабочая станция, я создал экземпляр Amazon Linux и использую прилагаемую к нему версию awscli, но получаю то же сообщение.

Тоже проблема для меня. Я использую его в контейнере докеров, созданном с использованием того же файла Dockerfile.
Он отлично работает при сборке на EC2, но не работает при локальной сборке на бродячем корпусе coreos.

Похоже, проблема в самих учетных данных. Я дважды проверил это и не могу воспроизвести эту проблему. Дважды проверьте учетные данные на странице учетных данных безопасности . Если кто-то может предоставить точный набор шагов, демонстрирующих проблему, я буду рад еще раз взглянуть на нее.

Просто это случилось со мной, и это было результатом того, что мое системное время слишком сильно отключилось, хотя оно не сообщало об этом. Запустил ntpdate на pool.ntp.org и решил эту проблему для меня.

Если вы получаете эту ошибку при настройке кредита с использованием переменной env, попробуйте sudo

Если вы находитесь на виртуальной машине, убедитесь, что время ОС вашего хоста совпадает со временем гостевой ОС. Если это не так, вы получите описанную вами ошибку.

Очень похожая ошибка возникает у меня с хорошими учетными данными, когда я перечисляю корзину, в которой есть _lot_ ключей. Вот ошибка:

A client error (SignatureDoesNotMatch) occurred when calling the ListObjects operation: The request signature we calculated does not match the signature you provided. Check your key and signing method.

Вот мой результат из aws configure list

      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                <not set>             None    None
access_key     ****************4UNA shared-credentials-file
secret_key     ****************MNOG shared-credentials-file
    region                <not set>             None    None

Обратите внимание, что эти учетные данные отлично работают с другими aws , и на самом деле эта list выполняется в течение длительного времени (более часа), прежде чем выйдет из строя с этой ошибкой. У меня есть файл с более чем 82000 строк вывода из команды, которая в конечном итоге не удалась.

У меня возникла эта проблема, и если я просто сплю свой сценарий на секунду и попробую снова, он пройдет. Это похоже на то, что он дросселируется и возвращает неправильную ошибку или что-то в этом роде.

Я тоже могу сообщить об этой проблеме. При попытке загрузить файл размером 11 ГБ с помощью aws cp foo s3: // mybucket / foo / bar я получаю различные ошибки, например:

A client error (SignatureDoesNotMatch) occurred when calling the UploadPart operation: The request signature we calculated does not match the signature you provided. Check your key and signing method.

и

Max retries exceeded with url: /***REDACTED***?partNumber=196&uploadId=B2viwGFF4Lmq5itbs8ipqwBExx0BWGRm3gkG_D5EYTiU8uEO_tmUT.d.i7BcgPnP5npZa.OW7yMfJ3ZhhLJD61zP7EVv.5.ZftCJQbKNdkEBeijGBqWlrxz4vMx3B05Q (Caused by <class 'socket.gaierror'>: [Errno -2] Name or service not known)

Я проверил правильность своего системного времени. Я также заметил значительную медленность (на уровне тайм-аута HTTP-запросов) в той же системе при загрузке, так что проблема с регулированием звучит разумно. Он также отлично работает для загрузки небольших файлов с одинаковыми учетными данными и использования веб-консоли с одного и того же компьютера, так что это действительно проблема с aws-cli.

Это случилось со мной и с aws-cli 1.5.5, обновление aws-cli до 1.6.2 решило эту проблему.

Бывает у меня с 1.6.2

Это случилось со мной сегодня. Для меня это в новинку. Я использовал awl-cli в течение нескольких месяцев без проблем и без изменений учетных данных AFAIK.

$ aws configure --profile ye list
      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                       ye           manual    --profile
access_key     ****************ERMQ shared-credentials-file    
secret_key     ****************E8Id shared-credentials-file    
    region                us-east-1      config-file    ~/.aws/config

Я считаю, что эта проблема теперь устранена через https://github.com/boto/botocore/pull/388 и будет доступна в следующем выпуске AWS CLI.

@jamesls подтвердил исправление в версии awscli 1.6.4 . Я использовал 1.5.4 . Спасибо!

У меня эта проблема возникает в новой системе Ubuntu.

A client error (SignatureDoesNotMatch) occurred when calling the PutObject operation: The request signature we calculated does not match the signature you provided. Check your key and signing method.

Установил aws-cli через pip

$ pip list
ansible (1.5.4)
apt-xapian-index (0.45)
argparse (1.2.1)
awscli (1.6.5)
bcdoc (0.12.2)
botocore (0.76.0)
chardet (2.0.1)
Cheetah (2.4.4)
cloud-init (0.7.5)
colorama (0.2.5)
configobj (4.7.2)
docutils (0.11)
html5lib (0.999)
httplib2 (0.8)
Jinja2 (2.7.2)
jmespath (0.5.0)
jsonpatch (1.3)
jsonpointer (1.0)
Landscape-Client (14.01)
MarkupSafe (0.18)
mercurial (2.8.2)
oauth (1.0.1)
PAM (0.4.2)
Pillow (2.3.0)
pip (1.5.4)
prettytable (0.7.2)
pyasn1 (0.1.7)
pycrypto (2.6.1)
pycurl (7.19.3)
Pygments (1.6)
pyinotify (0.9.4)
pyOpenSSL (0.13)
pyserial (2.6)
python-apt (0.9.3.5)
python-dateutil (2.3)
python-debian (0.1.21-nmu2ubuntu2)
PyYAML (3.10)
requests (2.2.1)
roman (2.0.0)
rsa (3.1.2)
setuptools (3.3)
six (1.5.2)
Sphinx (1.2.2)
ssh-import-id (3.21)
Twisted-Core (13.2.0)
urllib3 (1.7.1)
wsgiref (0.1.2)
zope.interface (4.0.5)

Есть идеи, как это исправить?

Мое решение заключалось в том, чтобы поспать на несколько секунд, а затем попробовать еще раз, но он
Похоже, что может быть обновление для инструмента, который также это исправляет.

Во вторник, 2 декабря 2014 г., в 3:38, Марк Вулф [email protected] написал:

У меня эта проблема возникает в новой системе Ubuntu.

Ошибка клиента (SignatureDoesNotMatch) произошла при вызове операции PutObject: рассчитанная нами подпись запроса не соответствует предоставленной вами подписи. Проверьте свой ключ и метод подписи.

Установил aws-cli через pip

список $ pip
анзибль (1.5.4)
apt-xapian-index (0,45)
argparse (1.2.1)
awscli (1.6.5)
bcdoc (0.12.2)
ботокор (0,76,0)
Chardet (2.0.1)
Гепард (2.4.4)
облако-init (0.7.5)
колорама (0,2,5)
configobj (4.7.2)
документация (0.11)
html5lib (0,999)
httplib2 (0,8)
Jinja2 (2.7.2)
jmespath (0.5.0)
jsonpatch (1.3)
jsonpointer (1.0)
Пейзаж-Клиент (14.01)
MarkupSafe (0,18)
ртутный (2.8.2)
oauth (1.0.1)
PAM (0.4.2)
Подушка (2.3.0)
пип (1.5.4)
красивый (0.7.2)
пясн1 (0.1.7)
пикрипто (2.6.1)
pycurl (7.19.3)
Пигменты (1.6)
pyinotify (0.9.4)
pyOpenSSL (0,13)
пизериал (2.6)
python-apt (0.9.3.5)
python-dateutil (2.3)
python-debian (0.1.21-nmu2ubuntu2)
PyYAML (3.10)
запросы (2.2.1)
римский (2.0.0)
rsa (3.1.2)
setuptools (3.3)
шесть (1.5.2)
Сфинкс (1.2.2)
идентификатор импорта-ssh (3,21)
Витой сердечник (13.2.0)
urllib3 (1.7.1)
wsgiref (0.1.2)
zope.interface (4.0.5)

Есть идеи, как это исправить?

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/aws/aws-cli/issues/602#issuecomment -65198065.

@wolfeidau и да, я заговорил слишком рано. Локально установленный пакет awscli снова выдает ошибки SignatureDoesNotMatch. Ой!

A client error (SignatureDoesNotMatch) occurred when calling the DeregisterInstancesFromLoadBalancer operation: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.

The Canonical String for this request should have been
'POST
/

host:elasticloadbalancing.us-east-1.amazonaws.com
user-agent:aws-cli/1.6.5 Python/2.7.8 Darwin/13.4.0
x-amz-date:20141203T015747Z

host;user-agent;x-amz-date
1d9dafbf4bfa9b1225d91bdbf99d8645503484d174b9094e4c3af637e6664b5b'

The String-to-Sign should have been
'AWS4-HMAC-SHA256
20141203T015747Z
20141203/us-east-1/elasticloadbalancing/aws4_request
5a56d12a4920502f4124e37a92aad475c36edda93d9865871e6a4fe1e49045c3'

Эта проблема возникает только при повторной попытке запроса? Или это происходит каждый раз, когда вы запускаете команду deregister-instance-from-load-balancer?

@jamesls теперь такое случается каждый раз :(

Я знаю, что эта проблема закрыта, но хотел бы поделиться, что вы можете увидеть эту ошибку при работе на виртуальной машине, которая находится в спящем режиме. В таких случаях системные часы не всегда догоняют, если вы используете Ubuntu. Просто обновите время исправления (например, sudo ntpdate -s time.nist.gov).

привет, есть ли какое-нибудь окончательное исправление по этому поводу?

+1

Используя версию 1.7.8 интерфейса командной строки, я обнаружил ту же ошибку SignatureDoesNotMatch при попытке сделать следующее:
$ aws iam list-users

И получение для этого AuthFailure:
$ aws ec2 describe-security-groups

После удаления моих ключей и попытки использования новых обе команды работают.

Это старый секретный ключ доступа, который мог быть причиной моих проблем, обратите внимание на символы процента, плюс и косую черту: H2J7 / oT3Fib15SwFVB1s3EnTCmg + SC7wF7qoP + dw%

: +1: @gsterndale. Мой ключ доступа с % не работал. Пришлось сгенерировать новые ключи.

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

По правде говоря, все мои проблемы с ключами подписи растворились, когда я переключился с запуска команды на машине ubuntu вместо локальной установки Mac Homebrew.

Я очень новичок в AWS, сразу столкнулся с этой проблемой на узле js

              ^

SignatureDoesNotMatch: рассчитанная нами подпись запроса не соответствует предоставленной вами подписи. Проверьте свой ключ доступа к AWS и метод подписи. Проконсультируйтесь с
документацию по тискам для получения подробной информации.

Каноническая строка для этого запроса должна была быть
'ПОЧТА
/

хост: email.us-west-2.amazonaws.com
x-amz-content-sha256: 89cdc817a829111278fbed35aacc694db71669f3845874beaecaf00ff2be1a39
x-amz- дата: 20150809T053346Z

хост; x-amz-content-sha256; x-amz-date
89cdc817a829111278fbed35aacc694db71669f3845874beaecaf00ff2be1a39 '

String-to-Sign должен был быть
'AWS4-HMAC-SHA256
20150809T053346Z
20150809 / us-west-2 / ses / aws4_request
0b908b0248bae550b814b37629a418707742416377816b5a5e78e1897b72293e '

+1

У меня эта проблема возникает для всех команд aws s3 (awscli 1.8.6 в ubuntu 14.04 LTS).
Есть какие-нибудь известные решения? Я попытался удалить свой файл учетных данных и запустить aws configure, перезагрузить, переустановить awscli.

@mcobzarenco , вы пробовали новые ключи?

@gsterndale Я видел выше комментарий о наличии слэшей в старых ключах, но это не так, и мои ключи были недавно сгенерированы (в июне 2015 года). У меня эта проблема только на AWS Ubuntu 14.04 LTS. На моем ноутбуке (14.04) awscli (та же версия) работает нормально.

@mcobzarenco Я не думаю, что дело в возрасте ключей, а в их специальных символах. Когда я изначально создавал ключи, в них были символы процента, плюс и косая черта. При отладке проблемы я попытался удалить и создать новые ключи. К счастью, в этих новых не было ни одного из этих персонажей, и они работают.

только что столкнулся с этой проблемой на ubuntu. Когда я ввел ключи через cli, он сохранил их в ~ / .aws / config, но убрал символ «+». Ручное редактирование файла с добавлением знака «+» позволило мне подключиться.

@gsterndale Спасибо за совет, я могу подтвердить, что создание нового ключа, не содержащего + , тоже сработало для меня. Решение @stebl хорошо, если ключи заменять неудобно.

Я столкнулся с той же проблемой при использовании AWS SDk с node js. Чтобы решить эту проблему, я выполнил точно такие же шаги, упомянутые здесь.
http://aws.amazon.com/developers/getting-started/nodejs/

Я думаю, что AWS SDK разработан для конкретной версии node js, несоответствие в node js приведет к таким проблемам.

У меня такая же проблема, и да, она была решена с помощью ключа без специальных символов ( + в моем конкретном случае)

Мы столкнулись с этой ошибкой (где одна машина могла описывать экземпляры с помощью awscli, но другая получила ошибку отказа в доступе с тем же ключом доступа. На последнем компьютере пользователи списка iam выдавали эту ошибку SignatureDoesNotMatch). Устранено исправлением системных часов на машине с проблемой.

Как сказал @tukaaa , есть ошибка, если секретный ключ доступа содержит не алфавитный символ (например, +). Я думаю, плохой побег куда-то ;-(

@ebuildy Можете ли вы подтвердить, на какой версии интерфейса командной строки вы это видите ( aws --version )? Если это причина версии интерфейса командной строки, я снова открою эту проблему.

Я получаю это на aws-cli/1.9.1 Python/3.5.0 Windows/7 botocore/1.1.8

У меня была такая же проблема с одним ящиком Windows, используя ключ без каких-либо не-альфа-символов. Я проверил, что это не ошибка копирования / вставки, используя тот же буфер вставки в другом поле. Удаление / повторная установка AWS cli и удаление файлов учетных данных / конфигурации, а затем повторный запуск конфигурации aws исправили его.

Только что видел это на aws-cli/1.10.3 Python/2.7.10 Darwin/14.5.0 botocore/1.3.25 .

Исправлено восстановление ключа без специальных символов. FWIW в моем случае специальный символ был / и я использовал файл INI.

Хорошо, откроем, мы разберемся с этим.

@ Я могу подтвердить, что у меня такая же проблема, как описывает @gsterndale .

aws --version
aws-cli/1.10.6 Python/2.7.11 Linux/3.10.0-327.4.5.el7.x86_64 botocore/1.3.28

Но мой ключ не содержит специальных символов.

Я получаю ту же ошибку при использовании модуля узла s3-cli. Мой секретный ключ содержит [ .

Я наконец выяснил, что случилось. Я случайно добавил к клавишам несколько символов. Вот в чем причина.

Я столкнулся с этой проблемой по следующему сценарию; как на rhel7, так и на ubuntu. Я думаю, что это как-то связано с не-альфа-символами, как упоминали другие

• ведро s3 защищено для одной роли
• Экземпляр ec2 с указанной ролью должен принять ту же роль перед доступом к защищенному ведру s3

aws sts assume-role --role-arn <role_name> --role-session-name default --output json --query Credentials > credentials.json
export AWS_ACCESS_KEY_ID=`sed -n 's/.*"AccessKeyId": "\(.*\)"/\1/p' credentials.json`
export AWS_SECRET_ACCESS_KEY=`sed -n 's/.*"SecretAccessKey": "\(.*\)",/\1/p' credentials.json`
export AWS_SESSION_TOKEN=`sed -n 's/.*"SessionToken": "\(.*\)",/\1/p' credentials.json`

Я считаю, что что-то с --query испортило учетные данные. При запуске команд вручную и копировании и вставке значений; затем установив переменные среды, казалось, что все работает нормально.

У меня была такая же проблема при запуске awscli версии 1.10 на Mac (устанавливается через pip) по сравнению с Ubuntu (образ Amazon) awscli версии 1.2.9. aws configure --profile user создает две разные конфигурации для каждой. Версия 1.10 создала два файла: конфигурацию и учетные данные. Версия 1.2.9 только что создала файл конфигурации (но с учетными данными). Когда я удалил учетные данные и файл конфигурации, созданный версией 1.10, и скопировал файл конфигурации, созданный версией 1.2.9, все заработало, даже со специальными символами и запустив awscli версии 1.10. Конфигурационный файл, созданный версией 1.2.9:

[profile FOO0]
aws_secret_access_key = FOO1
aws_access_key_id = FOO2
output = FOO3
region = FOO4

Могу подтвердить, что это связано с не буквенно-цифровыми символами.

У меня такая же проблема с секретным ключом, содержащим +. Однако я не являюсь владельцем учетной записи S3 и не могу легко создать новую. Кто-нибудь нашел какое-нибудь исправление, кроме создания нового ключа без специальных символов?

tl; dr Решение: повторно воссоздайте учетные данные, ПОКА ваш aws_secret_access_key НЕ содержит не буквенно-цифровых символов ... в моем случае aws_secret_access_key содержал + (знак плюса)

Я только что сделал новую установку ... такая же проблема ... это на Ubuntu ... это не проблема локальной ОС, это проблема с Amazon API, поэтому игнорируйте другие комментарии, в которых говорится, что переход с OSX исправляет

aws ec2 описать экземпляры

Произошла ошибка (AuthFailure) при вызове операции DescribeInstances: AWS не удалось проверить предоставленные учетные данные для доступа

------------------------------------------------

aws ec2 описать группы безопасности

Произошла ошибка (AuthFailure) при вызове операции DescribeSecurityGroups: AWS не удалось проверить предоставленные учетные данные для доступа

------------------------------------------------

aws ecr get-login

Произошла ошибка (InvalidSignatureException) при вызове операции GetAuthorizationToken: рассчитанная нами подпись запроса не соответствует предоставленной вами подписи. Проверьте свой ключ доступа к AWS и метод подписи. За подробностями обращайтесь к сервисной документации.

Каноническая строка для этого запроса должна была быть
'ПОЧТА
/

тип содержимого: приложение / x-amz-json-1.1
хост: ecr.us-east-1.amazonaws.com
x-amz- дата: 20160615T182955Z
x-amz- target: AmazonEC2ContainerRegistry_V20150921.GetAuthorizationToken

тип содержимого; хост; x-amz-date; x-amz-target
44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a '

String-to-Sign должен был быть
'AWS4-HMAC-SHA256
20160615T182955Z
20160615 / us-east-1 / ecr / aws4_request
86c2e3c850acd6765a1ca6aa626c6e9a6c85284f3954f45e170f51b5b89961c7 '

------------------------------------------------

список пользователей aws iam

Произошла ошибка (SignatureDoesNotMatch) при вызове операции ListUsers: рассчитанная нами подпись запроса не соответствует предоставленной вами подписи. Проверьте свой ключ доступа к AWS и метод подписи. За подробностями обращайтесь к сервисной документации.

Каноническая строка для этого запроса должна была быть
'ПОЧТА
/

хост: iam.amazonaws.com
x-amz- дата: 20160615T183516Z

хост; x-amz-date
b6359072c78d70ebee1e81adcbab4f01bf2c23245fa365ef83fe8f1f955085e2 '

String-to-Sign должен был быть
'AWS4-HMAC-SHA256
20160615T183516Z
20160615 / us-east-1 / iam / aws4_request
ad9f7581f0bf25ecae56355a6c96b60f3dc3188efbbdb3d0d4806e9f2c5cf8a9 '

------------------------------------------------

aws --version
aws-cli / 1.10.38 Python / 2.7.11 + Linux / 4.4.0-22-общий ботокор / 1.4.28

------------------------------------------------

кошка /root/.aws/credentials
[дефолт]
aws_access_key_id = AKIAJ7FCEUVVSGX7KZGQ
aws_secret_access_key = inCv47xj + eGE2C9crwilZJmKZg6vN / 3JTh5LDaNb

    Notice the plus sign ( + ) in above aws_secret_access_key   !!!!

   aws only works when aws_secret_access_key does NOT contain non-alpha chars

------------------------------------------------

РЕШЕНИЕ :
После удаления и создания новых учетных данных
где aws_secret_access_key НЕ имело знака плюса (+), все было хорошо выше, команды начали работать ОК

У меня такая же проблема. Повторное создание учетных данных до тех пор, пока у меня не будет специальных символов, у меня сработало.

Я обнаружил, что когда я скопировал и вставил учетные данные, на конце у них были символы ^ M, которые вызывали ошибку.

Получение секретного ключа без + исправило это и для меня ...

Примечание. Если вы видите эту проблему в докере (boot2docker VM'd), возможно, часы виртуальной машины не синхронизированы.
См. Http://stackoverflow.com/questions/24551592/how-to-make-sure-dockers-time-syncs-with-that-of-the-host

У меня такая же проблема. Что делать, если у меня нет разрешений на повторное создание учетных данных ... какие-либо возможные исправления другими способами?

ОБНОВЛЕНИЕ: я исправил это, запустив rm -rf .aws/cli/cache/

У меня тоже сейчас эта проблема. При попытке взять на себя роль

Версия:
aws-cli/1.11.17 Python/2.7.10 Darwin/16.1.0 botocore/1.4.74

Изменить: попытался также обновить снова, та же проблема:
aws-cli/1.11.18 Python/2.7.12 Darwin/16.1.0 botocore/1.4.75

Вывод:

Assuming role arn:aws:iam::XXXXXXXX:role/XXXX-staging using profile default

An error occurred (SignatureDoesNotMatch) when calling the AssumeRole operation: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.

The Canonical String for this request should have been
'POST
/

host:sts.amazonaws.com
x-amz-date:20161118T102600Z

host;x-amz-date
41db88384d54dc0783e616aa0662ebffce8832b35025195052029a5dc0e33c0e'

The String-to-Sign should have been
'AWS4-HMAC-SHA256
20161118T102600Z
20161118/us-east-1/sts/aws4_request
786b3d624f5aeea9ffcb2b802b177a4c2aebbfed608a2464ee684c6972bc6bc6'

Та же проблема по-прежнему существует с последней (актуальной) версией AWS CLI. Я только что обновил свой интерфейс командной строки 1.8.3 до 1.11.19 - и не смог выполнять какие-либо команды с новым пользователем / ключами, которые я создал. Пришлось повторить цикл около 5 ключей, прежде чем я получил пару, в которой секретный ключ не содержал никаких небуквенных символов. Однажды я наткнулся на такую ​​пару - CLI работает нормально.

Очень раздражает - я бы хотел, чтобы Amazon не генерировал недействительные ключи, которые они не могут обработать ...

@ mpopova-yottaa вы пробовали полностью очистить кеш awe-cli? Попробуйте удалить весь каталог ~/.aws (сделайте копию файлов конфигурации / учетных данных)

aws ec2 describe-instances запускается для меня, но при попытке создать стек формирования облаков:

`` `Исключение в потоке" main "com.amazonaws.services.cloudformation.model.AmazonCloudFormationException: рассчитанная нами подпись запроса не соответствует предоставленной вами подписи. Проверьте свой ключ доступа к AWS и метод подписи. За подробностями обращайтесь к сервисной документации.

Каноническая строка для этого запроса должна была быть
'ПОЧТА
/

amz-sdk-invocation-id: 18d13b66-80ae-f676-c0cf-dbf875edb1aa
amz-sdk- retry : 3/345/470
хост: cloudformation.us-west-1.amazonaws.com
пользовательский агент: aws-sdk-java / 1.11.20 Mac_OS_X / 10.10.5 Java_HotSpot (TM) _64-Bit_Server_VM / 25.91-b14 / 1.8.0_91
x-amz- дата: 20161127T194448Z

amz-sdk-invocation-id; amz-sdk-retry; host; user-agent; x-amz-date
aca0973fb4ac4029ec038d9c80b4afa23b6d305822b10e6bc32751ee1bd311d5 '

String-to-Sign должен был быть
'AWS4-HMAC-SHA256
20161127T194448Z
20161127 / us-west-1 / cloudformation / aws4_request
cb0286a8727afcc465171ab991accde0aaa7210e160a9ba3196e2a5e4305f428 '(Сервис: AmazonCloudFormation; Код состояния: 403; Код ошибки: SignatureDoesNotMatch; Идентификатор запроса: f52abbd4-b4d9-11e6-b989-b989)

config details:

`$: aws --version`           >>       `aws-cli/1.11.21 Python/2.7.12 Darwin/14.5.0 botocore/1.4.78`

`$: aws configure list`     >>
```   Name                Value                Type     Location
      ----                   -----                  ----        --------
profile                    not set>             None    None
access_key     ****************RTSA                env
secret_key     ****************UC3r                  env
region                us-west-1              env       AWS_DEFAULT_REGION

Секретный ключ содержит только буквы и цифры, поэтому я застрял.

@ aebrow4 Это в кеш-памяти для awe-cli. Попробуйте удалить: .aws/cli/cache/

@cultavix нет cli внутри .aws

Я получил эту ошибку при запуске aws glacier upload-archive с --archive-description "`date`" . Когда я использую --archive-description "`date +%Y/%m/%d`" он работает нормально, так что, похоже, есть какая-то проблема с выходом.

У меня была аналогичная проблема:

λ aws s3 sync s3://foo-bar-assets/ . --exclude "*/*.mp4" --exclude "*.mp4" fatal error: An error occurred (SignatureDoesNotMatch) when calling the ListObjects operation: The request signature we calculated does not match the signature you provided. Check your key and signing method.

Я попытался синхронизировать время с сервером NTP (успешно), но это не решило проблему. Регенерируя ключи, пока у меня не был исправлен набор без специальных символов.

λ aws --version aws-cli/1.11.16 Python/2.7.9 Windows/8 botocore/1.4.73

У меня такая же проблема с использованием awscli и образца кода Python (boto3).
Обратите внимание, что я использую хранилище объектов IBM, совместимое с S3 api, я могу перечислить сегменты и их содержимое, но не могу загрузить (как для кода pyhton, так и для cli).
Я протестировал сценарий с ruby aws-sdk и он отлично работает (загрузка / загрузка).
- конфигурация
aws-cli/1.2.9 Python/3.4.3 Linux/3.19.0-33-generic

Просто у меня возникла такая же проблема со сценарием, который я использовал в течение нескольких месяцев для размещения многокомпонентных загрузок в Glacier. Можно внести штраф через aws cli, поэтому учетные данные по-прежнему работают, но скрипт с использованием boto3 не работает с:

«botocore.exceptions.ClientError: Произошла ошибка (InvalidSignatureException) при вызове операции InitiateMultipartUpload: рассчитанная нами подпись запроса не соответствует предоставленной вами подписи. Проверьте свой секретный ключ доступа AWS и метод подписи. Подробности см. в документации по сервису».

aws --version есть
aws-cli / 1.11.38 Python / 2.7.10 Darwin / 15.6.0 ботокор / 1.5.1

(да, я обновил все, думая, что может решить проблему ... не повезло.)

получение новой пары ключей без каких-либо специальных символов (в моем случае это было + ) устранило проблему для меня

еще одно подтверждение здесь неправильной обработки + в секретном ключе.

Всем привет, вот сценарий, который я использовал, чтобы попытаться воспроизвести эту проблему: https://gist.github.com/jamesls/00ef7fcc0ac39ba8b06956d165c42f6d . Вот что делает сценарий:

• Создает новую пару access_key / secret_key через aws iam create-access-key в цикле до тех пор, пока не найдет учетные данные с символом + или / .
• Он создает новый профиль testcreds с этими вновь созданными учетными данными.
• Он пытается вызвать различные команды интерфейса командной строки AWS, чтобы эти учетные данные работали.

Это происходит в бесконечном цикле, пока вызов API не завершится ошибкой. Пока мне не удалось заставить его потерпеть неудачу. У меня работают секретные ключи с + и / .

На этом этапе мы подтвердили, что определенно можно использовать secret_keys с + или / поэтому я не думаю, что основная причина в чем-то столь же простом, как ошибка в нашем коде подписи. которая прерывается, когда присутствует + . Перечитывая комментарии в этой цепочке, возможно, проблема связана с тем, как учетные данные вводятся в файл ~/.aws/config или ~/.aws/credentials . Возможно, существует какая-то специфическая для платформы вещь, которая изменяет символы, содержащие + или / .

Поэтому для тех, кто все еще сталкивается с этой проблемой, было бы очень полезно, если бы вы могли предоставить дополнительную информацию:

1. Как вы получаете учетные данные (копирование / вставка с консоли, aws iam create-access-key , файл CSV с консоли и т. Д.)?
2. Как вы настраиваете интерфейс командной строки для использования этих учетных данных? Вы запускаете aws configure и вводите значения при появлении запроса? Вы делаете это программно, запустив aws configure set ? Вы вручную редактируете ~/.aws/config и / или ~/.aws/credentials ? Установка различных переменных AWS_* env?

Бонусы, которые были бы еще более полезными, если бы это было возможно:

1. Если вы используете другие SDK, будут ли эти учетные данные, которые не работают в интерфейсе командной строки, работать с другими SDK AWS?
2. Если у вас есть тестовая учетная запись или тестовый пользователь IAM, не даст ли вам запустить скрипт, который я использую для тестирования ?

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

У меня все еще есть эта проблема. Чтобы ответить на ваши вопросы:
Созданы учетные данные в консоли amazon и вырезаны / вставлены в ~ / .aws / credentials (отредактированы с помощью emacs на Mac)

Судя по устранению неполадок, которое я сделал до сих пор (и я новичок в этом ...), «Каноническая строка» верна, но «Строка для подписи» неверна, имея другую последнюю строку. Т.е. когда я печатаю возвращаемое значение auth.py string_to_sign, число, полученное из 'sha256 (canonical_request.encode (' utf-8 ')). Hexdigest ())', отличается от числа, указанного в возвращаемой ошибке "Строка -to-Sign должен был быть ".

В моих учетных данных нет специальных символов, и они работают при использовании других инструментов, например CrossFTP (который я не хочу использовать !!!)

Приветствуются любые идеи!

@ samato88 , похоже, это другая проблема. Если бы вы могли поделиться какой-либо информацией об отладке (обязательно удалите любую конфиденциальную информацию), это помогло бы.

Secret_access_key не влияет на string_to_sign. Когда мы подписываем запрос, мы берем HTTP-запрос, который собираемся отправить, конвертируем его в строку (т.е. строку ot sign), а затем, используя секретный ключ, мы подписываем эту строку секретным ключом (пропуская несколько подробности здесь). Таким образом, любые проблемы со строкой для подписи будут отделены от этой проблемы.

Не могли бы вы открыть другую проблему и предоставить вывод --debug (или включить полный запрос и сообщение об ошибке из службы)? Мы будем счастливы разобраться в этом для вас.

Спасибо jamesls - я открыл отдельный выпуск по адресу:
https://github.com/aws/aws-cli/issues/2474

Любые идеи очень ценятся.

Если системное время отстает более чем на 5 минут, вы не сможете использовать интерфейс командной строки.

просто беги ... sudo ntpdate -s time.nist.gov

затем попробуйте еще раз

У меня была такая же проблема, мой секретный ключ содержит знак "+". Я удалил свой файл .aws / credentials и повторно запустил aws configure. После этого мой запрос в очередь sqs для получения сообщения сработал.

Спасибо @ AlexParra03 . У меня была такая же проблема, и ваши комментарии помогли мне решить .... :-)

@robotzero вы помните, как вы aws configure а затем скопировали / вставили значения из веб-консоли?

Да, я запустил aws configure и скопировал вставленные значения.

Да, у меня в секрете был знак +, который до сих пор вызывал эту ошибку. Создание новых ключей без специальных символов устранило проблему.

aws --version
aws-cli / 1.11.78 Python / 3.6.1 Дарвин / 15.6.0 ботокор / 1.5.41

В моем секрете были + и /. Секреты без них решили проблему для меня.

Также была эта проблема.

$ aws --version
aws-cli/1.11.44 Python/3.5.3 Linux/4.10.0-19-generic botocore/1.5.7

$ lsb_release -sd 
Ubuntu 17.04

Имел "+" в учетных данных. Решилось восстановлением ключа доступа без них. В качестве примечания: "/" - хороший символ.

@adityanatraj @shwetapurushe @damienrj, вы все можете здесь ответить на эти вопросы? На этом этапе мы пытаемся получить больше информации о вашей среде и о том, как вы вводите учетные данные. Как упоминалось в этом комментарии, создание секретного ключа с помощью + не воспроизводит проблему для нас, поэтому, возможно, это связано с комбинацией вашей среды и / или того, как вы вводите учетные данные.

Другими словами, нам нужно больше информации от людей, чтобы мы могли выяснить, что происходит.

@jamesls

1. Как я получил учетные данные?

Я получил учетные данные, скопировав их с веб-консоли.

1. Как мне настроить CLI для их использования?

Я вручную создал два файла:

~ / .aws / config

[default]
region = us-east-1
output = json

~ / .aws / учетные данные

[default]
aws_access_key_id = ACCESS_KEY_HERE 
aws_secret_access_key = SECRET_ACCESS_KEY_THAT_BREAKS_WITH_A_+_SIGN

Извините, я не могу помочь с вопросами о бонусах, так как я очистил свои ключи доступа, содержащие знаки "+", поэтому проблема не проявляется.

@adityanatraj спасибо, каждый бит помогает.

Следующий шаг, который поможет нам в устранении неполадок, - это выяснить, проблема ли это только в интерфейсе командной строки или проблема с самими учетными данными. Для тех, кто все еще сталкивается с этой проблемой, было бы действительно полезно, если бы вы могли попробовать эти учетные данные в других SDK AWS. Чтобы помочь с этим, я собрал образец репо / скрипта, который упрощает эту задачу, если вы не хотите настраивать это самостоятельно: https://github.com/jamesls/aws-creds-test . Просто клонируйте репо и запустите make install , make test .

/tmp $ mkdir /tmp/repro-cli-602
/tmp $ cd /tmp/repro-cli-602/
/tmp/repro-cli-602 $ git clone git://github.com/jamesls/aws-creds-test
Cloning into 'aws-creds-test'...
...
/tmp/repro-cli-602 $ cd aws-creds-test/
/tmp/repro-cli-602/aws-creds-test (master u=) $ make install
npm install
[email protected] /private/tmp/repro-cli-602/aws-creds-test
├─┬ [email protected]
...
pip install -r requirements.txt
Requirement already satisfied: botocore<2.0.0,>=1.5.0 in /usr/local/lib/python2.7/site-packages (from -r requirements.txt (line 1))
...



/tmp/repro-cli-602/aws-creds-test (master u=) $ make test
./test-creds.sh
Testing python...
Access Key:
Secret Access Key:
AKID   hash: 4e7c36343646e1fa7495092bffcd4b9b7dd00f2f5014a189ab81f326e6472a62
AKID length: 20

SAK    hash: 941a655993caccb1a1218883b97a88b6f41762c6d03902f1cdd1e2a5de5fd82e
SAK  length: 40
Successfuly made an AWS request with the provided credentials.

Testing javasript...
Access Key: ********************
Secret Access Key: ****************************************
AKID   hash: 4e7c36343646e1fa7495092bffcd4b9b7dd00f2f5014a189ab81f326e6472a62
AKID length: 20


SAK    hash: 941a655993caccb1a1218883b97a88b6f41762c6d03902f1cdd1e2a5de5fd82e
SAK  length: 40
Sucessfully made an AWS request with the provided credentials.

Тем, кто сталкивается с этой проблемой, запустите тестовый сценарий и поделитесь результатами.

То же самое исключение произошло со мной в запросе PutObject (C #), когда метаданные объекта содержали символы Unicode.

Я была такая же проблема. Новые секретные ключи с + и / не работают. Я создал новые ключи без этих символов, и они работают нормально.
Ваш тестовый сценарий предназначен для Linux, и я запускаю Windows.
Я вставил свои учетные данные с помощью Control-C и Control-V, используя оболочку Windows и _aws configure_
и я использовал только _aws cp_

Это тоже проверено, и оно отлично работает, пока секретный ключ не имеет символов, как упоминалось выше.

Надеюсь, что это скоро будет решено, мне очень больно восстанавливать учетные данные, пока я не получу тот, который работает!

Вчера я подал заявку в службу поддержки AWS, и сегодня она, похоже, решена.

Я тестировал несколько раз, и + и / оба теперь работают? Я больше не могу воспроизвести эту ошибку.

У меня была такая же проблема с моим Pi.
С новейшим awscli (aws-cli / 1.11.85 Python / 3.4.2 Linux / 4.9.24-v7 + botocore / 1.5.48) у меня все еще была проблема:

корень @ pi : ~ # aws s3 ls s3: //
Произошла ошибка (SignatureDoesNotMatch) при вызове операции ListBuckets: рассчитанная нами подпись запроса не соответствует предоставленной вами подписи.
Проверьте свой секретный ключ доступа и метод подписи. Дополнительные сведения см. В разделах Аутентификация REST и Аутентификация SOAP.

Даже с секретным ключом, в котором не было специальных символов (+ или /), доступ не работал. Время всегда синхронизировалось, но, к сожалению, это тоже не проблема.

В файле ".aws / config" я добавил допустимый регион (только для тестирования ..), и вдруг все заработало. Поскольку я использую совместимое хранилище s3 (не s3 от Amazon)

[дефолт]
aws_secret_access_key = MYKEY
aws_access_key_id = MYID
region = us-east-1 <- раньше было "фиктивное" значение.

Как видно, у региона должно быть «правильное» значение. Когда я снова меняю его на что-то другое, например "dummyvalue", я получаю ту же ошибку, что и упомянутая выше.
Теперь со значением «us-east-1» работает!
Надеюсь, это кому-то поможет.

Я тоже с этим столкнулся. Также, похоже, проблема со знаком «+» в секретном ключе. Если у меня есть кредиты в переменных среды, я получаю сообщение об ошибке. Если я помещу их в файл ~ / .aws / credentials (отредактировав вручную), я не получу сообщения об ошибке.

[править] Только что заметил, что переменные среды были в файле, отформатированном для dos (ff = dos в vim). Это произошло потому, что я только что взял загруженный файл .csv и отредактировал его, изменив записи в переменных среды. Когда я переформатировал файл в 'ff = unix', я больше не получал ошибки. Единственное различие между 2 - это возврат строки, dos использует "CR-NL", а unix - просто "NL". Я предполагаю, что на самом деле проблема заключалась в том, что персонаж "CR".

я тоже, а также подтвердите вопрос "+"

Если вы столкнетесь с этим при использовании Docker для Mac, простой перезапуск Docker исправит несоответствие системного времени.

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

Создание новых пар ключей до тех пор, пока я не получу одну без специальных символов, тоже решило эту проблему; специальные символы (в частности, +) просто не работают в ~ / .aws / credentials.

Сгенерированный ключ без специальных символов (в частности, + ) решил проблему и для меня.

Форматирование файла в соответствии с комментарием @eikenb также помогает .

Удаление ключа и создание нового сработало для меня.

Только что получил эту ошибку. Обновленное системное время, которое оказалось более чем на 6 минут ниже GMT. Немедленно исправил проблему.

Для меня это было так странно и сложно.
Я боролся с этой проблемой и много раз пытался ее решить.
На данный момент это неожиданно сработало! Я был удивлен, поэтому сделал новое ведро, но оно не сработало. Поскольку я ничего не делал, кроме изменения кода, я просто ждал часами. Наконец, это сработало, хотя я ничего не сделал. Я не могу поверить в это ...

Используя aws configure в оболочке bash в Windows 7, я обнаружил, что у меня есть две строки aws_secret_access_key в моем .aws/credentials а во второй строке я неправильно набрал кучу мусора . Удалил вторую строчку и все заработало.

aws-cli/1.11.119 Python/2.7.12 Linux/4.4.0-53-generic botocore/1.5.82

Увидев эту проблему на Linux Mint здесь, без + в моем ключе или секрете.

Вывод из тестового скрипта:

/aws-creds-test $ make test
./test-creds.sh
Testing python...
Access Key: 
Secret Access Key: 
AKID   hash: 36b0df669bfc2fa232f31ada2b40e8f58ec152b0afee875f28b21e32e2d59a30
AKID length: 20

SAK    hash: 02b21158d3ab7d2691ceef468951c3b3551704a8eea19ad4a8f59c7be38378f6
SAK  length: 40
Error making AWS request: An error occurred (SignatureDoesNotMatch) when calling the GetCallerIdentity operation: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.

Testing javasript...
Access Key: ********************
Secret Access Key: ****************************************
AKID   hash: 36b0df669bfc2fa232f31ada2b40e8f58ec152b0afee875f28b21e32e2d59a30
AKID length: 20


SAK    hash: 02b21158d3ab7d2691ceef468951c3b3551704a8eea19ad4a8f59c7be38378f6
SAK  length: 40
Error making AWS request
{ SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.
    at Request.extractError (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/protocol/query.js:47:29)
    at Request.callListeners (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/sequential_executor.js:105:20)
    at Request.emit (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/sequential_executor.js:77:10)
    at Request.emit (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/request.js:683:14)
    at Request.transition (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/request.js:22:10)
    at AcceptorStateMachine.runTo (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/state_machine.js:14:12)
    at /home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/state_machine.js:26:10
    at Request.<anonymous> (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/request.js:38:9)
    at Request.<anonymous> (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/request.js:685:12)
    at Request.callListeners (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/sequential_executor.js:115:18)
  message: 'The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.',
  code: 'SignatureDoesNotMatch',
  time: 2017-09-18T20:33:23.951Z,
  requestId: '9e62c6c2-9cb0-11e7-9856-a5fd5c3e417d',
  statusCode: 403,
  retryable: false,
  retryDelay: 60.66602455065775 }
Makefile:6: recipe for target 'test' failed
make: *** [test] Error 1

После обновления awscli до aws-cli/1.11.154 Python/2.7.12 Linux/4.4.0-53-generic botocore/1.7.12 :

$ make test
./test-creds.sh
Testing python...
Access Key: 
Secret Access Key: 
AKID   hash: 0cdf83ac8cf800ca46738682ff5a0ab35d94891a568fc6fd9115ecf13dcce542
AKID length: 20

SAK    hash: 7ae856b46f3d5cd23b94f60765adbeb13215f6c226a2953ab93eed9e26d51694
SAK  length: 40
Error making AWS request: An error occurred (SignatureDoesNotMatch) when calling the GetCallerIdentity operation: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.

Testing javasript...
Access Key: ********************
Secret Access Key: ****************************************
AKID   hash: 0cdf83ac8cf800ca46738682ff5a0ab35d94891a568fc6fd9115ecf13dcce542
AKID length: 20


SAK    hash: 7ae856b46f3d5cd23b94f60765adbeb13215f6c226a2953ab93eed9e26d51694
SAK  length: 40
Error making AWS request
{ SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.
    at Request.extractError (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/protocol/query.js:47:29)
    at Request.callListeners (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/sequential_executor.js:105:20)
    at Request.emit (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/sequential_executor.js:77:10)
    at Request.emit (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/request.js:683:14)
    at Request.transition (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/request.js:22:10)
    at AcceptorStateMachine.runTo (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/state_machine.js:14:12)
    at /home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/state_machine.js:26:10
    at Request.<anonymous> (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/request.js:38:9)
    at Request.<anonymous> (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/request.js:685:12)
    at Request.callListeners (/home/kev/projects/external/aws-creds-test/node_modules/aws-sdk/lib/sequential_executor.js:115:18)
  message: 'The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.',
  code: 'SignatureDoesNotMatch',
  time: 2017-09-18T20:43:21.662Z,
  requestId: '02ab939a-9cb2-11e7-a1f3-87975b0dbd52',
  statusCode: 403,
  retryable: false,
  retryDelay: 86.52138921193912 }
Makefile:6: recipe for target 'test' failed
make: *** [test] Error 1

Я только что воссоздал свои ключи - мой новый все еще содержит '+', но теперь могу использовать cli

Может быть так просто

@ DanAbbz92 действительно, я случайно нашел такое же решение примерно сейчас. Понятия не имею, почему старые ключи никогда не работали, но новые были в порядке, используя тот же процесс.

У меня был ^ V в моем секретном ключе из-за неудачной попытки вставки. Возможно, будет разумно поставить более серьезное предупреждение о проверке ключей на наличие плохих символов. Предотвратит дальнейшую ненужную эскалацию.

Об этой проблеме было сообщено в 2014 году. Сегодня 26 октября 2017 года. Я столкнулся с этой проблемой, в моем секрете был знак «+». Я создал новый ключ и поместил его в ~ / .aws / configure
Давай, Amazon, ты когда-нибудь планируешь исправить эту ошибку * ???

Я столкнулся с этой проблемой сегодня после установки cli и запуска aws configure . В моих ключах не было специальных символов, но моя проблема была решена следующим образом:

• rm -r ~/.aws/
• воссоздали папку .aws и файл credentials и вручную добавили учетные данные

tl; dr выключение и повторное включение сработало для меня ¯_ (ツ) _ / ¯

Для людей, использующих Hadoop, которые попадают сюда: в Hadoop 2.8.0 исправлена ​​связанная ошибка:
" s3:" URL-адреса прерываются, если секретный ключ содержит косую черту, даже если они закодированы

Привет, сегодня я столкнулся с той же проблемой.
На коробке было неправильное время. По истечении времени обновления все работает.

Добавление еще одного "я тоже"

У меня был секретный ключ, в котором было два символа '+', и он работал из моего файла .aws / credentials на моей виртуальной машине Windows (при использовании приложением .NET), но когда я установил awscli из brew на свой MacBook Pro , и скопировал файлы .aws (тестирование кодировок файлов, форматов конца строки и т. д.), это не удалось с SignatureDoesNotMatch.

Я пытался воссоздать учетные данные, пока не получил секретный ключ без буквенно-цифровых символов, и теперь он работает с awscli на моем Mac. Копирование этих учетных данных обратно на мой компьютер с Windows и запуск приложения .NET, которое все еще работает.

Я не вносил никаких изменений во время ни на одной из машин (Mac уже использовал NTP, а виртуальная машина Windows выглядит так, как будто она работает примерно на 12 минут позже фактического времени)

Я установил awscli с помощью: brew install awscli

и aws --version возвращает: aws-cli / 1.14.30 Python / 3.6.4 Darwin / 16.7.0 botocore / 1.8.34

Итак, я отправил код лямбда-выражениям сегодня днем ​​(2018-02-01 15:48 EST с лямбдой в us-east-1).
Теперь в 18:00 я получаю ошибки подписи на каждой системе в офисе.
Оглядываясь назад на эту ветку: мое время верное, ничего не изменилось, учетные данные не старше года, работают со дня их создания, используя домашнюю версию aws-cli/1.14.30 Python/3.6.4 Darwin/17.4.0 botocore/1.8.34 (действительно пробовал перейти на версию 1.14. 2х версия, без любви)

Это какая-то злоба

Имея ту же проблему и решив генерировать новые ключи без каких-либо специальных символов (например, /, + и т. Д.).

Спасибо @hellais за вклад!

У меня была такая же проблема, решил ее, исправив часы моего ноутбука. Видимо я отстал от времени.

Я только что столкнулся с этой проблемой, и похоже, что мой клиент ntp отстал на 10 минут. Я сделал ntpdateи теперь все исправлено.

Я могу подтвердить, что воссоздание моих ключей доступа до тех пор, пока я не получил ключ без специальных символов, сработало. Какая нелепая ошибка, вау.

Учитывая, что это такая давняя проблема, не было бы разумным обновить сообщение об ошибке, чтобы дать пользователям ссылку на возможное исправление, например восстановление ваших ключей? Вместо того, чтобы сделать вывод о том, что проблема намного сложнее, чем «да, мы выдаем ошибку, когда в ваших ключах есть специальные символы, извините!».

тот же вопрос слышу:

Версии:

aws-cli/1.14.58 Python/2.7.10 Darwin/17.4.0 botocore/1.9.11

Команда:

aws s3 ls
получил следующую ошибку:
Unknown Signature Version: s3v3.

нет решения:

Я обновил свой плащ и создаю секрет без какого-либо специального символа

обновление - исправлено следующим

aws configure set default.s3.signature_version s3v4

Да, это все еще проблема - мой секретный ключ заканчивался символом + и исправление, которое я нашел, не помогло. Восстановил новые ключи без + в конце секретного ключа, и он работал нормально.

Какого черта это все еще проблема?

Произошла ошибка (SignatureDoesNotMatch) при вызове операции CreateMultipartUpload: рассчитанная нами подпись запроса не соответствует предоставленной вами подписи. Проверьте свой ключ и метод подписи.
пожалуйста помоги.

Мой секрет начинается со знака + и я даже не знал об этой проблеме до сегодняшнего дня. Я использую boto3 python для доступа к моему s3. Это не работает, когда я передаю учетные данные в виде необработанных строк, но отлично работает, если я загружаю их из config.ini как переменную, используя configparser.RawConfigParser() . Конечно, создание нового секрета без знака + в конце или в начале также решит эту проблему.

Тем не менее, если это (по какой-то причине) не может быть исправлено, возможно, измените сообщение об исключении на что-то вроде «мы не разрешаем знак +, сгенерируйте новый, если вы хотите получить к нему доступ таким же образом».

Я использую aws cli на osx, и у меня также был секрет, который оказался неверным. В моем исходном были + и = и я получил ошибку SignatureDoesNotMatch при попытке cp файлов на s3. Я восстановил ключи, и теперь мой новый секрет представляет собой буквенно-цифровую строку. Просто добавляю еще одно подтверждение того, что регенерация работает. :с облегчением:

В надежде, что это может дать понимание, эта проблема (не обработка + в секретных ключах) проявляется в этой версии на RHEL5.

aws-cli/1.15.25 Python/3.4.7 Linux/3.2.45-0.6.wd.865.49.315.metal1.x86_64 botocore/1.10.25

но не происходит с этой версией в Ubuntu

aws-cli/1.11.13 Python/3.5.2 Linux/4.4.0-121-generic botocore/1.4.70

Начато в январе 2014 года, а теперь в июне 2018 года, более 4 лет, и у меня была такая же проблема с ошибкой SignatureDoesNotMatch . Решение для меня было таким же, как и все решения большинства здесь, получить новый секретный ключ без какого-либо специального символа, так как для моего предыдущего ключа есть двоеточие : , я попробовал синхронизацию времени, но не работал у меня. Я использую WSL.

aws-cli/1.15.27 Python/3.6.5 Linux/4.4.0-17134-Microsoft botocore/1.10.27

Просто обновите то, что содержащие символ косой черты (/), могут привести к тому, что клиент PHP не будет работать (PHP 7 в Windows 10 в моем случае), возвращая _сигнатуры не совпадают_ ошибка. В этой ситуации просто сгенерируйте другую пару ключей, более безопасную.

Я был сбит с толку около 30 минут.

Следил за этой проблемой, проверял местное время и т. Д. - все было хорошо.

В отчаянии я уничтожил файл ~/.aws/credentials и снова вошел в систему (по сути, воссоздав файл) и вуаля, просто работает.

Интересно, почему он вообще выдает эту ошибку!

РЕДАКТИРОВАТЬ:
В моем случае это не связано с секретным ключом; все они в основном были простыми струнами.

+1 по этой проблеме, мой ключ начинался с = . Восстановил ключ, в котором было только / и все было хорошо. Пытался заключить ключ в знаки " , но безуспешно.

Не то, что я ожидал увидеть от интерфейса командной строки AWS.

Добавляя к той же проблеме здесь, я не могу поверить, что / в моем ключе вызвало это. Спасибо за потраченное время!

У меня была такая проблема. Я считаю, что это было результатом первоначальной установки aws cli от имени пользователя root. Казалось, что разрешение удаляет aws cli, удаляет как папку .aws в домашней папке текущего пользователя, так и в корневой папке, а затем снова запускает aws configure от имени текущего пользователя.

У меня возникла эта проблема при запуске сценария bash с использованием таймера systemd в Ubuntu. При ручном запуске скрипта с моим пользователем все работало нормально. Однако таймер продолжал выдавать ошибку (SignatureDoesNotMatch). Затем я заметил, что (SignatureDoesNotMatch) был создан для любой команды aws, запущенной от имени пользователя root, и что команда aws configure не сохраняла новые предоставленные значения.

Чтобы решить эту проблему, я вошел в систему как root 'su -i', изменил на 'cd ~ / .aws /' и удалил конфигурацию с 'sudo rm -r credentials', снова запустил 'aws configure' и на этот раз новые значения был спасен. Оттуда все снова заработало, как и ожидалось!

Могу подтвердить, что эта проблема все еще существует на aws-cli / 1.15.4 Python / 2.7.15rc1 Linux / 4.15.0-42-generic botocore / 1.12.8.

An error occurred (SignatureDoesNotMatch) when calling the <whatever> operation: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.

Оказывается, в моем секрете была + . Я регенерировал, и теперь все в порядке. Когда мы можем ожидать исправления для этого @jamesls? Или я могу чем-нибудь помочь?

Столкнулся с тем же на моем aws cli, потому что секретный ключ содержал + ... (как описано выше) после регенерации нового ключа ... (как я видел из комментария delmartechdude выше) .... проблема было решено.

Мои два цента. Это выдавало мне эту ошибку, потому что я пытался загрузить контент в s3 с ускоренной передачей таким образом (раньше это работало): --endpoint-url http://imaat.s3-accelerate.amazonaws.com ( --endpoint-url http://<bucket-name>.s3-accelerate.amazonaws.com ), как указано в свойствах конечной точки ускорения :

Следуя инструкциям в официальных документах: https://docs.aws.amazon.com/es_es/AmazonS3/latest/dev/transfer-acceleration-examples.html, я заменил эту последнюю часть на: --endpoint-url http://s3-accelerate.amazonaws.com и запустил команду aws configure set s3.addressing_style virtual для динамического построения имени хоста. Проверить: https://docs.aws.amazon.com/cli/latest/topic/s3-config.html#addressing -style

Не знаю почему, но теперь это работает. В моем имени корзины («imaat») нет специального символа, который может привести к сбоям DNS, но по какой-то причине оно не удалось с последними обновлениями cli.

Добавил профиль через текстовое редактирование и получил этот сбой. Обновление идентификатора и секрета доступа к профилю через набор конфигурации aws, и это сработало. Это для секрета со знаком "+" и

@ dave-miles Вы кое-что знаете, спасибо за комментарий! Я расширяю ваш вывод ниже:

Я столкнулся с этой проблемой с некоторыми изображениями докеров. Первоначально я использовал ADD в файле докеров, чтобы добавить файл ~ / .aws / credentials в контейнер.

Если бы мы это сделали, то при загрузке с s3 столкнулись бы с ошибкой SignatureDoesNotMatch.

Я удалил строку ADD в файле докеров, перестроил и запустил новый контейнер докеров. В этом новом контейнере я вручную запустил aws configure set aws_access_key_id <access key id goes here> и aws configure set aws_secret_access_key <secret access key goes here> Это был первый раз, когда вводилась информация об учетных данных в этом контейнере (т.е. контейнер был "свежим" образом centos).

После использования команд aws configure set я смог успешно загрузить с s3.

Для тех, кто использует это с файлом докеров, вы можете использовать операторы RUN в файле докеров для запуска двух команд или вы можете использовать оператор ADD для отправки скрипта в контейнер докеров:

#! / bin / sh

aws configure set aws_access_key_id _access-key-id-go-here_
aws configure set aws_secret_access_key _secret-access-key-go-here_

У меня была та же проблема, что и у @villasenor - + в секретном ключе вызвала бы ошибку при настройке awscli с использованием env vars в докере. поворот клавиш устранил проблему.

То же самое, но в ключе доступа или секретном ключе нет специальных символов.
Восстановлен новый набор для того же пользователя IAM, и новые могут перечислять сегменты, а старые - нет.

Это произошло с вызовами как AWS cli, так и Java SDK. Предположить, что вина не в клиентах ...

Оба набора еще живы. Если кому-то на Amazon нужна дополнительная информация, пожалуйста, свяжитесь с нами.

Мой коллега тоже с этим столкнулся. Я пробовал отладку, создавая ключ доступа, пока не получил его со знаком + или / в начале. Однако не удалось воспроизвести.

У меня был опыт коллеги по работе. Мы определили, что это происходит именно в Ubuntu 18.04 с + или / в секретном ключе.

Получил ту же ошибку сегодня, в настоящее время использую Windows 10. Однако, когда я использую тот же ключ доступа на другом ноутбуке (Mac), он отлично работает для меня. Затем я попробовал использовать ключ доступа в WSL, что тоже нормально. Не уверен, в чем причина, и в ключе aws нет специального символа.

У меня эта ошибка с одним набором ключей доступа, а не с другим.
Как упоминалось в нескольких других сообщениях здесь, мой ключ как '/' в нем. Мне эта проблема кажется простой проблемой, когда сервер или клиенты кодируют / декодируют с использованием стандарта кодирования RFC URI, а другие не используют его.
Я планирую запустить эти упомянутые тестовые сценарии и попытаться воспроизвести ошибки.

Для других людей здесь я столкнулся с ошибкой, но у меня были неправильные учетные данные, кэшированные в моей папке ~ / .aws. Сначала он смотрит туда, а затем - на переменные среды.

Я испытываю это в Windows 10 с помощью Git Bash. Он отлично работает с Powershell. Вызов Python явно отличается, но это тот же модуль Python и Python. У меня также есть + и / в моем ключе.

У меня просто была эта проблема, и для меня исправление заключалось в удалении пробелов. пример.
вместо значения по умолчанию:
[profilename]
aws_access_key_id = MYAWSACCESSKEYID
aws_secret_access_key = MYAWSSECRETACCESKEY
Я изменил его на:
[profilename]
aws_access_key_id=MYAWSACCESSKEYID
aws_secret_access_key=MYAWSSECRETACCESKEY

обратите внимание на отсутствие пробелов вокруг =. Это исправило это для меня, и у меня тоже есть + и / в моем ключе.

Все, здесь есть несколько отличных советов по устранению неполадок. Я собираюсь превратить их в страницу в разделе «Устранение неполадок» в Руководстве пользователя CLI. Спасибо за вклад!

Всем привет,

Я вижу, что здесь много ответов, но для меня это были специальные символы в секретном ключе доступа AWS. Мой начался с "= +", но когда я сгенерировал новый без специальных символов из веб-консоли, он сразу начал работать.

Я запускаю awscli в оболочке Zsh в Ubuntu в Windows:

jonathan<strong i="8">@SurfaceBook</strong>  ~  aws --version aws-cli/1.16.216 Python/2.7.12 Linux/4.4.0-17134-Microsoft botocore/1.12.206

Я надеюсь, что это поможет другим.

Спасибо
Джонатан

Просто потратил 4 часа на отладку, пока не нашел эту ветку. Я мог бы использовать s3 cli локально без каких-либо проблем, но при запуске их в circleci я получил эту ошибку: SignatureDoesNotMatch ..

Как предлагали другие, мой секретный ключ доступа содержал символ + , и после создания нового ключа все начало работать.

Было бы почти невозможно отладить без этого потока

Спасибо @blbradley . Это была именно та проблема, которая была у меня.

была та же проблема - решение заключалось в удалении переменных среды Windows с устаревшими учетными данными AWS

У меня тоже была проблема с Python3 boto3.
Моя начинается с =/

Я нахожусь на виртуальной машине, делая хост Time & Region похожим на гостевой Time & Region, что решает проблему.

Просто хотел сказать, что это ударило меня сегодня по вновь созданному ключу - и после большого разочарования, приземлился здесь и увидел упоминание о / в ключе. Конечно, в этом и заключалась проблема - новый ключ без него работает. Wtf ?!

Я не могу поверить, что эта проблема возникла в 2014 году, и до сих пор нет исправления, эта ошибка заставила меня создать новый набор учетных данных AWS для себя, я даже пытался закодировать '/', но это не сработало :(

Удаление учетных данных с помощью символа «/» решило проблему для меня. Спасибо всем за то, что указали на это.

Просто сделайте это в 2020 году. Секретный ключ отмечен знаком «+».

aws-cli - разработан aws project - не работает с действующими ключами aws ... в течение 6 лет?

Та же проблема в январе 2020 года. Секретный ключ имеет косую черту "/".

Я создал новый набор учетных данных с помощью консоли AWS IAM и убедился, что секретный ключ был полностью буквенно-цифровым, без "/", "+" и т. Д. Я заменил свой старый секретный ключ новым секретным ключом в моем файле ~ / .aws / credentials, а затем повторил попытку.

Это решило это.

Та же проблема и здесь, в 2020 году. Но я не могу удалить буквенно-цифровые символы, так как они сами являются частью моих учетных данных, и я не контролирую это

Просто регенерируйте учетные данные, пока не избавитесь от персонажей. Обычно требуется еще одна или две попытки.

Морис

От: columb1a [email protected]
Отправлено: вторник, 21 января 2020 г., 13:47
Кому: aws / aws- cli [email protected]
Копия: Морис Биззарри [email protected] ; Комментарий [email protected]
Тема: Re: [aws / aws-cli] Ошибка SignatureDoesNotMatch (№ 602)

Та же проблема и здесь, в 2020 году. Но я не могу удалить буквенно-цифровые символы, так как они сами являются частью моих учетных данных, и я не контролирую это

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Faws%2Faws-cli%2Fissues%2F602%3Femail_source%3Dnotifications % 26email_token% 3DAAAXXM3CF63PVTWMVHJN2FTQ65UMRA5CNFSM4ALOPGL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJRMFFA% 23issuecomment-576897684 & данные = 02% 7C01% 7Cmaurice% 40bizzarrisoftware.com% 7Cf6f2e8a571954134b76b08d79ebb6bee% 7C9aa15552370449f5ac56c2850c165d32% 7C1% 7C0% 7C637152400117352225 & SData = 2Z6PQRSvKD0P8Eu0yrs15Ypi6GgtFvaDi7qewAq5yH4% 3D & зарезервирован = 0 , или отказаться от https://nam04.safelinks.protection.outlook.com /?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAAXXM34MIXB32H3RMQL2FTQ65UMRANCNFSM4ALOPGLQ&data=02%7C01%7Cmaurice%40bizzarrisoftware.com%7Cf6f2e8a571954134b76b08d79ebb6bee%7C9aa15552370449f5ac56c2850c165d32%7C1%7C0%7C637152400117362212&sdata=53%2F78BXqn3FRxlkfzXYHnJPEEbs7Ta1XmJhW%2BZdBjXo%3D&reserved= 0 .

Сначала я столкнулся с проблемами тайм-аута, и после обновления моего awscli столкнулся с этой проблемой. Вы думали, шести лет хватит, чтобы все заработало ...

у меня также есть это развертывание приложения Vue.js через gitlab в ведро AWS S3, может кто-нибудь сказать мне, что делать
msg: фатальная ошибка: произошла ошибка (SignatureDoesNotMatch) при вызове операции ListObjectsV2: рассчитанная нами подпись запроса не соответствует предоставленной вами подписи. Проверьте свой ключ и метод подписи.

У меня не было никаких не буквенно-цифровых символов, но работа с профилированным не работала для одного профиля. Я восстановил учетные данные с помощью консоли, и новые просто заработали.

Получение таких ошибок сегодня и восстановление учетных данных без специальных символов ('+' или '/') работает для меня.

У меня все еще та же проблема, но это происходит внезапно, я работаю с операциями Get и Put, и одна работает, а другая нет. и да, мой секретный ключ не содержит специальных символов. любая помощь? Сначала я вызываю getIntent (API моделей amazon lex) для получения контрольной суммы намерений, а затем вызываю putIntent для обновления этого намерения. Метод Get работает (не всегда), но метод put вызывает ту же проблему с подписью, а если я удалил API метода Get из кода, метод Put сработает 2 раза из трех.

У меня была эта проблема, я предлагаю вам сгенерировать новые ключи
и переконфигурируйте свой профиль aws

aws настроить

Идентификатор ключа доступа AWS [ * * * * QD5E]: AWS_ACCESS_KEY_ID
Ключ доступа к AWS Secret [ * * * * ANjA]: AWS_SECRET_ACCESS_KEY
Название региона по умолчанию [eu-west-3]: AWS_REGION
Формат вывода по умолчанию [json]: OUTPUT_FORMAT

Привет !

У меня такая же проблема при использовании предварительно подписанного URL-адреса, возвращаемого моему клиенту.
URL-адрес создается на сервере (в течение ограниченного времени). Сервер - это python, и я не вижу там никаких ошибок, но клиент - это JS - только получает URL-адрес и открывает его. Часть URL - это сгенерированные учетные данные для этого ресурса)

Ошибка возникает и исчезает, поэтому я думаю, что это связано с тем, что здесь говорится о специальных ключах в учетных данных, но поскольку я использую учетные данные, созданные на сервере, я не могу их изменить!

Есть ли способ позаботиться об этом в коде? как-нибудь разобрать спец ключи?

Привет !

У меня такая же проблема при использовании предварительно подписанного URL-адреса, возвращаемого моему клиенту.
URL-адрес создается на сервере (в течение ограниченного времени). Сервер - это python, и я не вижу там никаких ошибок, но клиент - это JS - только получает URL-адрес и открывает его. Часть URL - это сгенерированные учетные данные для этого ресурса)

Ошибка возникает и исчезает, поэтому я думаю, что это связано с тем, что здесь говорится о специальных ключах в учетных данных, но поскольку я использую учетные данные, созданные на сервере, я не могу их изменить!

Есть ли способ позаботиться об этом в коде? как-нибудь разобрать спец ключи?

@ maya-harel вы можете изменить учетные данные из IAM -> пользователи выберите пользователя, которого вы создали, и повторно сгенерируйте вкладку учетных данных безопасности секретного ключа.

также время в коде действительно фатально, для каждого запроса, который вы делаете в бэкэнде, получите текущее время, чтобы использовать его в заголовке для генерации подписи.

Кроме того, было много слепых предложений «восстановить свои учетные данные IAM» пользователям, которые прямо заявили, что это не вариант для них.

Это бесполезно для пользователей и отвлекает от того факта, что это известная ошибка, которая продолжает влиять на пользователей aws-cli, пытающихся использовать действительные учетные данные IAM.

Тоже сталкиваюсь с этим.
$ aws --version
aws-cli / 1.16.300 Python / 2.7.16 Linux / 4.14.152-127.182.amzn2.x86_64 botocore / 1.13.36

Мои клавиши полностью буквенно-цифровые, без специальных символов.

Ключи работают из оболочки, однако при использовании через Jenkins в целевом файле Makefile возникает эта ошибка. Не уверен, что здесь происходит.

В моем секретном ключе есть как / и + . Столкнулись с этой проблемой и пробовали:

• Через aws-cli > aws iam get-user (с использованием файла ~/.aws/credentials )
• boto3 (через python 3.6.8)
  
  
  
  • Жестко запрограммированные ключи
  
  
  • Переменная окружения
  
  
  • Аргумент boto3.Session(profile_name=PROFILE) (извлекаемый из ~ / .aws / credentials)
  
  

Все это приводит к ошибке SignatureDoesNotMatch .

В настоящее время я не могу восстановить ключ.

Я не понимаю, что я могу использовать протокол S3 в Cyberduck (https://cyberduck.io/), и он работает должным образом. Как такое могло быть?

Это должна быть одна из самых неприятных ошибок, с которыми я столкнулся, и это безумие, что она не была исправлена. Получение кредита без «+» сработало для меня в CircleCI.

Он все еще рушится? столкнувшись с той же проблемой, ничего себе, я не могу ...

Да, это неприятно. Мой секретный ключ с + не работал в конвейере Jenkins, но когда я сгенерировал новый, в котором было всего несколько / , он работал нормально.

У меня была эта проблема с установленной пакетом версии awscli в Ubuntu 16.04. Я исправил это, установив awscli как пакет python pip.
Для получения инструкций перейдите по этой ссылке в разделе Установка AWS CLI с помощью Python PIP.

_ Обнаруженная проблема _

1) Обнаружена ошибка ключа доступа.
2) Журнал частичных ошибок приведен ниже.

$ python SetupAWS.py list_things
Отслеживание (последний вызов последний):
Файл "SetupAWS.py", строка 222, в
list_things ()
Файл "SetupAWS.py", строка 182, в list_things
things = client.list_things () ['вещи']
Файл "c: Program Files (x86) Python38-32libsite-packagesbotocore-1.16.6-py3.8.eggbotocoreclient.py", строка 316, в _api_call
вернуть self._make_api_call (имя_операции, kwargs)
Файл "c: Program Files (x86) Python38-32libsite-packagesbotocore-1.16.6-py3.8.eggbotocoreclient.py", строка 626, в _make_api_call
поднять error_class (parsed_response, operation_name)
botocore.exceptions.ClientError: произошла ошибка (InvalidSignatureException) при вызове операции ListThings: рассчитанная нами подпись запроса не соответствует предоставленной вами подписи. Проверьте свой ключ доступа к AWS и метод подписи. За подробностями обращайтесь к сервисной документации.

_ Анализ первопричин _

1) Как было предложено многими в их комментариях выше, наличие «+» в моем секретном ключе доступа привело к указанной выше ошибке.

_ Разрешение _

1) Создал новый ключ доступа в качестве пользователя IAM и проверил, что новый секретный ключ доступа не содержит «+» в строке.
2) Выполните команду
3) Выполните команду

$ python SetupAWS.py list_things
[{'thingName': 'myThingName', 'thingArn': 'myThingArn', 'attributes': {}, 'version': 1}]

Этот вопрос открыт уже шесть лет, и я благодарю вас за терпение, настойчивость и предоставленную информацию. Несколько основных причин были выявлены в ваших комментариях (https://github.com/aws/aws-cli/issues/602#issuecomment-520469209) и включены в главу «Устранение ошибок» в руководстве пользователя командной строки. К этим причинам относятся смещение часов и неправильная обработка клавиш со специальными символами в некоторых операционных системах.

Я попытался воспроизвести это в различных средах. Я использовал Ubuntu 16.04, Ubuntu 18.04 и Amazon Linux 2 с Python 3.6.8 и 3.8.3. Хотя многие комментаторы использовали Python 2, я не пытался воспроизвести его, поскольку он больше не поддерживается. Я использовал последнюю версию v1 aws-cli (1.18.80 на момент написания), а также более старую версию (1.11.78), упомянутую в этом выпуске. Я использовал предоставленный сценарий (https://github.com/aws/aws-cli/issues/602#issuecomment-281866173) от @jamesls, который создает новые пары учетных данных, пока не встретит пару со специальными символами и позволит им работать до по часу каждый. У меня не было ошибок SignatureDoesNotMatch . Я получал случайные ошибки AuthFailure в команде describe-instance, но повторная попытка команды с теми же учетными данными завершается успешно.

Большое количество комментариев мешает новым пользователям, которые обращаются к этой проблеме, находить запросы от нашей команды разработчиков с предложениями по устранению неполадок. Чтобы помочь нашей команде и сообществу определить причину этой ошибки, я закрываю эту проблему и создаю специальный шаблон проблемы GitHub, который включает рекомендации и требования к комментариям для пользователей, столкнувшихся с этой ошибкой.

Если вы столкнулись с этой ошибкой, перейдите на вкладку «Проблемы», нажмите кнопку «Новая проблема» и используйте шаблон для отчета об ошибке SignatureDoesNotMatch (или воспользуйтесь ссылкой ниже).

Из-за различий в пользовательских средах, в которых возникает эта ошибка, отправьте отдельную проблему, а не комментируйте существующую.

Нажмите здесь, чтобы отправить отчет об ошибке SignatureDoesNotMatch