EDITAR: Se você estiver enfrentando esse problema, agradecemos sua ajuda na solução de problemas. Estou atualizando este comentário para melhor visibilidade nas etapas de solução de problemas.

Solução de problemas

A primeira etapa para solucionar isso é determinar se o problema está ou não nas próprias credenciais ou na CLI. Para testar isso, tente usar essas credenciais em outros SDKs da AWS (javascript, ruby, java, etc). Para ajudar com isso, criei um script de teste que usa o AWS SDK para python e javascript que está disponível aqui: https://github.com/jamesls/aws-creds-test . Após a clonagem, apenas execute make install , make test . Ele solicitará as credenciais (semelhantes à CLI) e fará uma chamada de API para 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.

Para quem está enfrentando esse problema, execute o script de teste e compartilhe a saída.

Isso deve nos dar uma ideia melhor de onde o problema está ocorrendo:

• Se o script acima for aprovado em python e javascript, mas falhar ao usar a CLI, provavelmente é um problema de CLI.
• Se o script falhar para python, mas passar para javascript, provavelmente um problema com botocore (que a CLI usa).
• Se o script acima falhar para python e javascript, provavelmente um problema com as credenciais reais.

Agradecemos antecipadamente por qualquer pessoa que possa nos ajudar a solucionar esse problema. Avise-me se houver alguma dúvida.

É assim que parece:

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

Alguma atualização para esse problema? Também estou encontrando esse erro e meu arquivo de credenciais não mudou.

Eu tenho um problema semelhante. O plugin Jenkins s3 é capaz de colocar um objeto usando minhas credenciais, mas o aws-cli está me dando os erros abaixo.

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.

Estou tendo o mesmo problema. Se eu inventar um segredo, recebo um erro diferente (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

Isso está me parando completamente. Posso fazer algumas coisas com os utilitários ec2-blah-stuff especificando certs x509, mas a ajuda diz que está obsoleto, então não quero depender dele. Qualquer ajuda na resolução de problemas ou o que quer que seja realmente apreciada.

A primeira etapa seria garantir que suas chaves de acesso / secretas sejam realmente válidas. Algumas coisas para tentar:

• Essas mesmas credenciais de acesso / chave secreta funcionam com outras ferramentas? (O SDK java / javascript / ruby ​​/ python?)
• Outros comandos além de "aws s3" funcionam para você? "Aws ec2 describe-instances" ainda gera erros de autenticação?

Eles não funcionam com outras ferramentas (ec2-describe-instance por exemplo).

Acho que tenho os direitos apropriados, uma vez que uso as obras certs. Para ter certeza de que não é uma estação de trabalho, construí uma instância do Amazon Linux e estou usando a versão awscli que vem com ela, mas estou recebendo a mesma mensagem.

Também é um problema para mim. Estou usando-o em um contêiner do docker, construído com o mesmo Dockerfile.
Ele funciona bem quando construído em um EC2, mas não funciona quando construído localmente em uma caixa vagrant coreos.

Parece que o problema está nas próprias credenciais. Verifiquei novamente e não consigo reproduzir este problema. Verifique as credenciais na página de credenciais de segurança . Se alguém puder fornecer um conjunto exato de etapas que demonstrem o problema, será um prazer dar uma olhada.

Isso aconteceu comigo e foi um resultado do tempo do meu sistema estar muito errado, embora não tenha relatado isso. Executei ntpdate em pool.ntp.org e corrigiu esse problema para mim.

Se você está recebendo este erro quando cred é configurado usando a variável env, tente sudo

Se você estiver em uma máquina virtual, certifique-se de que o horário do sistema operacional do host corresponda ao horário do sistema operacional convidado. Se este não for o caso, você obterá o erro que descreveu.

Um erro muito semelhante ocorre para mim com boas credenciais, ao listar um intervalo que contém _muito_ de chaves. Aqui está o erro:

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.

Aqui está minha saída de 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

Observe que essas credenciais funcionam bem com outras aws invocações e, de fato, este list op é executado por um longo tempo (mais de uma hora) antes de escapar desse erro. Eu tenho um arquivo com mais de 82.000 linhas de saída do comando que falhou.

Estou tendo esse problema e, se eu dormir meu script por um segundo e tentar novamente, ele passa. É quase como se estivesse sendo estrangulado e retornando o erro errado ou algo assim.

Eu posso relatar esse problema também. Ao tentar fazer upload de um arquivo de 11 GB usando aws cp foo s3: // mybucket / foo / bar, recebo vários erros como:

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.

e

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)

Verifiquei se a hora do meu sistema está correta. Também notei uma lentidão considerável (no nível de solicitações de http expirando) no mesmo sistema durante o upload, portanto, sendo um problema de limitação, parece razoável. Também funciona bem para fazer upload de pequenos arquivos com as mesmas credenciais e usar o console da web da mesma máquina, então isso parece ser um problema aws-cli.

Isso aconteceu comigo também com o aws-cli 1.5.5, atualizar o aws-cli para 1.6.2 resolveu.

Acontece comigo com 1.6.2

Isso aconteceu comigo hoje. Isso é novo para mim. Uso o awl-cli há alguns meses sem problemas e sem alterações nas credenciais 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

Acredito que esse problema foi corrigido por meio de https://github.com/boto/botocore/pull/388 e estará disponível na próxima versão do AWS CLI.

@jamesls confirmado corrigido na versão do awscli 1.6.4 . Eu estava usando 1.5.4 . Obrigado!

Estou recebendo esse problema em um novo sistema 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 instalado via 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)

Alguma ideia de como consertar isso?

Minha solução foi dormir por alguns segundos e depois tentar novamente, mas
Parece que também pode haver uma atualização da ferramenta que corrige o problema.

Na terça-feira, 2 de dezembro de 2014 às 03h38, Mark Wolfe [email protected] escreveu:

Estou recebendo esse problema em um novo sistema ubuntu.

Ocorreu um erro de cliente (SignatureDoesNotMatch) ao chamar a operação PutObject: A assinatura da solicitação que calculamos não corresponde à assinatura fornecida. Verifique sua chave e método de assinatura.

Aws-cli instalado via pip

lista de $ pip
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)
Chita (2.4.4)
cloud-init (0.7.5)
colorama (0.2.5)
configobj (4.7.2)
docutils (0,11)
html5lib (0,999)
httpplib2 (0,8)
Jinja2 (2.7.2)
jmespath (0,5.0)
jsonpatch (1.3)
jsonpointer (1.0)
Paisagem-Cliente (14.01)
MarkupSafe (0,18)
mercurial (2.8.2)
oauth (1.0.1)
PAM (0.4.2)
Travesseiro (2.3.0)
pip (1.5.4)
bonita (0.7.2)
pyasn1 (0,1,7)
pycrypto (2.6.1)
picurl (7.19.3)
Pigmentos (1,6)
piinotificar (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)
pedidos (2.2.1)
romano (2.0.0)
rsa (3.1.2)
ferramentas de configuração (3.3)
seis (1.5.2)
Esfinge (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)

Alguma ideia de como consertar isso?

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/aws/aws-cli/issues/602#issuecomment -65198065.

@wolfeidau e sim, falei muito cedo. O awscli localmente instalado está apresentando os erros SignatureDoesNotMatch novamente. Caramba!

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'

Esse problema ocorre apenas quando uma solicitação é repetida? Ou isso acontece sempre que você executa o comando deregister-instances-from-load-balancer?

