Ik heb een nieuwe toegangssleutel gemaakt en die in de AWS CLI geconfigureerd met aws configure. Het heeft het bestand .inigemaakt in ~/.aws/config. Als ik aws s3 lsuitvoer, krijg ik:
Er is een clientfout (InvalidAccessKeyId) opgetreden bij het aanroepen van de ListBuckets-bewerking: de door u opgegeven AWS-toegangssleutel-ID komt niet voor in onze gegevens.
AmazonS3FullAccess-beleid is ook gekoppeld aan de gebruiker. Hoe dit op te lossen?
Antwoord 1, autoriteit 100%
Het kan gebeuren dat u de oude sleutels hebt geëxporteerd via env-variabelen (bash_profile) en aangezien de env-variabelen een hogere prioriteit hebben dan referentiebestanden, geeft het de foutmelding “het toegangssleutel-ID bestaat niet”.
Verwijder de oude sleutels uit het bash_profile en je bent klaar om te gaan.
Het is me een keer eerder overkomen toen ik vergat dat ik inloggegevens in bash_profile had en ik kreeg er geruime tijd hoofdpijn van 🙂
Antwoord 2, autoriteit 86%
Het lijkt erop dat er al enkele waarden zijn ingesteld voor de omgevingsvariabelen AWS_ACCESS_KEY_IDen AWS_SECRET_ACCESS_KEY.
Als het zo is, zou je enkele waarden kunnen zien bij het uitvoeren van de onderstaande commando’s.
echo $AWS_SECRET_ACCESS_KEY
echo $AWS_ACCESS_KEY_ID
U moet deze variabelen opnieuw instellen als u aws configure
gebruikt
Voer onderstaande commando’s uit om te resetten.
unset AWS_ACCESS_KEY_ID
unset AWS_SECRET_ACCESS_KEY
Antwoord 3, autoriteit 32%
Moet AWS_SESSION_TOKENtoevoegen aan inloggegevens, samen met AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY
Antwoord 4, autoriteit 11%
Geen van de positieve antwoorden werkt voor mij. Ten slotte geef ik de inloggegevens door in het python-script, met behulp van de client-API.
import boto3
client = boto3.client(
's3',
aws_access_key_id=ACCESS_KEY,
aws_secret_access_key=SECRET_KEY,
aws_session_token=SESSION_TOKEN)
Houd er rekening mee dat het argument aws_session_token optioneel is. Niet aanbevolen voor openbaar werk, maar maak het leven gemakkelijker voor een eenvoudige proef.
Antwoord 5, autoriteit 8%
Ik heb de fout gemaakt om mijn variabelen als volgt tussen aanhalingstekens te zetten:
AWS_ACCESS_KEY_ID="..."
Antwoord 6, autoriteit 6%
Voor mij vertrouwde ik op IAM EC2 rolesom toegang tot onze machines te geven aan specifieke bronnen.
Ik wist niet eens dat er een credentials-bestand was op ~/.aws/credentials, totdat ik enkele van onze toegangssleutels op de IAM-console draaide/verwijderde om onze beveiliging aanscherpen, en dat zorgde ervoor dat een van de scripts plotseling stopte met werken op een enkele machine.
Het verwijderen van dat credentials-bestand loste het voor mij op.
Antwoord 7, autoriteit 5%
Mogelijk moet u de omgevingsvariabele AWS_DEFAULT_REGIONinstellen.
Antwoord 8, autoriteit 5%
Misschien hebt u de AWS-inloggegevens correct geconfigureerd, maar als u deze inloggegevens gebruikt, maakt u mogelijk verbinding met een specifiek S3-eindpunt (zoals bij mij het geval was).
In plaats van te gebruiken:
aws s3 ls
probeer:
aws --endpoint-url=https://<your_s3_endpoint_url> s3 ls
Ik hoop dat dit degenen helpt die met hetzelfde probleem worden geconfronteerd.
Antwoord 9, autoriteit 3%
u kunt profielen configureren in het bash_profile-bestand met
<profile_name>
aws_access_key_id = <access_key>
aws_secret_access_key = <acces_key_secret>
als u meerdere profielen gebruikt. gebruik dan:
aws s3 ls --profile <profile_name>
Antwoord 10, autoriteit 3%
Ik ben op zoek naar informatie over dit probleem en heb dit bericht gevonden. Ik weet dat het oud is, maar ik wil dit bericht graag verlaten voor het geval iemand problemen heeft.
Ok, ik heb de AWS CLIgeïnstalleerd en geopend:
Het lijkt erop dat u aws configuremoet uitvoeren om de huidige inloggegevens toe te voegen. Eenmaal gewijzigd, heb ik toegang
Antwoord 11, autoriteit 2%
Het lijkt erop dat ~/.aws/credentialsniet is gemaakt. Probeer het handmatig te maken met deze inhoud:
[default]
aws_access_key_id = sdfesdwedwedwrdf
aws_secret_access_key = wedfwedwerf3erfweaefdaefafefqaewfqewfqw
(in mijn testbox, als ik de opdracht awsuitvoer zonder een inloggegevensbestand, is de fout Unable to locate credentials. You can configure credentials by running "aws configure".)
Kun je proberen deze twee commando’s uit te voeren vanuit dezelfde shell die je probeert uit te voeren aws:
$ export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
$ export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
en probeer dan de opdracht aws.
Antwoord 12, autoriteit 2%
een ander ding dat dit kan veroorzaken, zelfs als alles correct is ingesteld, is het uitvoeren van de opdracht vanuit een Makefile. ik had bijvoorbeeld een regel:
awssetup:
aws configure
aws s3 sync s3://mybucket.whatever .
toen ik make awssetupuitvoerde, kreeg ik de fout: fatal error: An error occurred (InvalidAccessKeyId) when calling the ListObjects operation: The AWS Access Key Id you provided does not exist in our records.. maar het uitvoeren vanaf de opdrachtregel werkte.
Antwoord 13, autoriteit 2%
Nog een antwoord toegevoegd omdat alle bovenstaande gevallen niet voor mij werkten.
Controleer in de AWS-console uw inloggegevens (Mijn beveiligingsreferenties) en kijk of u de juiste inloggegevens hebt ingevoerd.
Dankzij deze discussie:
https://forums.aws.amazon.com/message.jspa?messageID= 771815
Antwoord 14, autoriteit 2%
Voor degenen onder u die aws s3 lsgebruiken en deze uitzondering krijgen. Zorg ervoor dat u machtigingen heeft voor alle regio’s onder het opgegeven AWS-account. Wanneer u aws s3 lsuitvoert, probeert u alle s3-buckets onder het AWS-account te trekken. daarom, in het geval dat u niet over alle regio’s beschikt, krijgt u deze uitzondering – An error occurred (InvalidAccessKeyId) when calling the ListBuckets operation: The AWS Access Key Id you provided does not exist in our records.
Volg Uw regio’s beschrijven met behulp van de AWS CLIvoor meer info.
Antwoord 15, autoriteit 2%
Ik had hetzelfde probleem in Windows en bij het gebruik van de module aws-sdkvan javascript. Ik heb mijn IAM-inloggegevens gewijzigd en het probleem blijft bestaan, zelfs als ik de nieuwe inloggegevens op deze manier geef via de methode-update
s3.config.update({
accessKeyId: 'ACCESS_KEY_ID',
secretAccessKey: 'SECRET_ACCESS_KEY',
region: 'REGION',
});
Na een tijdje ontdekte ik dat de module aws-sdk een bestand had aangemaakt in de map Gebruiker op Windows met dit pad
C:\Users\User\.aws\credentials
. De inloggegevens in dit bestand hebben voorrang op de andere gegevens die door de methode-update zijn doorgegeven.
De oplossing voor mij was om hier te schrijven
C:\Users\User\.aws\credentials
de nieuwe inloggegevens en niet met de methode s3.config.update
Antwoord 16, autoriteit 2%
Exporteer de onderstaande variabelen uit het referentiebestand uit de onderstaande map.
path = .aws/
filename = credentials
export aws_access_key_id = AK###########GW
export aws_secret_access_key = g#############################J
Antwoord 17, autoriteit 2%
In mijn geval probeerde ik een nieuwe bucket in te richten in de regio Hong Kong, die niet standaard is ingeschakeld, volgens dit:
https://docs.aws.amazon.com/general/latest/ gr/s3.html
Het is niet helemaal gerelateerd aan de vraag van OP, maar aan het onderwerp op zich, dus als iemand anders zoals ik vast komt te zitten in dit randgeval:
Ik moest die regio handmatig inschakelen voordat ik in die AWS s3-regio werkte, volgens deze handleiding: https://docs.aws.amazon.com/general/latest/gr/rande-manage.html
Antwoord 18
Ik probeer onderstaande stappen en het werkte:
1. cd ~
2. cd .aws
3. vi-referenties
4. verwijderen
aws_access_key_id =
aws_secret_access_key =
door de cursor op die regel te plaatsen en op dd te drukken (vi-commando om regel te verwijderen).
Verwijder zowel de lijn- als de controleversterking.
Antwoord 19
Als je een AWS Educate-account hebt en je krijgt dit probleem:
Er is een fout opgetreden (InvalidAccessKeyId) bij het aanroepen van de ListBuckets-bewerking: de door u opgegeven AWS-toegangssleutel-ID bestaat niet in onze gegevens”.
De oplossing is hier:
-
Ga naar je
C:/-station en zoek naar de map.awsin je hoofdmap in Windows. -
In die map krijg je het “credentials”-bestand en open je het met Kladblok.
-
Plak de hele sleutelreferentie van het AWS-account in hetzelfde kladblok en sla het op.
-
Nu bent u klaar om uw AWS Educate-account te gebruiken.
Antwoord 20
Dit kan gebeuren omdat er een probleem is met uw AWS Secret Access Key. Na wat rommelen met AWS Amplify, kwam ik dit probleem tegen. De snelste manier is om een nieuw paar AWS Access Key IDen AWS Secret Access Keyaan te maken en aws configureopnieuw uit te voeren.
Ik werk voor mij. Ik hoop dat dit helpt.
Antwoord 21
Ervan uitgaande dat u Access Key IDen Secretal hebt gecontroleerd… wilt u misschien het bestand team-provider-info.jsoncontroleren welke is te vinden onder de map amplify/
"awscloudformation": {
"AuthRoleName": "<role identifier>",
"UnauthRoleArn": "arn:aws:iam::<specific to your account and role>",
"AuthRoleArn": "arn:aws:iam::<specific to your account and role>",
"Region": "us-east-1",
"DeploymentBucketName": "<role identifier>",
"UnauthRoleName": "<role identifier>",
"StackName": "amplify-test-dev",
"StackId": "arn:aws:cloudformation:<stack identifier>",
"AmplifyAppId": "<id>"
}
IAM-rol waarnaar hier wordt verwezen, moet actief zijn in de IAM-console.
Antwoord 22
Als je deze fout krijgt in een Amplify-project, controleer dan of "awsConfigFilePath"niet is geconfigureerd in amplify/.config/local-aws-info. json
In mijn geval moest ik het verwijderen, dus mijn omgeving zag er als volgt uit:
{
// **INCORRECT**
// This will not use your profile in ~/.aws/credentials, but instead the
// specified config file path
// "dev": {
// "configLevel": "project",
// "useProfile": false,
// "awsConfigFilePath": "/Users/dev1/.amplify/awscloudformation/cEclTB7ddy"
// },
// **CORRECT**
"dev": {
"configLevel": "project",
"useProfile": true,
"profileName": "default",
}
}
Antwoord 23
Misschien moet je je api-sleutels in de webconsole activeren, ik zag net dat de mijne om de een of andere reden inactief waren…
Antwoord 24
Bedankt, iedereen. Dit hielp bij het oplossen.
Er is op de een of andere manier iets gebeurd waardoor de toetsen zijn veranderd & Ik realiseerde me niet dat alles goed werkte totdat ik verbinding maakte met S3 vanaf een vonk … toen begon vanaf de opdrachtregel ook een fout te komen, zelfs in AWS s3 ls
Stappen om op te lossen
- Voer AWS-configuratie uit om te controleren of de toetsen zijn ingesteld (verifieer vanaf de laatste 4 tekens en blijf gewoon op enter drukken)
- AWS-console –> Gebruikers –> klik op de gebruiker –> ga naar beveiligingsgegevens–> controleer of de sleutel dezelfde is die wordt weergegeven in AWS-configuratie
- Als beide niet hetzelfde zijn, genereer dan een nieuwe sleutel, download csv
- loop –> AWS configureren, nieuwe sleutels instellen
- probeer nu AWS s3 ls
Verander de sleutels op alle plaatsen, in mijn geval waren het configuraties in Cloudera.
Antwoord 25
Ik kon er niet achter komen hoe ik het systeem mijn Vocareum-inloggegevens kon laten accepteren, dus maakte ik gebruik van het feit dat als u uw instantie configureert om IAM-rollen te gebruiken, selecteert de SDK automatisch de IAM-referenties voor uw toepassing, zodat u niet handmatig inloggegevens.
Zodra een rol met de juiste machtigingen was toegepast op de EC2-instantie, hoefde ik geen inloggegevens op te geven.
Antwoord 26
Open het bestand ~/.bash_profileen bewerk de informatie met de nieuwe waarden die je hebt ontvangen toen je de nieuwe gebruiker aanmaakte:
export AWS_ACCESS_KEY_ID=
export AWS_SECRET_ACCESS_KEY=
export AWS_DEFAULT_REGION=us-east-1
Voer daarna het commando uit:
source ~/.bash_profile
Hierdoor worden de nieuwe sleutels voor de lokale computer ingeschakeld. Nu moeten we de informatie ook in de terminal configureren. Voer de opdracht uit –
aws configure
Geef de nieuwe waarden zoals gevraagd en je bent klaar om te gaan.
Antwoord 27
In mijn geval gebruikte ik aws configure
Ik heb het bestand .aws/configechter met de hand bewerkt om de KeyID en de belangrijkste omgevingsvariabelen te exporteren.
Dit veroorzaakte blijkbaar een stille fout en zag de hierboven vermelde fout.
Ik heb dit opgelost door de directory .awste vernietigen en aws configureopnieuw uit te voeren.
Antwoord 28
Hopelijk bespaart dit anderen urenlange frustratie:
bel aws.config.update({) voordat u s3 initialiseert.
const AWS = require('aws-sdk');
AWS.config.update({
accessKeyId: 'AKIAW...',
secretAccessKey: 'ptUGSHS....'
});
const s3 = new AWS.S3();
Credits voor dit antwoord:
https://stackoverflow.com/a/61914974/11110509
Antwoord 29
Ik ben dit probleem tegengekomen bij het exporteren van RDS Postgres-gegevens naar S3volgens deze officiële gids.
TL;DR Tips voor het oplossen van problemen:
- Reset RDS-inloggegevens met:
DROP EXTENSION aws_s3 CASCADE; DROP EXTENSION aws_commons CASCADE; CREATE EXTENSION aws_s3 CASCADE; - De rol van de DB-instantie verwijderen en toevoegendie wordt gebruikt voor de functie
s3Export. Optioneel reset RDS-inloggegevens (vorig actiepunt) daarna nogmaals.
Hieronder vindt u meer details over mijn zaak.
In het bijzonder ben ik het volgende tegengekomen:
[XX000] ERROR: could not upload to Amazon S3
Details: Amazon S3 client returned 'The AWS Access Key Id you provided does not exist in our records.'.
Om export naar S3 te kunnen uitvoeren, moet de RDS DB-instantie worden geconfigureerd om een rol aan te nemen met toestemming om naar S3-bucket te schrijven, de handleidingbeschrijft deze stappen.
De reden van een fout was in de aws_s3.query_export_to_s3Postgres-procedure met enkele (in de cache?) ongeldige veronderstelde inloggegevens. Ik weet nog steeds niet welke inloggegevens het heeft gebruikt, maar ik ben erin geslaagd hetzelfde gedrag te bereiken met AWS CLI:
- Ik heb een rol aangenomen (
aws sts assume-role), - En probeerde vervolgens een andere actie uit te voeren (met name
aws s3 cp) met deze inloggegevens zonder sessietoken (alleenAWS_ACCESS_KEY_IDenAWS_SECRET_ACCESS_KEYzonderAWS_SESSION_TOKEN).
Dit resulteerde in dezelfde fout van AWS CLI: An error occurred (InvalidAccessKeyId) when calling the PutObject operation: The AWS Access Key Id you provided does not exist in our records.
Kortom: hard resetten van RDS-inloggegevens heeft geholpen.