Hoe kan ik de fout “Het beveiligingstoken dat is opgenomen in het verzoek is ongeldig” oplossen bij het uitvoeren van aws iam upload-server-certificate?

Ik cdin 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_IDaws_secret_access_keyEN 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_IDen 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/credentialseen extra waarde had: AWS_SESSION_TOKENdie de fout veroorzaakte. Na het verwijderen en opnieuw aanmaken van de ~/.aws/configuremet het commando aws configure, zijn er nu alleen waarden voor aws_access_key_iden aws_secret_access_key.


Antwoord 7, autoriteit 10%

  1. Klik op uw gebruikersnaam bovenaan, Mijn beveiligingsreferenties
  2. Klik op het tabblad Toegangssleutel, Nieuwe maken, kopieer de sleutel en het geheim.
  3. Voer vanaf de terminal $ aws configureuit en gebruik de nieuwe sleutel en geheim.
  4. 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 defaultexpliciet 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_TOKENEN AWS_SECURITY_TOKEN

Probeer ze uit te schakelen: unset VAR_NAME

Om te zien welke variabelen zijn ingesteld, probeer env | grep AWSen 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 configurete 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.

Other episodes