@jamesls agora acontece sempre :(

Eu sei que este problema está resolvido, mas gostaria de compartilhar que você pode ver esse erro ao executar em uma VM que hiberna. Nesses casos, o relógio do sistema não atualiza de forma consistente se você estiver usando o Ubuntu. Basta atualizar o tempo de correção (ou seja, sudo ntpdate -s time.nist.gov).

Olá, existe alguma solução final para isso?

+1

Usando a versão 1.7.8 da CLI, estava vendo o mesmo erro SignatureDoesNotMatch ao tentar o seguinte:
$ aws iam list-users

E obter um AuthFailure para isso:
$ aws ec2 describe-security-groups

Depois de excluir minhas chaves e tentar novas, os dois comandos funcionam.

Esta é a chave de acesso secreta antiga que pode ter sido a causa dos meus problemas, observe a porcentagem, os caracteres de adição e barra: H2J7 / oT3Fib15SwFVB1s3EnTCmg + SC7wF7qoP + dw%

: +1: @gsterndale. Minha chave de acesso com % não funcionou. Tive que gerar novas chaves.

Eu também tive esse problema várias vezes. Toda vez que regenerar a chave até obter uma sem nenhum caractere especial nela (em particular, eu estava tendo problemas com o sinal + no segredo), resolvi isso.

Sinceramente, todos os meus problemas de chave de assinatura desapareceram quando mudei de executar o comando em uma máquina ubuntu em vez de uma instalação homebrew mac local.

Eu sou muito novo no AWS, enfrentei esse problema imediatamente no node js

              ^

SignatureDoesNotMatch: a assinatura da solicitação que calculamos não corresponde à assinatura que você forneceu. Verifique sua chave de acesso secreta da AWS e método de assinatura. Consulte o s
vice-documentação para obter detalhes.

A seqüência canônica para esta solicitação deveria ter sido
'PUBLICAR
/

host: email.us-west-2.amazonaws.com
x-amz-content-sha256: 89cdc817a829111278fbed35aacc694db71669f3845874beaecaf00ff2be1a39
x-amz- date: 20150809T053346Z

host; x-amz-content-sha256; x-amz-date
89cdc817a829111278fbed35aacc694db71669f3845874beaecaf00ff2be1a39 '

O String-to-Sign deveria ter sido
'AWS4-HMAC-SHA256
20150809T053346Z
20150809 / us-west-2 / ses / aws4_request
0b908b0248bae550b814b37629a418707742416377816b5a5e78e1897b72293e '

+1

Estou tendo esse problema para todos os comandos aws s3 (awscli 1.8.6 no ubuntu 14.04 LTS).
Existem soluções conhecidas? Tentei excluir meu arquivo de credenciais e executar o aws configure, reiniciando e reinstalando o awscli.

@mcobzarenco , você experimentou novas chaves?

@gsterndale Eu vi o comentário acima sobre ter barras nas chaves antigas, mas esse não é o caso e minhas chaves foram geradas recentemente (em junho de 2015). Eu só tenho esse problema no AWS Ubuntu 14.04 LTS. No meu laptop (14.04) awscli (mesma versão) funciona bem.

@mcobzarenco Não acho que seja a idade das chaves, mas sim os caracteres especiais nelas. Quando eu originalmente criei as chaves, elas tinham caracteres de porcentagem, mais e barra. Ao depurar o problema, tentei excluir e criar novas chaves. Esses novos, felizmente, não tinham nenhum desses personagens e funcionam.

acabei de encontrar esse problema no Ubuntu. Quando eu inseri as chaves via CLI, ele as armazenou em ~ / .aws / config, mas removeu o caractere '+'. Editar manualmente o arquivo para adicionar o '+' permitiu que eu me conectasse.

@gsterndale Obrigado pela dica, posso confirmar que gerar uma nova chave que não contém + funcionou para mim também. A solução de @stebl é boa se for inconveniente substituir as chaves.

Eu enfrentei o mesmo problema ao usar AWS SDk com node js. Para resolver esses problemas, eu segui exatamente as mesmas etapas mencionadas aqui
http://aws.amazon.com/developers/getting-started/nodejs/

Acho que o AWS SDK foi desenvolvido com uma versão específica do node js, a incompatibilidade no node js resultará em problemas como este.

Eu tenho o mesmo problema e sim, foi resolvido usando uma chave sem símbolos especiais (o + no meu caso específico)

Encontramos este erro (onde uma máquina poderia descrever instâncias usando awscli, mas a outra obteve um erro de acesso negado com a mesma chave de acesso. Na última máquina, os usuários da lista de IAM deram este erro SignatureDoesNotMatch). Resolvido corrigindo a hora do relógio do sistema na máquina com o problema.

Como @tukaaa disse, há um bug se a chave de acesso secreta contiver um caractere não alfabético (como +). Acho que foi uma fuga ruim para algum lugar ;-(

@ebuildy Você pode confirmar em qual versão da CLI está vendo isso ( aws --version )? Se esta for uma versão do motivo da CLI, prosseguirei e reabrirei este problema.

Estou recebendo isso em aws-cli/1.9.1 Python/3.5.0 Windows/7 botocore/1.1.8

Eu estava tendo o mesmo problema em uma caixa do Windows, usando uma chave sem caracteres não alfa nela. Eu verifiquei que não era um erro de copiar / colar usando o mesmo buffer de colagem em outra caixa. Desinstalar / reinstalar o AWS cli e excluir os arquivos de credenciais / configuração e, em seguida, executar novamente a configuração do aws corrigiu o problema.

Acabei de ver isso em aws-cli/1.10.3 Python/2.7.10 Darwin/14.5.0 botocore/1.3.25 .

A regeneração de uma chave sem caracteres especiais corrigiu-a. FWIW, no meu caso, o caractere especial era / e eu estava usando um arquivo INI.

Ok, reabrindo, vamos nos aprofundar nisso.

@ Posso confirmar que tenho o mesmo problema descrito por @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

Mas minha chave não contém nenhum símbolo especial.

Estou recebendo o mesmo erro ao usar o módulo de nó s3-cli. Minha chave secreta contém um [ .

Finalmente descobri o que há de errado. Eu acidentalmente adicionei vários caracteres às teclas. Essa é a razão.

Eu estava enfrentando esse problema com o seguinte cenário; tanto no rhel7 quanto no ubuntu. Acho que tem algo a ver com caracteres não alfa, como outros mencionaram

• balde s3 protegido para uma única função
• A instância ec2 com a referida função precisa assumir a mesma função antes de acessar o bucket S3 protegido

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`

Eu acredito que algo com o --query estava bagunçando as credenciais. Ao executar os comandos manualmente e copiar e colar os valores; em seguida, definir as variáveis ​​de ambiente parecia funcionar muito bem.

Tive o mesmo problema ao executar o awscli versão 1.10 no Mac (instalado via pip) versus Ubuntu (imagem da Amazon) no awscli versão 1.2.9. aws configure --profile user produz duas configurações diferentes em cada uma. A versão 1.10 produziu dois arquivos: config e credentials. A versão 1.2.9 acabou de produzir um arquivo de configuração (mas com as informações de credencial). Quando apaguei as credenciais e o arquivo de configuração produzido pela versão 1.10 e copiei o arquivo de configuração produzido pela versão 1.2.9 tudo funcionou, mesmo com caracteres especiais e rodando o awscli versão 1.10. O arquivo de configuração produzido pela versão 1.2.9 é

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

Pode confirmar que é devido a caracteres não alfanuméricos.

Tenho o mesmo problema com uma chave secreta contendo um +. No entanto, não sou o proprietário da conta S3 e não consigo criar uma nova facilmente. Alguém encontrou alguma correção além de criar uma nova chave sem caracteres especiais?

tl; dr Solução: recriar repetidamente as credenciais ATÉ que sua aws_secret_access_key NÃO contenha caracteres não alfanuméricos ... no meu caso aws_secret_access_key continha um + (sinal de mais)

Acabei de fazer uma nova instalação ... mesmo problema ... isso é no Ubuntu ... não é um problema de sistema operacional local, é um problema de API da Amazon, então ignore outros comentários que dizem que sair do OSX corrige isso

aws ec2 describe-instances

Ocorreu um erro (AuthFailure) ao chamar a operação DescribeInstances: AWS não foi capaz de validar as credenciais de acesso fornecidas

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

aws ec2 describe-security-groups

Ocorreu um erro (AuthFailure) ao chamar a operação DescribeSecurityGroups: AWS não foi capaz de validar as credenciais de acesso fornecidas

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

aws ecr get-login

Ocorreu um erro (InvalidSignatureException) ao chamar a operação GetAuthorizationToken: A assinatura da solicitação que calculamos não corresponde à assinatura fornecida. Verifique sua chave de acesso secreta da AWS e método de assinatura. Consulte a documentação do serviço para obter detalhes.

A seqüência canônica para esta solicitação deveria ter sido
'PUBLICAR
/

tipo de conteúdo
host: ecr.us-east-1.amazonaws.com
x-amz- date: 20160615T182955Z
x-amz- target: AmazonEC2ContainerRegistry_V20150921.GetAuthorizationToken

content-type; host; x-amz-date; x-amz-target
44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a '

O String-to-Sign deveria ter sido
'AWS4-HMAC-SHA256
20160615T182955Z
20160615 / us-east-1 / ecr / aws4_request
86c2e3c850acd6765a1ca6aa626c6e9a6c85284f3954f45e170f51b5b89961c7 '

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

usuários da lista de aws iam

Ocorreu um erro (SignatureDoesNotMatch) ao chamar a operação ListUsers: A assinatura da solicitação que calculamos não corresponde à assinatura fornecida. Verifique sua chave de acesso secreta da AWS e método de assinatura. Consulte a documentação do serviço para obter detalhes.

A seqüência canônica para esta solicitação deveria ter sido
'PUBLICAR
/

host: iam.amazonaws.com
x-amz- date: 20160615T183516Z

host; x-amz-date
b6359072c78d70ebee1e81adcbab4f01bf2c23245fa365ef83fe8f1f955085e2 '

O String-to-Sign deveria ter sido
'AWS4-HMAC-SHA256
20160615T183516Z
20160615 / us-east-1 / iam / aws4_request
ad9f7581f0bf25ecae56355a6c96b60f3dc3188efbbdb3d0d4806e9f2c5cf8a9 '

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

aws - versão
aws-cli / 1.10.38 Python / 2.7.11 + Linux / 4.4.0-22-botocore genérico / 1.4.28

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

cat /root/.aws/credentials
[padrão]
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

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

SOLUÇÃO:
Depois de excluir e criar novas credenciais
onde aws_secret_access_key NÃO tinha o sinal de mais (+) tudo estava bem acima dos comandos começaram a funcionar bem

Eu tive o mesmo problema. Recriar as credenciais até que não tivesse nenhum caractere especial funcionou para mim.

Descobri que, quando copiei e colei as credenciais, elas tinham ^ M caracteres no final que estavam causando o erro.

Obter uma chave secreta sem + consertou para mim também ...

Observação - se você estiver vendo esse problema no dock (boot2docker VM'd), pode ser que o relógio da VM esteja fora de sincronia.
Consulte: http://stackoverflow.com/questions/24551592/how-to-make-sure-dockers-time-syncs-with-that-of-the-host

Estou tendo o mesmo problema. E se eu não tiver permissões para regenerar as credenciais ... alguma correção possível de outras maneiras?

ATUALIZAÇÃO: Corrigi isso executando rm -rf .aws/cli/cache/

Também estou tendo esse problema agora. Ao tentar assumir o papel

Versão:
aws-cli/1.11.17 Python/2.7.10 Darwin/16.1.0 botocore/1.4.74

Edit: Também tentei atualizar novamente agora, mesmo problema:
aws-cli/1.11.18 Python/2.7.12 Darwin/16.1.0 botocore/1.4.75

Saída:

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'

O mesmo problema ainda existe com a versão mais recente (atualizada) do AWS CLI. Acabei de atualizar meu 1.8.3 CLI para 1.11.19 - e não consegui executar nenhum comando com um novo usuário / chaves que criei. Tive que reiniciar cerca de 5 chaves antes de obter um par em que a chave secreta não tinha caracteres não alfabéticos. Uma vez que me deparei com esse par - CLI funciona bem.

Muito chato - eu gostaria que a Amazon não gerasse chaves inválidas que eles não podem processar ...

@ mpopova-yottaa você tentou limpar completamente o cache do awe-cli? Tente excluir todo o diretório ~/.aws (faça uma cópia de seus arquivos de configuração / credencial)

aws ec2 describe-instances corre para mim, mas ao tentar criar uma pilha de formação de nuvem:

`` `Exceção no thread" main "com.amazonaws.services.cloudformation.model.AmazonCloudFormationException: A assinatura da solicitação que calculamos não corresponde à assinatura que você forneceu. Verifique sua chave de acesso secreta da AWS e método de assinatura. Consulte a documentação do serviço para obter detalhes.

A seqüência canônica para esta solicitação deveria ter sido
'PUBLICAR
/

amz-sdk-invocation-id: 18d13b66-80ae-f676-c0cf-dbf875edb1aa
amz-sdk- retry: 3/345/470
host: cloudformation.us-west-1.amazonaws.com
user- agent: 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- date: 20161127T194448Z

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

O String-to-Sign deveria ter sido
'AWS4-HMAC-SHA256
20161127T194448Z
20161127 / us-west-1 / cloudformation / aws4_request
cb0286a8727afcc465171ab991accde0aaa7210e160a9ba3196e2a5e4305f428 '(Serviço: AmazonCloudFormation; Código de status: 403; Código de erro: SignatureDoesNotMatch; ID de solicitação: f52abbd4-b4d9-11e6-b7989)

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

A chave secreta contém apenas alfanuméricos, então estou preso.

@ aebrow4 Está no cache para awe-cli. Tente excluir: .aws/cli/cache/

@cultavix não existe um cli dentro de .aws

Recebi este erro ao executar aws glacier upload-archive com --archive-description "`date`" . Quando eu uso --archive-description "`date +%Y/%m/%d`" ele funciona bem, então parece haver algum problema de escape.

Eu estava tendo um problema semelhante:

λ 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.

Tentei sincronizar a hora com um servidor NTP (com sucesso), mas isso não resolveu o problema. Regenerando chaves até que eu tivesse um conjunto sem caracteres especiais corrigido.

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

Eu tenho o mesmo problema ao usar o awscli e o código Python de amostra (boto3).
Observe que estou usando o IBM Object Storage S3 compatível com api, posso listar buckets e seus conteúdos, mas não posso fazer upload (tanto para código pyhton quanto cli).
Testei o cenário com ruby aws-sdk e funciona bem (upload / download).
- configuração
aws-cli/1.2.9 Python/3.4.3 Linux/3.19.0-33-generic

Acabei de começar a ter o mesmo problema com um script que venho usando há meses para depositar uploads de várias partes no Glacier. Ainda é possível depositar sem problemas por meio do aws cli, então as credenciais ainda funcionam, mas o script usando boto3 falha com:

"botocore.exceptions.ClientError: Ocorreu um erro (InvalidSignatureException) ao chamar a operação InitiateMultipartUpload: A assinatura da solicitação que calculamos não corresponde à assinatura que você forneceu. Verifique sua chave de acesso secreta da AWS e método de assinatura. Consulte a documentação do serviço para obter detalhes."

aws - versão é
aws-cli / 1.11.38 Python / 2.7.10 Darwin / 15.6.0 botocore / 1.5.1

(sim, eu atualizei tudo pensando que poderia resolver o problema ... não tive essa sorte.)

obter um novo par de chaves sem nenhum caractere especial (era + no meu caso) corrigiu o problema para mim

outra confirmação aqui de manuseio incorreto de + na chave secreta.

Olá a todos, aqui está um script que usei para tentar reproduzir esse problema: https://gist.github.com/jamesls/00ef7fcc0ac39ba8b06956d165c42f6d . Isso é o que o script faz:

• Cria um novo par access_key / secret_key via aws iam create-access-key em um loop até encontrar credenciais que tenham um + ou um / char.
• Ele cria um novo perfil "testcreds" com essas credenciais recém-geradas
• Ele tenta invocar vários comandos AWS CLI para garantir que essas credenciais funcionem

Ele faz isso em um loop infinito até que uma chamada de API falhe. Até agora, não consegui fazer com que ele falhasse. As chaves secretas que têm + e / estão funcionando para mim.

Neste ponto, confirmamos que é definitivamente possível usar secret_keys que têm + ou / então não acho que a causa raiz seja algo tão simples quanto um bug em nosso código de assinatura que quebra quando + está presente. Relendo os comentários neste tópico, pode ser um problema em como as credenciais estão sendo inseridas no arquivo ~/.aws/config ou ~/.aws/credentials . Talvez haja alguma coisa específica da plataforma que está alterando caracteres que contêm + ou / .

Portanto, para qualquer pessoa que ainda esteja enfrentando esse problema, seria muito útil se você pudesse fornecer algumas informações adicionais:

1. Como você está obtendo credenciais (copiar / colar do console, aws iam create-access-key , arquivo CSV do console, etc)?
2. Como você está configurando o CLI para usar essas credenciais? Você está executando aws configure e inserindo os valores quando solicitado? Você está fazendo isso programaticamente executando aws configure set ? Você está editando ~/.aws/config e / ou ~/.aws/credentials manualmente? Definindo os vários AWS_* env vars?

Bonificações que seriam ainda mais úteis, se possível:

1. Se você usa outros SDKs, essas credenciais que não funcionam na CLI funcionam em outros SDKs da AWS?
2. Se você tem uma conta de teste ou um usuário de teste IAM, a execução do script que estou usando para testar falha em você?

Qualquer informação adicional que possa nos ajudar a reproduzir este problema de nossa parte seria ótima.

Eu ainda estou tendo esse problema. Para responder às suas perguntas:
Criou credenciais no console amazon e recortou / colou em ~ / .aws / credentials (editado com emacs em um mac)

Com base na solução de problemas que fiz até agora (e sou um novato nisso ...), a 'String canônica' está correta, mas a 'String-para-assinar' está errada, tendo uma última linha diferente. Ou seja, quando eu imprimo o valor de retorno de auth.py string_to_sign, o número produzido de 'sha256 (canonical_request.encode (' utf-8 ')). Hexdigest ())' é diferente do número relatado no erro retornado "The String -to-Assinar deveria ter sido ".

Não há caracteres especiais em minhas credenciais e funcionam ao usar outras ferramentas, por exemplo, CrossFTP (que não quero usar !!!)

Qualquer introspecção seria muito bem recebida!!

@ samato88, isso parece ser um problema diferente aqui. Se você pudesse compartilhar qualquer informação de depuração (certificando-se de remover todas as informações confidenciais), isso ajudaria.

O string_to_sign não é influenciado pela secret_access_key. Quando assinamos uma solicitação, pegamos a solicitação HTTP que estamos prestes a enviar, convertemos em uma string (ou seja, a string ou sinal) e, em seguida, usando a chave secreta, assinamos essa string com a chave secreta (pulando alguns detalhes aqui). Portanto, quaisquer problemas com a string a ser assinada seriam separados deste problema.

Você poderia abrir outro problema e fornecer a saída --debug (ou incluir a solicitação completa e a mensagem de erro do serviço)? Ficaríamos felizes em cuidar disso para você.

Obrigado jamesls - Abri um problema separado em:
https://github.com/aws/aws-cli/issues/2474

Todos os insights são muito apreciados.

Se o tempo do seu sistema estiver atrasado por mais de 5 minutos, você não poderá usar o CLI

apenas corra ... sudo ntpdate -s time.nist.gov

então tente novamente

Eu tive o mesmo problema, minha chave secreta contém o sinal "+". Excluí meu arquivo .aws / credentials e executei novamente o aws configure. Depois disso, minha consulta à fila de sqs para receber mensagens funcionou.

Obrigado @ AlexParra03 . Eu tive o mesmo problema e seus comentários me ajudaram a resolver .... :-)

@robotzero você se lembra de como inseriu suas credenciais? Você executou aws configure e, em seguida, copiou / colou os valores do console da web?

Sim, executei o aws configure e copiei e colei os valores.

Sim, eu tinha um + no meu segredo, o que causou esse erro ainda. Fazer novas chaves sem caracteres especiais resolveu o problema.

aws - versão
aws-cli / 1.11.78 Python / 3.6.1 Darwin / 15.6.0 botocore / 1.5.41

Tinha um + e um / no meu segredo. Os segredos sem isso resolveram o problema para mim.

Também tive esse problema.

$ 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

Tinha um "+" nas credenciais. Foi resolvido regenerando a chave de acesso sem eles. Como uma nota: "/" é um bom personagem para se ter.

@adityanatraj @shwetapurushe @damienrj vocês podem responder a essas perguntas aqui ? Neste ponto, estamos tentando obter mais informações sobre o seu ambiente e como você está inserindo as credenciais. Conforme mencionado nesse comentário, gerar uma chave secreta com + não reproduz o problema para nós, portanto, possivelmente está relacionado a uma combinação de seu ambiente e / ou como você está inserindo credenciais.

Em outras palavras, precisamos de mais informações das pessoas para que possamos solucionar o que está acontecendo.

@jamesls

1. Como consegui as credenciais?

Consegui as credenciais copiando-as do console da web.

1. Como eu configuro a CLI para usá-los?

Eu criei manualmente os dois arquivos:

~ / .aws / config

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

~ / .aws / credentials

[default]
aws_access_key_id = ACCESS_KEY_HERE 
aws_secret_access_key = SECRET_ACCESS_KEY_THAT_BREAKS_WITH_A_+_SIGN

Não posso ajudar com as perguntas bônus, pois limpei minhas chaves de acesso contendo os sinais '+', então o problema não apareceu.

@adityanatraj obrigado, tudo ajuda.

A próxima etapa que nos ajudará a solucionar o problema é descobrir se esse é um problema apenas com a CLI ou com as próprias credenciais. Para qualquer pessoa que ainda esteja enfrentando esse problema, seria muito útil se você pudesse tentar essas credenciais em outros SDKs da AWS. Para ajudar com isso, eu coloquei um repositório / script de amostra que torna isso fácil se você não quiser configurar isso sozinho: https://github.com/jamesls/aws-creds-test . Basta clonar o repo e executar 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.

Para quem está enfrentando esse problema, execute o script de teste e compartilhe a saída.

Essa mesma exceção aconteceu comigo em uma solicitação PutObject (C #), sempre que os metadados do objeto tinham caracteres Unicode.

Eu tive o mesmo problema. Novas chaves secretas com + e / não funcionam. Eu gerei novas chaves sem esses personagens e eles funcionam bem.
Seu script de teste é para Linux e estou executando o Windows.
Colei minhas credenciais usando Control-C e Control-V usando windows shell e _aws configure_
e eu estava usando apenas _aws cp_

Também testei e funciona bem, desde que a chave secreta não tenha símbolos, conforme mencionado acima.

Espero ver isso resolvido em breve, é uma dor ter que continuar regenerando as credenciais até que eu consiga uma que funcione!

Eu levantei um tíquete de suporte para AWS ontem, e hoje parece estar resolvido

Eu testei várias vezes e + e / agora parecem funcionar? Não consigo mais reproduzir esse bug.

Eu tive o mesmo problema no meu Pi.
Com o awscli mais recente (aws-cli / 1.11.85 Python / 3.4.2 Linux / 4.9.24-v7 + botocore / 1.5.48), eu ainda tinha o problema:

root @ pi : ~ # aws s3 ls s3: //
Ocorreu um erro (SignatureDoesNotMatch) ao chamar a operação ListBuckets: A assinatura da solicitação que calculamos não corresponde à assinatura que você forneceu.
Verifique sua chave de acesso secreta e método de assinatura. Para obter mais informações, consulte Autenticação REST e Autenticação SOAP para obter detalhes.

Mesmo com uma chave secreta sem caracteres especiais (+ ou /) o acesso não funcionou. A hora estava sempre sincronizada, infelizmente esse também não era o problema.

No arquivo ".aws / config" eu adicionei uma região válida (apenas para teste ..) e de repente funcionou. Como estou usando armazenamento s3 compatível (não s3 da Amazon)

[padrão]
aws_secret_access_key = MYKEY
aws_access_key_id = MYID
region = us-east-1 <- havia um valor "fictício" antes.

Ao que parece, a região deve ter um valor "correto". Quando eu mudo de volta para algo diferente como "valor fictício", obtenho o mesmo erro mencionado acima.
Agora com o valor "us-east-1" ele funciona!
Espero que isso ajude alguém.

Eu também corri para isso. Também parece haver um problema com um '+' na chave secreta. Se eu tiver os creds nas variáveis ​​de ambiente, recebo o erro. Se eu colocá-los no arquivo ~ / .aws / credentials (editando manualmente), não recebo o erro.

[editar] Acabei de notar que as variáveis ​​de ambiente estavam em um arquivo formatado para DOS (ff = dos no vim). Foi isso porque eu tinha acabado de pegar o arquivo .csv baixado e editado para transformar as entradas em variáveis ​​de ambiente. Quando reformatei o arquivo em 'ff = unix', não recebi mais o erro. A única diferença entre os 2 é o retorno da linha, dos usa "CR-NL" enquanto o unix é apenas "NL". Meu palpite é que, na verdade, esse personagem "CR" era o problema.

eu também, e também confirme o problema "+"

Se você se deparar com isso ao usar o Docker para Mac, basta reiniciar o Docker para corrigir a discrepância de tempo do sistema.

Eu estava enfrentando o mesmo problema.
Foi verificado o segredo e havia + / nele.
Tive que criar um novo par de id sem um caractere especial para fazê-lo funcionar

Criar novos pares de chaves até que eu tenha um sem caracteres especiais resolvido para mim também; caracteres especiais (especificamente +) simplesmente não funcionam em ~ / .aws / credentials.

A chave gerada sem caracteres especiais (especificamente + ) também corrigiu o problema para mim.

Formatar o arquivo de acordo com o comentário de

Excluir a chave e criar uma nova funcionou para mim.

Acabei de receber este erro. A hora do sistema foi atualizada, que parecia estar a mais de 6 minutos do GMT. Corrigido o problema imediatamente.

Foi tão estranho e complicado para mim.
Eu lutava com esse problema e estava tentando muitas vezes resolvê-lo.
No momento, de repente funcionou! Fiquei surpreso, então fiz um novo balde, mas não funcionou. Como não fiz nada, exceto mudar o código, esperei horas. Por fim, funcionou bem, embora eu não tenha feito nada. Não acredito ...

Usando aws configure em um shell bash no Windows 7, descobri que tinha duas linhas aws_secret_access_key em meu .aws/credentials e a segunda linha era onde eu havia digitado incorretamente um monte de lixo . Exclua a segunda linha e tudo funcione.

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

Vendo esse problema no Linux Mint aqui, sem + na minha chave ou segredo.

Resultado do script de teste:

/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

Depois de atualizar o awscli para 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

Acabei de recriar minhas chaves - Minha nova ainda contém um '+', mas agora posso usar o cli

Pode ser tão fácil quanto isso

@ DanAbbz92 na verdade, aconteceu de eu encontrar a mesma solução agora. Não tenho ideia de por que as chaves antigas nunca funcionaram, mas as novas funcionavam bem usando o mesmo processo.

Eu tinha um ^ V na minha chave secreta de uma tentativa de colagem incorreta. Pode ser prudente colocar um aviso mais forte na verificação de caracteres ruins nas chaves. Impedirá mais escalonamentos desnecessários.

Esse problema foi relatado em 2014. Hoje é 26 de outubro de 2017. Encontrei esse problema, meu segredo tinha um "+" nele. Eu criei uma nova chave e coloquei em ~ / .aws / configure
Vamos Amazon, você já planejou consertar esse bug * ???

Eu encontrei esse problema hoje depois de instalar o cli e executar aws configure . Minhas chaves não tinham caracteres especiais, mas o seguinte corrigiu meu problema:

• rm -r ~/.aws/
• recriou a pasta .aws e o arquivo credentials e adicionou as credenciais manualmente

tl; dr desligá-lo e ligá-lo novamente funcionou para mim ¯_ (ツ) _ / ¯

Para pessoas que usam o Hadoop e acabam aqui: Um bug relacionado foi corrigido para o Hadoop 2.8.0:
" s3:" URLs quebram quando a chave secreta contém uma barra, mesmo se codificada

Oi, hoje eu peguei o mesmo problema.
A caixa estava com a hora errada. Depois de atualizar o tempo, tudo está funcionando.

Adicionando outro "eu também"

Eu tinha uma chave secreta com dois caracteres '+' e funcionava a partir do meu arquivo .aws / credentials em minha VM do Windows (quando usada por um aplicativo .NET), mas quando instalei o awscli do brew no meu MacBook Pro , e copiou os arquivos .aws (testando as codificações de arquivo, formatos de fim de linha, etc.), falhou com SignatureDoesNotMatch.

Tentei recriar as credenciais até obter uma chave secreta sem nenhum valor não alfanumérico e agora funciona a partir do awscli no meu Mac. Copiar essas credenciais de volta para minha máquina Windows e executar o aplicativo .NET, que ainda funciona.

Não fiz nenhuma alteração na hora em nenhuma das máquinas (o Mac já estava usando NTP e a VM do Windows parece estar executando cerca de 12 minutos atrás da hora real)

Eu instalei o awscli com: brew install awscli

e aws --version retorna: aws-cli / 1.14.30 Python / 3.6.4 Darwin / 16.7.0 botocore / 1.8.34

Bem, enviei o código para lambdas esta tarde (01/02/2018 15:48 EST com lambda em us-east-1).
Agora, às 18h, estou recebendo erros de assinatura em todos os sistemas do escritório.
Olhando para trás neste tópico: meus tempos estão corretos, nada mudou, as credenciais têm menos de um ano, estão funcionando desde o dia em que foram estabelecidas, usando a versão homebrew aws-cli/1.14.30 Python/3.6.4 Darwin/17.4.0 botocore/1.8.34 (tentei fazer o downgrade para 1.14. Versão 2x, sem amor)

Isso é um pouco malarky

Tendo o mesmo problema e resolvido a geração de novas chaves sem nenhum caractere especial (como /, + e assim por diante).

Obrigado @hellais pela contribuição!

Só tive o mesmo problema, resolvi corrigindo o relógio do meu laptop. Aparentemente, eu estava atrasado.

Acabei de experimentar esse problema e parece que meu cliente ntp estava 10 minutos atrasado. Eu fiz um ntpdatee tudo agora está consertado.

Posso confirmar que recriar minhas chaves de acesso até conseguir uma sem caracteres especiais funcionou. Que inseto ridículo, uau.

Visto que esse é um problema de longa duração, não seria inteligente atualizar a mensagem de erro para fornecer aos usuários um link para uma possível correção, como reconstruir suas chaves? Em vez de algo que diga que o problema é muito mais complexo do que "sim, nós erramos quando suas chaves têm caracteres especiais, desculpe!".

mesmo problema ouvir:

Versões:

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

Comando:

aws s3 ls
obteve o seguinte erro:
Unknown Signature Version: s3v3.

nenhuma solução:

atualizei minha capa e gerei um segredo sem nenhum personagem especial

update - corrigido pelo seguinte

aws configure set default.s3.signature_version s3v4

Sim, isso ainda é um problema - minha chave secreta terminou com um caractere + e nenhuma correção que encontrei funcionou. Novas chaves regeneradas sem + no final da chave secreta e funcionou bem.

Como diabos isso ainda é um problema?

Ocorreu um erro (SignatureDoesNotMatch) ao chamar a operação CreateMultipartUpload: A assinatura da solicitação que calculamos não corresponde à assinatura que você forneceu. Verifique sua chave e método de assinatura.
por favor ajude.

Meu segredo começa com o sinal + e eu nem sabia que havia esse problema até hoje. Eu uso boto3 python para acessar meu s3. Não funciona quando passo credenciais como strings brutas, mas funciona bem se eu carrego-o do config.ini como uma variável usando configparser.RawConfigParser() . Obviamente, gerar um novo segredo sem o sinal + no final ou no início também resolverá esse problema.

No entanto, se isso (por algum motivo) não puder ser corrigido, talvez mude a mensagem de exceção para algo como "não permitimos sinal +, gere um novo se quiser acessá-lo da maneira que você faz".

Estou usando o aws cli no osx e também tinha um segredo que parecia não estar correto. Meu original tinha + e = nele e recebi o erro SignatureDoesNotMatch ao tentar transferir cp arquivos para s3. Regenerei as chaves e meu novo segredo agora é uma string alfanumérica. Basta adicionar outra confirmação de que a regeneração funciona. :aliviado:

Na esperança de que isso possa fornecer uma visão, este problema (não lidar com + em chaves secretas) se expõe com esta versão no 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

mas não ocorre com esta versão no Ubuntu

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

Comecei em janeiro de 2014 e agora em junho de 2018, há mais de 4 anos e tive o mesmo problema com o erro SignatureDoesNotMatch . A solução para mim foi a mesma que todas as soluções da maioria aqui, pegue uma nova chave secreta sem nenhum caractere especial, pois minha chave anterior tem dois pontos : , tentei sincronizar a hora, mas não está funcionando para mim. Estou usando WSL.

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

Apenas atualizando o que @gchiu disse em abril de 2017: ainda é o caso em junho de 2018 que segredos que contêm o caractere de barra (/) podem fazer o cliente PHP não funcionar (PHP 7 no Windows 10 no meu caso), retornando o _signatures not match_ error. Nessa situação, basta gerar outro par de chaves mais seguro.

Fiquei perplexo com isso por cerca de 30 minutos.

Acompanhado este problema e verificado a hora local, etc. - tudo estava bem.

Em desespero, nukou o arquivo ~/.aws/credentials e logou novamente (essencialmente recriando o arquivo) e voila, simplesmente funciona.

Eu me pergunto por que ele lança esse erro, afinal!

EDITAR:
Não parece estar relacionado à chave secreta no meu caso; eram todos strings simples.

1 sobre este assunto, minha chave começou com um = . Regenerou uma chave que só tinha / e estava tudo bem. Tentei encerrar a chave com " marcas, mas sem sucesso.

Não é algo que eu esperaria ver do AWS CLI.

Acrescentando ao mesmo problema aqui, não posso acreditar que o / na minha chave teria causado isso. Obrigado pelo tempo perdido!

Eu tive esse problema. Acredito que tenha sido o resultado da instalação inicial do aws cli como usuário root. A resolução parecia ser a desinstalação do aws cli, excluindo a pasta .aws da pasta inicial do usuário atual e também da pasta raiz e, em seguida, executando o 'aws configure' novamente como o usuário atual.

Eu experimentei esse problema ao executar um script bash usando um cronômetro systemd no Ubuntu. Ao executar manualmente o script com meu usuário, tudo funcionou bem. No entanto, o cronômetro continuaria gerando o erro (SignatureDoesNotMatch). Percebi então que (SignatureDoesNotMatch) foi produzido para qualquer comando aws executado como root e que 'aws configure' não salvou os novos valores fornecidos.

Para resolver o problema eu loguei como root 'su -i', mudei para 'cd ~ / .aws /' e removi a configuração com 'sudo rm -r credentials', executei 'aws configure' novamente e desta vez os novos valores foi salvo. A partir daí tudo funcionou novamente como esperado!

Pode-se confirmar que esse problema ainda existe em 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.

E descobri que havia um + no meu segredo. Regenerei e está tudo bem agora. Quando podemos esperar uma correção para este @jamesls? Ou posso fazer algo para ajudar?

Enfrentei o mesmo em meu aws cli porque a chave secreta continha + ... (conforme descrito acima) Depois de regenerar uma nova chave .. (como vi no comentário delmartechdude acima) ... o problema foi resolvido.

Meus dois centavos. Ele estava me dando este erro porque eu estava tentando fazer upload de conteúdo para s3 com transferências aceleradas desta forma (costumava funcionar no passado): --endpoint-url http://imaat.s3-accelerate.amazonaws.com ( --endpoint-url http://<bucket-name>.s3-accelerate.amazonaws.com ) conforme especificado nas propriedades do endpoint de aceleração :

Seguindo as instruções nos documentos oficiais: https://docs.aws.amazon.com/es_es/AmazonS3/latest/dev/transfer-acceleration-examples.html Substituí a última parte por: --endpoint-url http://s3-accelerate.amazonaws.com e executei o comando aws configure set s3.addressing_style virtual para construir o nome do host dinamicamente. Verifique: https://docs.aws.amazon.com/cli/latest/topic/s3-config.html#addressing -style

Não sei por que, mas agora funciona. Meu nome de intervalo ("imaat") não tem nenhum caractere especial que pode levar a falhas de DNS, mas falhou por algum motivo com as últimas atualizações cli.

Adicionando um perfil via edição de texto e obtive esta falha. Atualizar o ID de acesso e o segredo do perfil por meio de um conjunto de configurações do aws e funcionou. Isso é para um segredo com '+' nele e aws-cli / 1.16.23 Python / 2.7.15 Windows / 10 botocore / 1.12.13

@dave-miles Você está no caminho certo, obrigado por comentar! Estou expandindo sua descoberta abaixo:

Eu encontrei esse problema com algumas imagens do docker. Originalmente, eu estava usando um ADD no dockerfile para adicionar o arquivo ~ / .aws / credentials ao contêiner.

Se fizéssemos isso, encontraríamos o erro SignatureDoesNotMatch ao tentar fazer o download do s3.

Removi a linha ADD do dockerfile, reconstruí e lancei um novo contêiner do docker. Neste novo contêiner, executei manualmente aws configure set aws_access_key_id <access key id goes here> e aws configure set aws_secret_access_key <secret access key goes here> Esta foi a primeira vez que inseri as informações de credenciais neste contêiner (ou seja, o contêiner era uma imagem de centos "nova").

Depois de usar os comandos aws configure set , consegui fazer o download do s3 com sucesso.

Para qualquer pessoa que use isso com um dockerfile, você pode usar instruções RUN no dockerfile para executar os dois comandos ou pode usar uma instrução ADD para enviar um script para seu contêiner do docker:

#! / bin / sh

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

Eu tive o mesmo problema que @villasenor - um + na chave secreta causaria o erro ao configurar o awscli usando env vars no docker. girar as chaves resolveu o problema.

Idem aqui, mas não há caracteres especiais na chave de acesso ou na chave secreta.
Um novo conjunto foi gerado novamente para o mesmo usuário IAM, e os novos podem listar os intervalos, os antigos não.

Isso ocorreu com chamadas AWS cli e Java SDK. Sugerindo que a falha não está nos clientes ...

Ambos os conjuntos ainda estão ativos. Se alguém da Amazon quiser mais detalhes entre em contato.

Meu colega de trabalho também encontrou isso. Tentei depurar criando uma chave de acesso até obter uma com + ou / no início. Não foi capaz de reproduzir, no entanto.

Eu tive uma experiência de colega de trabalho isso. Determinamos que isso ocorre especificamente no Ubuntu 18.04 com + ou / na chave secreta.

Recebi o mesmo erro hoje, atualmente usando o Windows 10. No entanto, quando eu uso a mesma chave de acesso em outro laptop (mac), ela funciona bem para mim. Então tentei a chave de acesso dentro do WSL, o que também é bom. Não tenho certeza do motivo e não há nenhum caractere especial na chave aws.

Estou tendo este erro com um conjunto de chaves de acesso e não com o outro.
Conforme mencionado em vários outros posts aqui, minha chave como um '/' nele. Para mim, esse problema parece um problema simples de codificação / decodificação do servidor ou dos clientes usando o padrão de codificação URI RFC e o outro não o usa.
Pretendo executar os scripts de teste mencionados e tentar reproduzir os erros.

Para outras pessoas aqui, encontrei o erro, mas tinha credenciais incorretas armazenadas em cache na minha pasta ~ / .aws. Ele verifica primeiro lá e depois as variáveis ​​de ambiente.

Estou experimentando isso no Windows 10 usando Git Bash. Funciona perfeitamente com o Powershell. A invocação do Python é obviamente diferente, mas é o mesmo módulo Python e Python. Também tenho + e / na minha chave.

Eu só tive esse problema e, para mim, a solução foi remover os espaços. exemplo.
em vez do padrão de:
[profilename]
aws_access_key_id = MYAWSACCESSKEYID
aws_secret_access_key = MYAWSSECRETACCESKEY
Eu mudei para:
[profilename]
aws_access_key_id=MYAWSACCESSKEYID
aws_secret_access_key=MYAWSSECRETACCESKEY

observe a falta de espaços ao redor de =. Isso corrigiu para mim e eu tenho + e / na minha chave também.

Todos, existem algumas dicas incríveis de solução de problemas aqui. Vou transformar isso em uma página na seção Solução de problemas no Guia do usuário CLI. Obrigado pelas contribuições!

Olá a todos,

Posso ver que há muitas respostas aqui, mas para mim foram os caracteres especiais na chave de acesso secreta da AWS. O meu começou com "= +", mas quando gerei um novo sem caracteres especiais no console da web, ele começou a funcionar imediatamente.

Estou executando o awscli em um shell Zsh no Ubuntu no 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

Espero que isso seja útil para outros.

Obrigado
Jonathan

Apenas mergulhei 4 horas de depuração nisso até que encontrei este tópico. Eu poderia usar o s3 cli localmente sem problemas, mas ao executá-los no circleci, recebi este erro: SignatureDoesNotMatch ..

Como outros sugeriram, minha chave de acesso secreta continha um caractere + e, após gerar uma nova chave, tudo começou a funcionar.

Seria quase impossível depurar sem este tópico

Obrigado @blbradley . Era exatamente o problema que eu tinha.

teve o mesmo problema - a solução foi excluir as variáveis ​​de ambiente do Windows com credenciais obsoletas da AWS

Tive o problema também no boto3 Python3.
O meu começa com =/

Estou em uma máquina virtual tornando o host Time & Region semelhante ao guest Time & Region resolve o problema.

Só queria dizer que isso me atingiu hoje também em uma chave recém-criada - e depois de muita frustração, parei aqui e vi a menção de / na chave. Com certeza, esse era o problema - nova chave sem funcionar. Wtf ?!

Não posso acreditar que esse problema foi aberto em 2014 e ainda não há uma correção para ele, esse bug me forçou a fazer um novo conjunto de credenciais AWS para mim mesmo, eu até tentei codificar o '/', mas não funcionou :(

Eliminar a credencial com "/" corrigiu o problema para mim. Obrigado a todos por apontar isso.

Basta atingir isso em 2020 agora. A chave secreta tem um '+'.

aws-cli - desenvolvido pelo projeto aws - falha com chaves aws válidas ... por 6 anos?

O mesmo problema em janeiro de 2020. A chave secreta tem um caractere de barra "/".

Eu gerei um novo conjunto de credenciais, usando o console AWS IAM, e assegurei que a chave secreta fosse alfanumérica, sem "/" não "+" e assim por diante. Substituí minha chave secreta antiga pela nova chave secreta em meu arquivo ~ / .aws / credentials e tentei novamente.

Isso resolveu tudo.

O mesmo problema aqui em 2020. Mas não posso remover nenhum caractere alfanumérico, pois eles fazem parte das minhas credenciais, e não estou no controle disso

Apenas gere novamente a credencial até se livrar dos personagens. Geralmente, são necessárias apenas mais uma ou duas tentativas.

Maurice

De: columb1a [email protected]
Enviado: terça-feira, 21 de janeiro de 2020 13:47
Para: aws / aws-cli [email protected]
Cc: Maurice Bizzarri [email protected] ; Comentário [email protected]
Assunto: Re: [aws / aws-cli] Erro SignatureDoesNotMatch (# 602)

O mesmo problema aqui em 2020. Mas não posso remover nenhum caractere alfanumérico, pois eles fazem parte das minhas credenciais, e não estou no controle disso

-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente, visualize-o no 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 & dados = 02% 7C01% 7Cmaurice% 40bizzarrisoftware.com% 7Cf6f2e8a571954134b76b08d79ebb6bee% 7C9aa15552370449f5ac56c2850c165d32% 7C1% 7C0% & 7C637152400117352225 sdata = 2Z6PQRSvKD0P8Eu0yrs15Ypi6GgtFvaDi7qewAq5yH4% 3D & reservados = 0 , ou de cancelamento 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

Eu primeiro tive problemas de tempo limite e depois de atualizar meu awscli encontrei esse problema. Você pensou que 6 anos é o suficiente para fazer funcionar ...

também estou implantando o aplicativo Vue.js por meio do gitlab para o intervalo AWS S3, alguém pode me dizer o que fazer
msg: erro

Eu não tinha nenhum caractere não alfanumérico, mas trabalhar com perfilado não funcionou, para um único perfil. Eu gerei novamente as credenciais usando o console e as novas funcionaram.

Receber esses erros também hoje e regenerar as credenciais sem caracteres especiais ('+' ou '/') funciona para mim.

Continuo com o mesmo problema, mas acontece de repente, trabalho com operações Get e Put e uma funciona, a outra não. e sim minha chave secreta não contém nenhum caractere especial. qualquer ajuda? Primeiro chamo getIntent (API de modelos amazon lex) para recuperar a soma de verificação de intents e, em seguida, chamo putIntent para atualizar esse intent. O método get funciona (nem sempre), mas o método put apresenta o mesmo problema de assinatura, enquanto se eu removesse a API do método Get do código, o método Put funcionaria 2 vezes em três.

Eu tive esse problema, sugiro que você gere novas chaves
e reconfigurar seu perfil aws

aws configure

AWS Access Key ID [ * * * * QD5E]: AWS_ACCESS_KEY_ID
Chave de acesso secreto da AWS [ * * * * ANjA]: AWS_SECRET_ACCESS_KEY
Nome da região padrão [eu-west-3]: AWS_REGION
Formato de saída padrão [json]: OUTPUT_FORMAT

Oi !

Estou tendo o mesmo problema ao usar um URL pré-assinado retornado ao meu cliente
A URL é gerada no servidor (por tempo limitado). O servidor é python e não vejo nenhum erro lá, mas o cliente é JS - apenas pega a URL e abre. Parte do URL são credenciais geradas para este recurso)

O erro está ligado e desligado, então acho que está relacionado ao que é dito aqui sobre chaves especiais nas credenciais, mas como estou usando credenciais geradas no servidor - não posso alterá-las!

Alguma maneira de cuidar disso no código? analisar as chaves especiais de alguma forma?

Oi !

Estou tendo o mesmo problema ao usar um URL pré-assinado retornado ao meu cliente
A URL é gerada no servidor (por tempo limitado). O servidor é python e não vejo nenhum erro lá, mas o cliente é JS - apenas pega a URL e abre. Parte do URL são credenciais geradas para este recurso)

O erro está ligado e desligado, então acho que está relacionado ao que é dito aqui sobre chaves especiais nas credenciais, mas como estou usando credenciais geradas no servidor - não posso alterá-las!

Alguma maneira de cuidar disso no código? analisar as chaves especiais de alguma forma?

@ maya-harel, você pode alterar as credenciais de IAM -> os usuários selecionam o usuário que você criou e geram novamente a guia de credenciais de segurança de chave secreta.

além disso, o tempo no código é realmente fatal, para cada solicitação que você fizer no back-end, obtenha a hora atual para usá-la no cabeçalho para gerar a assinatura.

Como um aparte, tem havido muitas sugestões cegas de "regenerar suas credenciais de IAM" para usuários que disseram explicitamente que não é uma opção para eles.

Isso não é útil para os usuários e desvia o fato de que este é um bug conhecido que continua a afetar os usuários do aws-cli que tentam usar credenciais válidas do IAM.

Correndo para isso também.
$ aws - versão
aws-cli / 1.16.300 Python / 2.7.16 Linux / 4.14.152-127.182.amzn2.x86_64 botocore / 1.13.36

Minhas chaves são totalmente alfanuméricas, sem caracteres especiais.

As chaves funcionam a partir do shell, no entanto, quando usadas por meio do Jenkins em um destino Makefile, esse erro ocorre. Não tenho certeza do que está acontecendo aqui.

Minha chave secreta contém / e + . Encontrando este problema e tentei:

• Trough aws-cli > aws iam get-user (usando ~/.aws/credentials file)
• boto3 (por meio de python 3.6.8)
  
  
  
  • Chaves codificadas
  
  
  • Variável de Ambiente
  
  
  • Argumento boto3.Session(profile_name=PROFILE) (extraído de ~ / .aws / credentials)
  
  

Tudo isso resulta no erro SignatureDoesNotMatch .

Atualmente, não consigo regenerar a chave.

O que não entendi é que posso usar o protocolo S3 no Cyberduck (https://cyberduck.io/) e funciona conforme o esperado. Como poderia ser?

Este deve ser um dos bugs mais frustrantes que encontrei e é doido que não foi corrigido. Obter uma credencial sem um "+" funcionou para mim no CircleCI.

Ainda está travando? enfrentando o mesmo problema, uau eu não posso ser possível ...

Sim, é frustrante. Minha chave secreta que tinha um + não funcionou em um pipeline do Jenkins, mas quando eu gerei um novo, que tinha apenas alguns / , funcionou bem.

Tive esse problema na versão do pacote instalado do awscli no Ubuntu 16.04. Eu corrigi-lo instalando awscli como um pacote Python pip.
Para obter instruções, siga este link na seção Instalando AWS CLI usando Python PIP

_ Problema encontrado _

1) Encontrado o erro InvalidSignatureException após regenerar a chave de acesso
2) O registro de erro parcial é fornecido a seguir.

$ python SetupAWS.py list_things
Traceback (última chamada mais recente):
Arquivo "SetupAWS.py", linha 222, em
list_things ()
Arquivo "SetupAWS.py", linha 182, em list_things
coisas = client.list_things () ['coisas']
Arquivo "c: Arquivos de programas (x86) Python38-32libsite-packagesbotocore-1.16.6-py3.8.eggbotocoreclient.py", linha 316, em _api_call
return self._make_api_call (operation_name, kwargs)
Arquivo "c: Arquivos de programas (x86) Python38-32libsite-packagesbotocore-1.16.6-py3.8.eggbotocoreclient.py", linha 626, em _make_api_call
aumentar error_class (parsed_response, operation_name)
botocore.exceptions.ClientError: Ocorreu um erro (InvalidSignatureException) ao chamar a operação ListThings: A assinatura da solicitação que calculamos não corresponde à assinatura fornecida. Verifique sua chave de acesso secreta da AWS e método de assinatura. Consulte a documentação do serviço para obter detalhes.

_ Análise de causa raiz _

1) Como sugerido por muitos em seus comentários acima, a presença de "+" em minha chave de acesso secreta estava resultando no erro acima.

_ Resolução _

1) Gerou uma nova chave de acesso como um usuário IAM e verificou que a nova chave de acesso secreta não contém um "+" na string.
2) Execute o comando aws configure e forneça os novos valores.
3) Executei o comando

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

