Ik cd
in de map waar alle pem/key-bestanden staan en voer het volgende uit:
aws iam upload-server-certificate
--server-certificate-name certificate_name
--certificate-body file://webservercertificate.pem
--private-key file://server.key
--certificate-chain file://certificate_chain_file.pem
Ik krijg de volgende foutmelding:
Er is een clientfout (InvalidClientTokenId) opgetreden bij het aanroepen van de
UploadServerCertificate-bewerking: het beveiligingstoken dat is opgenomen in de
verzoek is ongeldig.
Ik heb 1 ‘gebruiker’ in ‘gebruikers’. Aan die gebruiker zijn de volgende rechten toegewezen:
IAMFullAccess IAMReadOnlyAccess IAMUserSSHKeys
Ik heb de inloggegevens voor deze gebruiker gedownload en in mijn gebruikersvariabelen geplaatst
AWS_ACCESS_KEY ****
AWS_SECRET_KEY ****
Ik heb 1 rol op mijn elastische bonenstaak aws-elasticbeanstalk-ec2-role
Antwoord 1, autoriteit 100%
Probeer naar de beveiligingsgegevens op uw accountpagina te gaan:
Klik op je naam in de rechterbovenhoek -> Mijn beveiligingsgegevens
Genereer dan daar toegangssleutels en gebruik die toegangssleutels in uw inloggegevensbestand (aws configure)
Antwoord 2, autoriteit 84%
Als u de CLI met MFAgebruikt, moet u naast de toegangs- en geheime sleutels ook het sessietoken instellen. Raadpleeg dit artikel:
https://aws.amazon.com/premiumsupport/knowledge-center/ authenticate-mfa-cli/
Antwoord 3, autoriteit 31%
In mijn geval waren er twee verschillende ‘AWS_SECRET_ACCESS_KEY’ en ‘AWS_ACCESS_KEY_ID-waarden die een variabele en één via de opdrachtregel worden ingeschakeld.
Werk deze twee en de standaard_region bij met behulp van een opdrachtregel
> aws configure
Druk op ENTER en volg de stappen om het juiste te vullen
AWS_ACESS_KEY_ID
aws_secret_access_key
EN AWS_DEFAULT_REGION
> aws sts get-caller-identity
moet de nieuwe set-inloggegevens retourneren
4, Autoriteit 22%
Als u ook een sessie-token hebt gekregen, moet u het handmatig instellen na configure
:
aws configure set aws_session_token "<<your session token>>"
5, Autoriteit 20%
Probeer het juiste profiel te exporteren, d.w.z. $ export AWS_PROFILE="default"
Als u alleen een standaardprofiel hebt, zorg er dan voor dat de toetsen correct zijn en RERUNEN aws configure
6, Autoriteit 16%
Ik had dezelfde fout, zelfs na het opnieuw uitvoeren van aws configure
, en invoer een nieuwe AWS_ACESS_KEY_ID
en aws_secret_access_key
.
Wat was het opgelost voor mij om mijn ~/.aws/credentials
-bestand te verwijderen en opnieuw uit te voeren aws configure
.
Het lijkt erop dat mijn bestand ~/.aws/credentials
een extra waarde had: AWS_SESSION_TOKEN
die de fout veroorzaakte. Na het verwijderen en opnieuw aanmaken van de ~/.aws/configure
met het commando aws configure
, zijn er nu alleen waarden voor aws_access_key_id
en aws_secret_access_key
.
Antwoord 7, autoriteit 10%
- Klik op uw gebruikersnaam bovenaan, Mijn beveiligingsreferenties
- Klik op het tabblad Toegangssleutel, Nieuwe maken, kopieer de sleutel en het geheim.
- Voer vanaf de terminal
$ aws configure
uit en gebruik de nieuwe sleutel en geheim. -
Voer de opdracht opnieuw uit:
serverless invoke local --function create --path mocks/create-event.json
Antwoord 8, autoriteit 10%
Dit is mij overkomen bij het gebruik van java sdk. Het probleem voor mij was dat ik de sessietoken van de aangenomen rol niet gebruikte.
Voorbeeld van werkende code ( in kotlin )
val identityUserPoolProviderClient = AWSCognitoIdentityProviderClientBuilder
.standard()
.withCredentials(AWSStaticCredentialsProvider(BasicSessionCredentials("accessKeyId", ""secretAccessKey, "sessionToken")))
.build()
Antwoord 9, autoriteit 10%
Ik moest het AWS-profiel specificeren om --profile default
expliciet te gebruiken om van deze fout af te komen tijdens het uitvoeren van AWS CLI-opdrachten. Ik kon echter niet begrijpen waarom het dit profiel niet automatisch oppikte, aangezien er alleen een [dafault]
profiel aanwezig was in mijn aws-configuratie- en inloggegevensbestand.
Ik hoop dat dit helpt.
Gegroet,
Kunal
Antwoord 10, autoriteit 6%
U gebruikt op de een of andere manier verkeerde AWS-referenties (AccessKey en SecretKey) van het AWS-account. Zorg er dus voor dat ze correct zijn, anders moet u nieuwe maken en gebruiken – in dat geval kan @Prakash het antwoord goed voor u zijn
Antwoord 11, autoriteit 6%
Ik had dezelfde fout maar werd veroorzaakt door een ander probleem.
De inloggegevens zijn gewijzigd op AWS, maar ik gebruikte nog steeds een MFA-sessietoken in de cache voor het configuratieprofiel.
Er is een cachebestand voor elk profiel onder ~/.aws/cli/cache/
met daarin de sessietoken.
Verwijder het cachebestand, geef de opdracht opnieuw op en voer een nieuwe MFA-token in en u kunt aan de slag.
Antwoord 12, autoriteit 6%
Dit kan ook gebeuren als u MFA hebt uitgeschakeld. Er zal een oude langetermijnvermelding zijn in de AWS-inloggegevens.
Bewerk het bestand handmatig met een editor naar keuze, hier met vi (gelieve eerst een back-up te maken):
vi ~/.aws/credentials
Verwijder vervolgens het gedeelte [default-long-term]. Als resultaat in een minimale installatie zou er één sectie [default]over moeten zijn met de daadwerkelijke inloggegevens.
[default-long-term]
aws_access_key_id = ...
aws_secret_access_key = ...
aws_mfa_device = ...
Antwoord 13, autoriteit 6%
Vergelijk het antwoord van Pat, controleer uw omgevingsvariabelen.
Met name AWS_SESSION_TOKEN
EN AWS_SECURITY_TOKEN
Probeer ze uit te schakelen: unset VAR_NAME
Om te zien welke variabelen zijn ingesteld, probeer env | grep AWS
en verwacht zoiets als:
AWS_REGION=ap-southeast-2
AWS_PAGER=
AWS_SECRET_ACCESS_KEY=...
AWS_ACCESS_KEY_ID=...
AWS_SESSION_TOKEN=...
AWS_SECURITY_TOKEN=...
Antwoord 14, autoriteit 2%
Ik dacht dat je het kon vermijden door gewoon de –no-sign-request param door te geven, zoals:
aws --region us-west-2 --no-sign-request --endpoint-url=http://192.168.99.100:4572 \
s3 mb s3://mytestbucket
Antwoord 15, autoriteit 2%
In mijn situatie was het probleem te wijten aan het draaien van powershell als beheerder, dus zocht het naar de aws-referenties in de hoofdmap van mijn beheerder. Er is waarschijnlijk een betere manier om dit op te lossen, maar wat voor mij snel werkte, was mijn .aws-map opnieuw maken in de hoofdmap van mijn admin-gebruiker.
Antwoord 16, autoriteit 2%
Ik had de toegangssleutel en de geheime sleutel door elkaar gehaald 🙂
Antwoord 17
Ik was in staat om AWS cli volledig geauthenticeerd te gebruiken, dus voor mij lag het probleem zeker binnen terraform. Ik heb alle bovenstaande stappen geprobeerd zonder succes. Een herstart loste het voor mij op, er moet ergens een cache ergens in terraform zijn die dit probleem veroorzaakte.
Antwoord 18
Dit is raar, maar in mijn geval telkens wanneer ik de toegangs-ID en de sleutel opnieuw wilde typen door aws configure
te typen.
Het toevoegen van de ID-toegang eindigt altijd met een puinhoop in het toegangs-ID-item in het bestand ~/.aws/credentials
(zie de afbeelding)
Ik heb deze puinhoop verwijderd en alleen de toegangs-ID achtergelaten. En de fout is opgelost.
Antwoord 19
Ik had een soortgelijk probleem toen ik mijn django-applicatie implementeerde over elastische Beanstalk en wat ik ontdekte was toen ik verschillende methoden probeerde, op de een of andere manier werd er een eb-cli-profiel gemaakt in het configuratiebestand in de map ~/.aws/, dus zodra ik verlost van dat alles werkte prima!!.
Antwoord 20
Ik had een soortgelijk probleem bij het uploaden van een certificaat met behulp van de cli.
Ik moest een programmatische toegang gebruiken van een nieuw aangemaakte iam-gebruiker (met zijn eigen sleutels).
De MFA die ik gebruikte om mezelf te authenticeren bij de AWS-console (web) in mijn AWS-account, stoorde bij het gebruik van de opdracht aws configure met de nieuwe iam-gebruikersreferenties voor programmatische toegang. In het nieuwe referentiebestand (gemaakt met de opdracht aws configure) was het sessietoken uit het MFA-logboek op de een of andere manier behouden. Handmatig verwijderen uit het inloggegevensbestand heeft de sessietoken in mijn geval geholpen.