Ik heb een sleutelpaar gemaakt met behulp van puttygen.exe(client is Windows 8). Op de server (Ubuntu 12.04.3 LTS) heb ik mijn openbare sleutel in ~/.ssh/authorized_keysgezet. De publieke sleutel is deze:
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAopfM6RHOgnuc4Aftn3t4k5UIAT3StCAbn/vg/IMbphbXadshC+79sIlRq3P4zGzMjFTP4hKnzu6ehLV5lmj/qorq3SKT+bPO5Qrac3VbIlrGvuBFDDjP82I2Hwg3HzlsFTstqk++KToapaTYZ7jENEYyPl2wnzITJnt//+4U1o6juoXTKgdNE02hHnRZyHOV/bnkZyJJCEwJv5U0eXSThQnhmXtUxGT8U0HQNFiXfqIIVllhWiCnyrhhIaKz/CIJNAd2VmzyJzQtJtTQX8aWSNVrZju6Sv2/RncTNvsACdNgjjh/FH8PQXaep00jlJ3MOdsC8vz6VSPFbh6iKy1oLQ== rsa-key-20131231
Dus het is correct (één regel, geen opmerkingen, begint met ssh-rsa, enz.)
Het
.sshdir-machtigingsniveau is 700, de bestandsmachtiging van Authorized_keys is 600. Zowel de directory als het bestand zijn eigendom van de daadwerkelijke gebruiker die ik probeer in te loggen.
Als ik verbinding probeer te maken, krijg ik 'server refused our key'en de server vraagt om een wachtwoord. Dat is alles. Er wordt niets vastgelegd in /var/log/auth.logwanneer u probeert in te loggen met de sleutel.
Ik heb overal gekeken en alle artikelen en tips vermelden het instellen van chmod 600 en 700 voor het bestand/de map en het correct formatteren van de sleutel. Ik heb dit allemaal gedaan en krijg nog steeds de foutmelding ‘onze sleutel geweigerd’ en ik heb geen ideeën meer.
Antwoord 1, autoriteit 100%
Ok, er zat een kleine typfout in mijn sleutel. Blijkbaar werd bij het plakken naar het bestand de eerste letter afgebroken en begon het met sh-rsa in plaats van ssh-rsa.
nrathathaus – je antwoord was erg nuttig, heel erg bedankt, dit antwoord is aan jou gecrediteerd 🙂 Ik deed wat je zei en zette dit in sshd_conf:
LogLevel DEBUG3
Door naar de logs te kijken realiseerde ik me dat sshd de sleutel correct leest, maar weigert vanwege de onjuiste identifier.
2, Autoriteit 51%
Een paar gedachten toevoegen aangezien andere antwoorden hebben geholpen, maar niet exact fit waren.
Allereerst, zoals vermeld in geaccepteerd antwoord, bewerken
/etc/ssh/sshd_config
en stel logniveau in:
LogLevel DEBUG3
Probeer vervolgens te verifiëren, en wanneer het mislukt, zoekt u naar logbestand:
/var/log/secure
Het heeft fouten waarnaar u op zoek bent.
3, Autoriteit 30%
In mijn geval moest ik ook de machtigingen van / home / gebruiker van 0755 tot 0700 wijzigen.
4, Autoriteit 7%
Hetzelfde probleem hebben in Windows Server 2008 R2 en verkent veel om op te lossen, eindelijk deed dat door:
Open C: \ programmabestanden (x86) \ openssh \ etc \ sshd_config met tekstpad of een andere teksteditor
Verwijder de opmerking van de volgende regels, na het verwijderen ervan moeten ze eruitzien als volgt:
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
Sla het op en probeer nu in te loggen met de privésleutel.
veel plezier.
5, Autoriteit 5%
Ik voeg dit antwoord toe om iemand te helpen, zoals ik, die uren besteedt aan het internet zonder succes.
Uw woningmap kan worden gecodeerd.
Of voor die materie is elke map waarin uw bestand “geautoriseerd_keys” is genest. Man, dat zou me veel tijd hebben bespaard. Om te controleren, voert u uit
ls -A
in de directory waarvan u de versleutelingsstatus wilt bepalen. Als de map een map met de naam “.encryptfs” bevat, is het antwoord ja, die map is versleuteld. Dit belemmert uw toegang tot het bestand “authorized_keys” dat de openbare ssh-sleutel bevat die nodig is voor verificatie.
Om dit op te lossen, plaatst u het bestand “authorized_key” in een directorystructuur die geen codering bevat.
Antwoord 6, autoriteit 5%
De eenvoudige oplossing die ik vond was om het bestand authorized_keysweg te halen uit de verborgen .ssh-directory en het in de systeem-ssh-directory te plaatsen:
/etc/ssh/keys/authorized_keys
Zodra ik dit deed, werkte het zonder problemen.
Antwoord 7, autoriteit 3%
Dankzij nrathaus en /var/log/auth.logonderzoek op debug-niveau komt het volgende.
Een andere reden is dat uw homedirectory mogelijk andere rechten heeft dan 755.
Antwoord 8, autoriteit 3%
Ik heb dit probleem opgelost, puttygen is software van derden, de ssh-sleutel die hierdoor werd gegenereerd, werd niet rechtstreeks gebruikt, dus u moet enkele wijzigingen aanbrengen.
Het ziet er bijvoorbeeld zo uit
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20170502"
AAAAB3NzaC1yc2EAAAABJQAAAQEAr4Ffd3LD1pa7KVSBDU+lq0M7vNvLp6TewkP7
*******C4eq1cdJACBPyjqUCoz00r+LqkGA6sIFGooeVuUXTOxbYULuNQ==
---- END SSH2 PUBLIC KEY ----
Ik laat enkele van de alfabetten in het midden weg, vervangen door *, zo niet, StackOverflow vertelde me dat de code-indeling verkeerd is, laat me niet posten。
dit is mijn ssh-sleutel gegenereerd door puttygen, je moet dit veranderen
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAr4Ffd3LD1pa7KVSBDU+lq0M7vNvLp6TewkP7wfvKGWWR7wxA8GEXJsM01FQw5hYWbNF0CDI7nCMXDUEDOzO1xKtNoaidlLA0qGl67bHaF5t+0mE+dZBGqK7jG9L8/KU/b66/tuZnqFqBjLkT+lS8MDo1okJOScuLSilk9oT5ZiqxsD24sdEcUE62S8Qwu7roVEAWU3hHNpnMK+1szlPBCVpbjcQTdiv1MjsOHJXY2PWx6DAIBii+/N+IdGzoFdhq+Yo/RGWdr1Zw/LSwqKDq1SmrpToW9uWVdAxeC4eq1cdJACBPyjqUCoz00r+LqkGA6sIFGooeVuUXTOxbYULuNQ== yourname@hostname
In mijn geval heb ik enkele opmerkingen verwijderd, zoals
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20170502"
---- END SSH2 PUBLIC KEY ----
en voeg aan het begin ssh-rsatoe,
voeg als laatste yourname@hostnametoe.
opmerking: niet delete==in de laatste en je moet “yourname” en “hostname” voor je veranderen. In mijn geval is dit uaskh@mycomputer,je naam is dat je wilt inloggen op je vps .wanneer al deze dingen gedaan zijn, zou je de publieke sleutel kunnen uploaden naar de home van uaskh~/.ssh/authorized_keysdoor cat public-key >> ~/.ssh/authorized_keysdan sudo chmod 700 ~/.sshsudo chmod 600 ~/.ssh/authorized_keysdan moet je /etc/ssh wijzigen /sshd_config, RSAAuthentication yesPubkeyAuthentication yesAuthorizedKeysFile .ssh/authorized_keysmijn besturingssysteem is CentOS 7, dit is de eerste keer dat ik een vraag beantwoord, ik zal proberen mijn inspanningen te doen, bedankt!
Antwoord 9, autoriteit 3%
Ik kwam dit probleem vandaag tegen en mijn probleem was dat bij het kopiëren van de openbare sleutel uit het bestand ook nieuwe regeltekens worden opgenomen. U kunt “:set list” in vim gebruiken om alle verborgen nieuwe regels te zien en zorg ervoor dat u alle nieuwe regels verwijdert, behalve de laatste. Ook ontbrak mijn sleutel in het begin “ssh-rsa”. Zorg ervoor dat je dat ook hebt.
Antwoord 10, autoriteit 2%
Voor degenen die deze fout van Windows Server ontvingen, ik ontving dezelfde fout en het was een probleem met een gebruikersaccount. Bij veel organisaties staat het groepsbeleid voor beheerders het instellen van SSH-server en verbindingen mogelijk niet toe. Met dat type installatie moet dit worden gedaan vanuit een lokaal beheerdersaccount. Misschien de moeite waard om te onderzoeken als je hebt bevestigd dat er geen typefouten in de openbare sleutel zitten.
Antwoord 11, autoriteit 2%
In mijn geval moest ik SELinux op Centos6.6 uitschakelen om het werkend te krijgen 🙂
Bewerk /etc/selinux/config en stel het volgende in en herstart dan de host.
selinux=disabled
BTW…vergat te vermelden dat ik LogLevel=DEBUG3 moest instellen om het probleem te identificeren.
Antwoord 12, autoriteit 2%
Ik had dezelfde fout op solaris, maar vond in /var/adm/splunk-auth.log het volgende:
sshd: [auth.debug] debug1: PAM conv function returns PAM_SUCCESS
sshd: [auth.notice] Excessive (3) login failures for weblogic: locking account.
sshd: [auth.debug] ldap pam_sm_authenticate(sshd-kbdint weblogic), flags = 1
sshd: [auth.info] Keyboard-interactive (PAM) userauth failed[9] while authenticating: Authentication failed
In /etc/shadow was het account vergrendeld:
weblogic:*LK*UP:16447::::::3
Het “*LK*” gedeelte verwijderd:
weblogic:UP:16447::::::3
en ik zou zoals gewoonlijk ssh kunnen gebruiken met geautoriseerde_sleutels.
Antwoord 13, autoriteit 2%
In mijn geval werd het veroorzaakt door (/etc/ssh/sshd_config):
PermitRootLogin no
Gewijzigd in yes, de service opnieuw gestart en normaal binnengekomen.
Antwoord 14, autoriteit 2%
Na het toevoegen van de sleutel, log in als ec2-userals je een Amazon Linux-machine gebruikt
Antwoord 15, autoriteit 2%
Oh mijn god, ik heb dagenlang geprobeerd dit op te lossen. Dus hier is wat voor mij werkte. Ik ging als volgt terug naar de rootfold:
cd /root/
mkdir .ssh
cd .ssh
chmod 700 .ssh
nano -w geautoriseerde_sleutels
service ssh opnieuw opstarten
Dus ik gebruikte root om te loggen via Putty en het werkte. dus probeer hetzelfde te doen met de gebruiker die je in putty wilt gebruiken.
Antwoord 16, autoriteit 2%
In het geval van mij was het een verkeerde user:group attributie. Ik heb de juiste gebruiker en groep ingesteld:
sudo chown [user]:[group] -R /home/[user]
Antwoord 17, autoriteit 2%
Het equivalent van een SSH-commando:
ssh -i <path_to_pem_file> [email protected]
Gebruik in Windows eerst PuTTYGen om het pem-bestand naar een ppk-bestand te converteren.
- Open PuTTYGen
- Bestand/laad de privé pem-sleutel (of een OpenSSH-sleutel)
- Gebruik in de Open FileDialog de vervolgkeuzelijst om “Alle bestanden” te selecteren (het toont alleen ppk-bestandsindelingen niet pem, ook OpenSSH-sleutelbestanden die kunnen worden geconverteerd zoals pem-bestanden hebben geen bestandsextensie)
- Bestand/Opslaan privésleutel (*.ppk)
Dezelfde instellingen in Putty als het SSH-commando:
- Open Putty
- Sessie/Hostnaam: calendar.com
- Verbinding/Gegevens/Auto-login gebruikersnaam: ec2-gebruiker
- Connection/SSH/Auth/PrivateKeyFile Path: het bestandspad naar het PPK-bestand
Antwoord 18
Ik gebruik een PUTTYgen-bestand met psftp en ik kwam dit probleem tegen op mijn Windows Server toen we nieuwe sleutels voor een client moesten maken. Het bestand private_key_name.ppk en het bestand open_ssh.txt moeten zich in dezelfde map bevinden om de verbinding te laten werken.
Antwoord 19
In mijn geval was thuis op nfs 777, dat moest 750 zijn. Dat loste het probleem op.
Antwoord 20
Ik heb dit probleem waarbij sshd alleen leest van authorized_keys2.
Het kopiëren of hernoemen van het bestand loste het probleem voor mij op.
cd ~/.ssh
sudo cat authorized_keys >> authorized_keys2
P.S. Ik gebruik Putty van Windows en gebruikte PuTTyKeygen voor het genereren van sleutelparen.
Antwoord 21
Ik had een soortgelijk probleem toen ik me probeerde aan te melden via Mobaxterm. De privésleutel is gegenereerd door puttygen. Het regenereren van de sleutel hielp in mijn geval.
Antwoord 22
Als u Cpanel gebruikt, kunt u controleren of de sleutel is geautoriseerd in
SSH-toegang >> Openbare sleutels >> Beheer >> Autoriseren of autoriseren.
Antwoord 23
als je deze foutmelding krijgt in /var/log/secure
fout: key_read: key_from_blob AA
AAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG+rKz93l7em1BsUBzjHPMsswD
het betekent dat uw sleutel ruimte heeft, als u de sleutel via puttgen heeft gegenereerd wanneer u het bestand .ppkbekijkt, ziet het er als volgt uit:
AAAAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG+rKz93l7em1BsUBzjHPMsswD
al74MLaJyhQD0pE23NS1izahbo1sJGnSJu2VJ//zxidSsba6xa6OvmeiKTwCz0E5
GMefdGVdpdbTlv99qjBl1+Nw1tDnHIC0+v9XmeZERQfCds9Kp1UivfReoYImntBC
gLtNyqRYrSu8csJCt7E1oY8QK6WP1vfYgAQ2taGyS9+g7FHyyf5VY2vH3oWzzbqz
xjsSLAv3zEQSm1LzSw9Pvc8iwasFyUMBOPj31CKQYTXyX8KpJTr0Zb7oqMauBE5L
VwxZhlcJHbj0FsMbF/+GRjvgexymCi3bHmwGQ6FEADNd0RkhdQ==
en als je het probeert te plakken, krijg je een foutmelding bij het lezen van de sleutel, dus probeer de sleutel te bewerken en er één regel van te maken en probeer het
dit zou ergens op moeten lijken
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG+rKz93l7em1BsUBzjHPMsswDal74MLaJyhQD0pE23NS1izahbo1sJGnSJu2VJ//zxidSsba6xa6OvmeiKTwCz0E5GMefdGVdpdbTlv99qjBl1+Nw1tDnHIC0+v9XmeZERQfCds9Kp1UivfReoYImntBCgLtNyqRYrSu8csJCt7E1oY8QK6WP1vfYgAQ2taGyS9+g7FHyyf5VY2vH3oWzzbqzxjsSLAv3zEQSm1LzSw9Pvc8iwasFyUMBOPj31CKQYTXyX8KpJTr0Zb7oqMauBE5LVwxZhlcJHbj0FsMbF/+GRjvgexymCi3bHmwGQ6FEADNd0RkhdQ== username@domainname
Antwoord 24
Wat voor mij werkt, is dat:
- De ec2-instantie gestopt
- het volume loskoppelen
- verbind het volume met de oude instantie met dezelfde sleutel en kon SSH gebruiken
- koppel het volume in een tijdelijke map
- het bestand in de directory mount_point/home/ec2-user/.ssh/authorized_keys gecontroleerd
- Idealiter moet dit bestand onze belangrijkste informatie bevatten, maar voor mij was dit bestand leeg
- heeft het oude instance Authorized_keys-bestand gekopieerd naar het nieuw aangekoppelde volume
- het apparaat ontkoppelen
- opnieuw koppelen aan de originele ec2-instantie
- start het en laat het de gezondheidscontroles doorstaan
Deze keer werkt het voor mij. Maar ik weet niet waarom het in eerste instantie mijn belangrijkste bestandsinformatie niet heeft toen de instantie werd gelanceerd. Bekijk ook deze link https://docs.aws.amazon. com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html#TroubleshootingInstancesConnectingMindTerm
Antwoord 25
Aan mijn geval was het probleem zo, tijdens het genereren van SSH-toetsen, heb ik opzettelijk de standaardmappen van de sleutels gewijzigd. Dus in plaats van de locatie te gebruiken ~ / .SSH / Authorized_Keys, koos ik ervoor om ~/home/user/folder1/.ssh/authorized_keyste gebruiken, want deze wijzigingen aan het werk moest ik dezelfde wijzigingen aanbrengen Over de nieuwe locatie op dit bestand /etc/ssh/sshd_config. Maar totdat ik dit besef, had ik al verschillende oplossingen geprobeerd die door andere mensen hier zijn gesuggereerd, inclusief het instellen van de toestemming van de thuismap naar 700en de .SSH-map naar 600.
26
Stappen om de root-mount op te lossen (die ik heb gevolgd toen ik toestemming heeft gewijzigd met de map EC2-User en het autorisatie-sleutelbestand)
Dit proces zal vergelijkbaar zijn met losse en bevestig een pen-drive
Hieronder staan enkele andere scenario’s die u kunt tegenkomen –
- U gebruikt een SSH-particuliere sleutel, maar de bijbehorende publieke toets bevindt zich niet in het geautoriseerde_keys-bestand.
- U hebt geen machtigingen voor uw geautoriseerde_keys-bestand.
- U hebt geen machtigingen voor de .SSH-map.
- Your Authorized_Keys-bestand of .SSH-map is niet correct genoemd.
- Uw geautoriseerde_keys-bestand of .SSH-map is verwijderd.
Stappen om ze te repareren
- Stop de problematische EC2-instantie
- Maak het rootvolume (/ dev / sda1)
- Maak een EC2-instantie of gebruik een draaiende
- Monteer het vrijstaande volume (/ dev / sdvf) naar nieuwe EC2-instantie
los
Nu nadat u bent ingelogd bij nieuwe EC2-run onder de stappen
- LSBLK-opdracht – lijst Alle beschikbare mounts
- Kies de houderwaarde die u niet van het problematische exemplaar maakt
- als EC2-User Run “Sudo Mount / Dev / Mapper / ROOTVG-Home / MNT”
sudo mount /dev/mapper/rootvg-home /mnt - Wijzig vervolgens de map naar / MNT
- Maak alle benodigde wijzigingen
Nu hebben we ons volume opgelost met het probleem waarmee we geconfronteerd zijn. Meestal kan het een probleem van de gebruikersrechten zijn
– Umount / MNT om het niet aan te sluiten
– Ga nu naar de console en wijs naar het volume dat is aangesloten op het nieuwe exemplaar en losmaken
– Na vrijstaande, bevestigde deze aan uw nieuwe volume AS / Dev / SDA1
Met dat zei dat u met succes moet inloggen
27
Als mijn ervaring, stel ik aan dat je sleutels van Putty zou moeten genereren, zou niet moeten genereren uit Linux-kant. Omdat de sleutel een oud PEM-formaat is. Hoe dan ook, gewoon mijn suggestie. Ik deed als stappen onder en werkte prima met mij en met mijn team.
-
Genereer een sleutelpaar met puttygen.exe op uw lokale (type: RSA, lengte: 2048 bits).
-
Privé / openbare sleutel opslaan als “id_rsa.ppk / id_rsa.pub ” bestanden op uw plaatselijke.
-
-bestand maken “Authorized_keys” -bestand op uw lokale en voer vervolgens de openbare sleutel in “ID_RSA.PUB ” naar “Authorized_Keys “.
Onthoud dat de inhoud moet beginnen met “ssh-rsa ” en one-regel .
- Gebruik WinSCP (of Putty Command) om te kopiëren “geautoriseerd_keys & amp; id_rsa.pub ” van uw lokale naar uw Linux-User-Home “/home/$user/sh/ “.
-
Voer deze opdrachten uit:
CHMOD 700 .SSH
chmod 600 .ssh/authorized_keys
chown $USER:$USER .ssh -R
-
Test uw verbindingsinstelling door de privésleutel “id_rsa.ppk” in het PuTTY.exe-profiel te laden en vervolgens op openen te klikken (indien aanwezig uw wachtwoordzin).
Antwoord 28
controleer uw sleutel, dit zou vandaag een rsa (id_rsa.pub) sleutel moeten zijn en niet langer een dss (id_dsa.pub) sleutel, gebruik puttygen 0.70 en kies RSA op het type sleutel dat u wilt genereren, vervang de openbare sleutel op de host ~/.ssh/authorized_keys