Esta edição está aberta há seis anos e agradeço sua paciência, persistência e as informações que você forneceu. Algumas causas subjacentes foram identificadas por meio de seus comentários (https://github.com/aws/aws-cli/issues/602#issuecomment-520469209) e compiladas no capítulo Command Line User Guide

Tentei reproduzir isso usando vários ambientes diferentes. Usei Ubuntu 16.04, Ubuntu 18.04 e Amazon Linux 2, com Python 3.6.8 e 3.8.3. Embora muitos comentaristas usem Python 2, não tentei reproduzi-lo, pois não há mais suporte para ele. Usei a última v1 aws-cli (1.18.80 no momento da escrita), bem como uma versão mais antiga (1.11.78) mencionada neste problema. Usei o script fornecido (https://github.com/aws/aws-cli/issues/602#issuecomment-281866173) por @jamesls que cria novos pares de credenciais até encontrar um com caracteres especiais e deixá-los funcionar por até uma hora cada. Eu não tive nenhuma ocorrência de um erro SignatureDoesNotMatch . Recebi erros ocasionais de AuthFailure no comando describe-instances, mas uma nova tentativa do comando com as mesmas credenciais é bem-sucedida.

O grande número de comentários torna difícil para novos usuários que abordam esse problema encontrar solicitações de nossa equipe de desenvolvedores para sugestões de solução de problemas. Para ajudar nossa equipe e a comunidade a determinar a causa desse erro, estou encerrando este problema e criando um modelo de problema específico no GitHub que inclui orientações e requisitos de comentários para usuários que encontrarem esse erro.

Se você encontrar esse erro, vá até a guia de problemas, clique no botão “Novo problema” e use o modelo para um relatório de erro SignatureDoesNotMatch (ou use o link abaixo).

Devido à variação dos ambientes do usuário onde esse erro ocorre, registre um problema separado em vez de comentar sobre um existente.

Clique aqui para enviar um relatório de erro SignatureDoesNotMatch