SSH naar mijn AWS-server is net verbroken voor zowel Putty als Filezilla. Ik doe mijn best om van dit bericht een uitgebreide lijst voor probleemoplossing te maken, dus als u links naar andere pagina’s met overloop van stapels deelt, zal ik deze in de vraag aanpassen.

Disconnected : No supported authentication methods available (server sent :publickey)

De fout is bekend van toen ik bijna een jaar geleden de verbinding tot stand bracht. Als u AWS SSH voor de eerste keer instelt, lossen deze de meest voorkomende problemen op:

• Onjuiste gebruikersnaam:Verbinding verbroken : Geen ondersteunde authenticatiemethoden beschikbaar (server verzonden: publickey)
• Onjuist .ppk-bestand:Niet mogelijk om verbinding te maken met de Amazon-server met behulp van putty

Echter, het enige dat ik kon bedenken dat van invloed zou zijn op een eerder werkend systeem is:

• Onjuist IP-adres:Het herstarten van een AWS-instantie (of het maken van een afbeelding) houdt niet gegarandeerd hetzelfde IP-adres. Dit zou natuurlijk in stopverf moeten worden bijgewerkt.

Welke andere mogelijkheden zijn er?

Oplossing voor deze (volgens het geaccepteerde bericht hieronder) is dat voor AWS EC2 alle 3 de juiste machtigingen moeten hebben (777 nietok voor een van deze). Hier is een voorbeeld dat werkt:

/home/ec2-user/ - 700
/home/ec2-user/.ssh/ - 600
/home/ec2-user/.ssh/authorized_keys - 600

/var/log/secure zal je vertellen welke een fout geeft, raadpleeg deze video-tutorial om toegang te krijgen als je volledig bent buitengesloten:
http://d2930476l2fsmh.cloudfront.net/LostKeypairRecoveryOfLinuxInstance.mp4

Antwoord 1, autoriteit 100%

Bij mij verscheen deze fout onmiddellijk nadat ik de homedirectory van de gebruiker had gewijzigd met

sudo usermod -d var/www/html username

Het kan ook gebeuren door een gebrek aan de juiste toestemming voor het geautoriseerde_sleutelbestand in ~/.ssh. Zorg ervoor dat de toestemming van dit bestand 0600 is en dat de toestemming van ~/.ssh 700 is.

Antwoord 2, autoriteit 90%

Ik had per ongeluk hetzelfde probleem. Ik zal het hier delen, voor het geval iemand dezelfde fout heeft gemaakt.

Basisstappen, zoals anderen beschreven.

1. Download putty en puttygen, of het putty-pakket en installeer het.
2. Haal het .pem-bestand van uw AWS EC2-instantie.
3. Gebruik puttygen om het .pem-bestand te converteren zodat je een privésleutel hebt — hier is een fout opgetreden. Ik koos het tabblad “Conversies” van PuttyGen en laad mijn .pem-bestand. Na het laden van het pem-bestand, klik hier NIET op “Genereren”, maar direct op “Save private key”. Dat is de sleutel die je nodig hebt. Als je op Genereren klikt, heb je een totaal ander sleutelpaar.
4. Gebruik in putty [email protected], en laad de privésleutel op SSH/Auth

Veel succes!

Antwoord 3, autoriteit 95%

Er is nog een andere oorzaak die van invloed kan zijn op een eerder werkend systeem. Ik heb mijn instances opnieuw gemaakt (met AWS OpsWorks) om Amazon Linux te gebruiken in plaats van Ubuntu, en kreeg deze foutmelding nadat ik dit had gedaan. Overschakelen naar het gebruik van “ec2-user” als gebruikersnaam in plaats van “ubuntu” loste het probleem voor mij op.

Antwoord 4, autoriteit 127%

PuTTY biedt geen native ondersteuning voor de private key-indeling (.pem) die wordt gegenereerd door Amazon EC2. PuTTY heeft een tool genaamd PuTTYgen, die sleutels kan converteren naar het vereiste PuTTY-formaat (.ppk). U moet uw privésleutel naar deze indeling (.ppk) converteren voordat u probeert verbinding te maken met uw instantie met behulp van PuTTY.

De stappen om dit uit te voeren worden hier beschreven: https:// docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html

Dit loste het probleem op.

Antwoord 5, autoriteit 118%

Uitgebreid antwoord vindt u hier: https://docs.aws.amazon .com/AWSEC2/latest/UserGuide/putty.html

Uw probleem kan te maken hebben met onjuiste aanmeldingdie varieert afhankelijk van AMI’s.
Gebruik de volgende logins op de volgende AMI’s:

• ubuntuof rootop ubuntu AMI’s
• ec2-gebruikerop Amazon Linux AMI
• centosop Centos AMI
• debianof rootop Debian AMI’s
• ec2-gebruikerof fedoraop Fedora
• ec2-gebruikerof rootop: RHEL AMI, SUSE AMI, andere.

Als u een besturingssysteem gebruikt:

• Windows– haal de PEM-sleutel van de AWS-website en genereer een PPK-bestand met PuttyGen. Gebruik vervolgens Putty om de PPK te gebruiken (selecteer het met behulp van de linkerkolom: Connection->SSH->Auth: Private key voor autorisatie)
• Linux– voer uit: ssh -i your-ssh-key.pem login@IP-or-DNS

Veel succes.

Antwoord 6, autoriteit 18%

in de meeste gevallen geen authenticatiemethodefout opgetreden bij het gebruik van de verkeerde gebruikersnaam om in te loggen. Maar ik vind wel iets anders als je nog steeds worstelt met verbindingsproblemen en je alle bovenstaande opties hebt geprobeerd.

Ik heb een paar Linux VM’s gemaakt en probeer een dergelijk verbindingsprobleem te reproduceren, een ding dat ik ontdekte, was dat toen AWS je vroeg om je sleutelpaar een naam te geven, GEEN lege ruimte (” “) en punt (“.”) in het sleutelpaar gebruikt naam, zelfs AWS staat u dit toe.

bijv. toen ik het sleutelpaar “AWS.FREE.LINUX” noemde, werd de verbinding altijd geweigerd. Als ik de naam “AWS_FREE_LINUX” noem, werkt alles prima.

Hopelijk helpt dit een beetje.

Antwoord 7, autoriteit 18%

Geen privésleutel genereren

Uw probleem is, wanneer puttygen wordt geopend, laadt u file-from-aws.pemu klikt op Genereer dit is verkeerd, klik gewoon op de knop privésleutel opslaan

Antwoord 8, autoriteit 9%

In mijn geval was het probleem dat het ppk-bestand in de map %USERPROFILE%\Downloads werd geplaatst in plaats van de map %USERPROFILE%.ssh.

Nadat ik het bestand had verplaatst, was het probleem verdwenen.

Antwoord 9, autoriteit 9%

Aanmelding is afhankelijk van de AMI die u heeft gemaakt. Gebruik de gegevens aan de linkerkant als gebruikersnaam tijdens het inloggen.

ubuntu- ubuntu AMIs
ec2-user- Amazon Linux AMI
centos- Centos AMI
debian or root- Debian AMIs6
ec2-user or fedora- Fedora

10

Op basis van meerdere instanties, als het sleutelbestand en gebruikersnaam correct zijn, lijkt dit optreden bij het wijzigen van bepaalde machtigingen die verband houden met de root-gebruiker.

11

Een soortgelijk probleem is vandaag met mij gebeurd. Ik had hier ook veel over gezocht. Geen hulp. Ik heb net twee veranderingen gemaakt en het wordt ook goed gewerkt.

1. Ik had Amazon-documentatie waar beschrijft, waar Er is een regel die het verkeer van uw computer naar poort 22 (SSH) mogelijk maakt en indien niet aanwezig, maakt, maakt u het en bewerken “Security Group” en voegt u “SSH” toe aan mijn IP. Dit zal helpen.
2. In mijn geval, in Putty-profiel, moet ik opnieuw autoriseren met .ppk-bestand. Ik weet niet waarom het opnieuw vraagt, zonder enige wijzigingen aangebracht.

Ik hoop dat het u zal helpen.

12

Ik had hetzelfde probleem, ik gebruikte openbare DNS in plaats van openbare IP . Het is nu opgelost.

13

Voor mij moest ik het filezilla gewoon vertellen waar de privétoetsen waren:

1. Selecteer Bewerken & GT; Instellingen in het hoofdmenu
2. Ga in het dialoogvenster Instellingen naar verbinding en GT; Sftp
3. Klik op het knop “Sleutelbestand toevoegen …”
4. Navigeer naar en selecteer vervolgens het gewenste PEM-bestand (en)

14

Ik gebruik OPSWORKS en wilde een nieuwe bestaande Linux-instantie registreren van mijn Windows-machine op AWS CLI.

Vorstprobleem was dat ik mijn putty gegenereerde .pkk-bestand moest gebruiken.

Tweede probleem was dat ik citaat het absolute pad naar dat .PKK-bestand zoals dat is:

AWS OPSWORKS REGISTER – Infrastructuur-Klasse EC2 –SSH-gebruikersnaam
EC2-User –SSH-PRIVÉ-KEY “C: \ Key.PPK”

15

Dit: “Ontkoppeld: geen ondersteunde authenticatiemethoden beschikbaar (server verzonden: PrediKey)” is me overkomen nadat ik Microsoft One Drive Backup had ingeschakeld en synchroniseer voor mijn bestanden, waaronder de map waar ik mijn SSH-sleutel heb opgeslagen. In mijn geval is de oplossing eenvoudig: ga gewoon naar Putty = & GT; Ssh = & gt; Auth en (her) bladeren opnieuw naar waar mijnzelfde sleutel zich bevindt en opgeslagen, dan werkte het. Het lijkt een back-up- en synchronisatiesoftware, zoals Microsoft One Drive (en kan hetzelfde zijn met Google Drive), beïnvloeden de manier waarop Putty de mappen ziet en identificeert als de sleuteldirectory is opgegeven en dan later wat tijdig installeren of inschakelen of inschakelen Directory.

16

In mijn geval was het probleem met hostnaam / openbaar DNS.I-geassocieerd Elastice IP met mijn exemplaar en vervolgens werd mijn DNS gewijzigd. Ik probeerde verbinding te maken met oude DNS. Het veranderen in nieuw opgelost het probleem. U kunt het detail controleren door naar uw instantie te gaan en vervolgens op Details te klikken.

17

Dit gebeurde mij, want na LoadPEM-bestand naar PuttyGen Ik heb ingedrukt geefd generate-knop en druk vervolgens op save the private key. Het is niet nodig om te drukken op generate-knop. Gewoon Loaden druk op Save Private Key

Antwoord 18

Tijdens ssh-sessie is mijn verbinding verbroken, sindsdien kan ik mijn SRV niet sshen, ik was een nieuwe instantie gestart en kan de nieuwe instantie sshen (met dezelfde sleutel).

Ik heb het oude volume aan de nieuwe machine gekoppeld en de .ssh/authorized_key gecontroleerd en kon geen enkel probleem vinden met toestemming of inhoud.