Putty: Der Server hat unseren Schlüsselfehler abgelehnt

Ich habe ein Schlüsselpaar mit erstellt puttygen.exe(Client ist Windows 8). Auf dem Server (Ubuntu 12.04.3 LTS) habe ich meinen öffentlichen Schlüssel eingegeben ~/.ssh/authorized_keys. Der öffentliche Schlüssel lautet:

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAopfM6RHOgnuc4Aftn3t4k5UIAT3StCAbn/vg/IMbphbXadshC+79sIlRq3P4zGzMjFTP4hKnzu6ehLV5lmj/qorq3SKT+bPO5Qrac3VbIlrGvuBFDDjP82I2Hwg3HzlsFTstqk++KToapaTYZ7jENEYyPl2wnzITJnt//+4U1o6juoXTKgdNE02hHnRZyHOV/bnkZyJJCEwJv5U0eXSThQnhmXtUxGT8U0HQNFiXfqIIVllhWiCnyrhhIaKz/CIJNAd2VmzyJzQtJtTQX8aWSNVrZju6Sv2/RncTNvsACdNgjjh/FH8PQXaep00jlJ3MOdsC8vz6VSPFbh6iKy1oLQ== rsa-key-20131231

Es ist also richtig (eine Zeile, keine Kommentare, beginnt mit ssh-rsa usw.)

.ssh Die Berechtigungsstufe dir ist 700, die Berechtigung file_keys für autorisierte_keys ist 600. Sowohl das Verzeichnis als auch die Datei des tatsächlichen Benutzers, bei dem ich mich anmelden möchte.

Wenn ich versuche, eine Verbindung herzustellen, erhalte ich 'server refused our key'und der Server fragt nach dem Passwort. Das ist alles. /var/log/auth.logBeim Versuch, sich mit dem Schlüssel anzumelden, wird nichts angemeldet .

Ich habe überall gesucht und in allen Artikeln und Tipps wird erwähnt, dass chmod 600 und 700 für die Datei / das Verzeichnis eingestellt und der Schlüssel richtig formatiert wurden. Ich habe das alles getan und immer noch den Fehler "unseren Schlüssel abgelehnt" bekommen.

OK, in meinem Schlüssel war ein kleiner Tippfehler. Anscheinend wurde beim Einfügen in die Datei der erste Buchstabe abgeschnitten und es begann mit sh-rsa anstelle von ssh-rsa.

nrathathaus - Ihre Antwort war sehr hilfreich, vielen Dank, diese Antwort wird Ihnen gutgeschrieben :) Ich habe wie Sie gesagt und dies in sshd_conf gesetzt:

LogLevel DEBUG3

Beim Betrachten der Protokolle wurde mir klar, dass sshd den Schlüssel korrekt liest, ihn jedoch aufgrund der falschen Kennung ablehnt.

Das Hinzufügen einiger Gedanken als andere Antworten half, war aber nicht genau passend.

Bearbeiten Sie zunächst, wie in der akzeptierten Antwort erwähnt,

/etc/ssh/sshd_config

und Protokollstufe einstellen:

LogLevel DEBUG3

Versuchen Sie dann, sich zu authentifizieren, und suchen Sie nach einer Protokolldatei, wenn dies fehlschlägt:

/var/log/secure

Es wird Fehler geben, nach denen Sie suchen.

In meinem Fall musste ich auch die Berechtigungen von / home / user von 0755 auf 0700 ändern.

In meinem Fall liegt ein Berechtigungsproblem vor.

Ich habe die Protokollebene in geändert DEBUG3und in /var/log/securedieser Zeile wird Folgendes angezeigt:

Authentication refused: bad ownership or modes for directory

Googelte und ich fand diesen Beitrag:

https://www.daveperrett.com/articles/2010/09/14/ssh-authentication-refused/

chmod g-w /home/your_user
chmod 700 /home/your_user/.ssh
chmod 600 /home/your_user/.ssh/authorized_keys

Grundsätzlich sagt es mir:

• Entfernen Sie die Gruppenberechtigung wIhres Home-Verzeichnisses
• Ändere die Erlaubnis in 700das .sshVerzeichnis
• Ändern Sie die Berechtigung 600für die authorized_keysDatei.

Und das funktioniert.

Eine andere Sache ist, dass ich selbst dann, wenn ich die Root-Anmeldung aktiviert habe, nicht rootzur Arbeit kommen kann. Verwenden Sie besser einen anderen Benutzer.

Unter Windows 8.1 stieß ich auf das server refused our keyProblem.

Befolgen Sie die Anleitung: https://winscp.net/eng/docs/guide_windows_openssh_server Es war einfach, eine Verbindung mit dem Windows-Login usernameund herzustellen password. Bei der Authentifizierung mit usernamein Kombination mit a private keywar die Antwort jedoch server refused our key.

Um es mit einem öffentlichen Schlüssel zum Laufen zu bringen, kam es auf die Berechtigungen für die Datei an: C:\ProgramData\ssh\administrators_authorized_keys

Dies ist eine hilfreiche Seite: https://github.com/PowerShell/Win32-OpenSSH/wiki/Troubleshooter-Steps

Stoppen Sie die beiden OpenSSH-Dienste und öffnen Sie einen command promptmit admin permissions. Dann renne: C:\OpenSSH-Win32>c:\OpenSSH-Win32\sshd.exe -ddd

Hinweis: Geben Sie den vollständigen Pfad zur Exe an, andernfalls sshdbeschweren Sie sich. Dadurch wird ein Verbindungslistener für die einmalige Verwendung erstellt. Das-ddd ist ausführliche Stufe 3.

Nach dem Herstellen einer Verbindung ergab das Scannen der Protokolle Folgendes:

debug1: trying public key file __PROGRAMDATA__/ssh/administrators_authorized_keys
debug3: Failed to open file:C:/ProgramData/ssh/administrators_authorized_keys error:2
debug1: Could not open authorized keys '__PROGRAMDATA__/ssh/administrators_authorized_keys':
        No such file or directory

Musste die Datei erstellen: C:\ProgramData\ssh\administrators_authorized_keys Und kopiere den public keyText hinein, zB: ssh-rsa AAAA................MmpfXUCj rsa-key-20190505 Und dann speichere die Datei. Ich habe die Datei wie UTF-8beim gespeichert BOM. Nicht getestet ANSI.

Führen Sie dann die einmalige Befehlszeile erneut aus. In den Protokollen wird Folgendes angezeigt:

debug1: trying public key file __PROGRAMDATA__/ssh/administrators_authorized_keys
debug3: Bad permissions. Try removing permissions for user: S-1-5-11 on file C:/ProgramData/ssh/administrators_authorized_keys.
        Authentication refused.

S-1-5-11ist der Name, der dem gegeben wird System.

Um das zu beheben Bad permissions, klicken Sie mit der rechten Maustaste auf die administrators_authorized_keysDatei, gehen Sie zu Security Tab, klicken Sie auf die AdvancedSchaltfläche und entfernen Sie geerbte Berechtigungen. Löschen Sie dann alle Group or user names:außer dem Windows-Login-Benutzernamen, z. B.: YourMachineName\username Die Berechtigungen dafür usernamesollten lauten Read Allow, Write Denyalles andere ist deaktiviert. Der Besitzer der Datei sollte auch seinYourMachineName\username

Dies hat das Problem behoben.

Andere nützliche Links:

Laden Sie OpenSSH-Win32.zip von folgender Adresse herunter: https://github.com/PowerShell/Win32-OpenSSH/releases

C # -Beispiel für die Verwendung der WinSCPnet.dll zum Herstellen einer Verbindung zum OpenSSH-Server: https://winscp.net/eng/docs/library#csharp

Hier ist das Code-Snippet zum Herstellen einer Verbindung mit WinSCPnet.dll:

static void WinSCPTest() {
    SessionOptions ops = new SessionOptions {
        Protocol = Protocol.Sftp, 
        PortNumber = 22,
        HostName = "192.168.1.188", 
        UserName = "user123",
        //Password = "Password1",
        SshHostKeyFingerprint = @"ssh-rsa 2048 qu0f........................ddowUUXA="
    };

    ops.SshPrivateKeyPath = @"C:\temp\rsa-key-20190505.ppk";

    using (Session session = new Session()) {
        session.Open(ops);
        MessageBox.Show("success");
    }
}

Ersetzen Sie SshHostKeyFingerprintund SshPrivateKeyPathdurch Ihre eigenen Werte.

Bearbeiten: Screenshot der Dateiberechtigungen administrators_authorized_keys hinzugefügt:

Wenn OpenSSH SSH Serveres als Dienst ausgeführt wird, Systemsollte nur die Berechtigung vorhanden sein. Wenn Sie jedoch sshd.exean der Eingabeaufforderung ausgeführt werden, sollte nur der aktuelle Benutzer aufgeführt sein (Leseerlaubnis, Schreibverweigerung).

Ich füge diese Antwort hinzu, um allen wie mir zu helfen, die stundenlang erfolglos im Internet gesucht haben.

IHR ZUHAUSE ORDNER KANN VERSCHRIFTET WERDEN.

Oder für jeden Ordner, in dem Ihre Datei "authorized_keys" verschachtelt ist. Mann, das hätte mir viel Zeit gespart. Um dies zu überprüfen, führen Sie durch

ls -A

in dem Verzeichnis, dessen Verschlüsselungsstatus Sie bestimmen möchten. Wenn der Ordner einen Ordner mit dem Namen ".encryptfs" enthält, lautet die Antwort: Ja, dieser Ordner ist verschlüsselt. Dies beeinträchtigt Ihren Zugriff auf die Datei "authorized_keys", die den zur Überprüfung erforderlichen öffentlichen SSH-Schlüssel enthält.

Um dies zu beheben, platzieren Sie die Datei "authorized_key" in einem Verzeichnisbaum, der keine Verschlüsselung enthält.

Die einfache Lösung, die ich gefunden habe, bestand darin, die authorized_keysDatei aus dem versteckten SSH-Verzeichnis zu verschieben und in das System-SSH-Verzeichnis zu legen:

/etc/ssh/keys/authorized_keys

Sobald ich das tat, funktionierte es ohne Probleme.

Nachdem ich das gleiche Problem in Windows Server 2008 R2 hatte und viel zu lösen hatte, tat ich dies schließlich wie folgt:

Öffnen Sie C: \ Programme (x86) \ OpenSSH \ etc \ sshd_config mit einem Textpad oder einem anderen Texteditor

Entfernen Sie den Kommentar aus den folgenden Zeilen. Nach dem Entfernen sollten sie wie folgt aussehen:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

Speichern Sie es und versuchen Sie, sich jetzt mit einem privaten Schlüssel anzumelden. habe Spaß.

Dank nrathaus und der /var/log/auth.logUntersuchung auf Debug-Ebene kommt Folgendes.

Ein weiterer Grund ist, dass Ihr Home-Verzeichnis möglicherweise andere Berechtigungen als 755 hat.

Ich bin heute auf dieses Problem gestoßen, und mein Problem war, dass beim Kopieren des öffentlichen Schlüssels aus einer Datei auch neue Zeilenzeichen enthalten sind. Sie können ": set list" in vim verwenden, um alle versteckten neuen Zeilen anzuzeigen und sicherzustellen, dass alle neuen Zeilen mit Ausnahme der letzten gelöscht werden. Außerdem fehlte meinem Schlüssel am Anfang "ssh-rsa". Stellen Sie sicher, dass Sie das auch haben.

Für diejenigen, die diesen Fehler von Windows Server erhalten haben, habe ich denselben Fehler erhalten, und es handelte sich um ein Problem mit dem Benutzerkonto. In vielen Organisationen können Gruppenrichtlinien für Administratoren das Einrichten von SSH-Servern und -Verbindungen möglicherweise nicht zulassen. Bei dieser Art der Einrichtung muss dies über das lokale Administratorkonto erfolgen. Es könnte sich lohnen, einen Blick darauf zu werfen, wenn Sie bestätigt haben, dass der öffentliche Schlüssel keine Tippfehler enthält.

In meinem Fall musste ich SELinux unter Centos6.6 deaktivieren, damit es funktioniert :)

Bearbeiten Sie / etc / selinux / config, stellen Sie Folgendes ein und starten Sie den Host neu.

selinux=disabled

Übrigens ... habe vergessen zu erwähnen, dass ich LogLevel = DEBUG3 setzen musste, um das Problem zu identifizieren.

Ich hatte den gleichen Fehler unter Solaris, fand aber in /var/adm/splunk-auth.log Folgendes:

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 wurde das Konto gesperrt:

weblogic:*LK*UP:16447::::::3

Der Teil "* LK *" wurde entfernt:

weblogic:UP:16447::::::3

und ich könnte ssh wie gewohnt mit autorisierten_schlüsseln verwenden.

In meinem Fall wurde es verursacht durch ( /etc/ssh/sshd_config):

PermitRootLogin no

Geändert zu yes, den Dienst neu gestartet und normal eingestiegen.

Ich habe dieses Problem gelöst. Puttygen ist eine Software von Drittanbietern. Der von ihm generierte SSH-Schlüssel wurde nicht direkt verwendet. Sie müssen daher einige Änderungen vornehmen. Zum Beispiel sieht es so aus

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20170502"
AAAAB3NzaC1yc2EAAAABJQAAAQEAr4Ffd3LD1pa7KVSBDU+lq0M7vNvLp6TewkP7
*******C4eq1cdJACBPyjqUCoz00r+LqkGA6sIFGooeVuUXTOxbYULuNQ==
---- END SSH2 PUBLIC KEY ---- 

Ich lasse einige der Alphabete in der Mitte weg, ersetzt durch *. Wenn nicht, sagte mir StackOverflow, dass das Codeformat falsch ist. Lassen Sie mich nicht post posten

Dies ist mein SSH-Schlüssel, der von Puttygen generiert wurde. Sie müssen dies ändern

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAr4Ffd3LD1pa7KVSBDU+lq0M7vNvLp6TewkP7wfvKGWWR7wxA8GEXJsM01FQw5hYWbNF0CDI7nCMXDUEDOzO1xKtNoaidlLA0qGl67bHaF5t+0mE+dZBGqK7jG9L8/KU/b66/tuZnqFqBjLkT+lS8MDo1okJOScuLSilk9oT5ZiqxsD24sdEcUE62S8Qwu7roVEAWU3hHNpnMK+1szlPBCVpbjcQTdiv1MjsOHJXY2PWx6DAIBii+/N+IdGzoFdhq+Yo/RGWdr1Zw/LSwqKDq1SmrpToW9uWVdAxeC4eq1cdJACBPyjqUCoz00r+LqkGA6sIFGooeVuUXTOxbYULuNQ== yourname@hostname

In meinem Fall habe ich einige Kommentare gelöscht, wie z

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20170502"
---- END SSH2 PUBLIC KEY ----

und ssh-rsaam Anfang hinzufügen, yourname@hostnameam letzten hinzufügen . Hinweis : Nicht ==im letzten löschen und Sie müssen "Ihr Name" und "Hostname" für Sie ändern. In meinem Fall ist uaskh@mycomputerIhr Name, dass Sie sich bei Ihrem VPS anmelden möchten. Wenn all diese Dinge getan haben, können Sie öffentlich hochladen -Taste nach Hause uaskh die ~/.ssh/authorized_keysdurch cat public-key >> ~/.ssh/authorized_keysdann sudo chmod 700 ~/.ssh sudo chmod 600 ~/.ssh/authorized_keysdann müssen Sie ändern / etc / ssh / sshd_config, RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keysmein Betriebssystem CentOS 7 ist, diese zu anwser Frage mein erstes Mal ist, werde ich meine Bemühungen zu tun versuchen, Thank you!

Oh mein Gott, ich habe Tage damit verbracht, dies zu beheben. Also hier ist, was für mich funktioniert hat. Ich ging wie folgt zum Root-Fold zurück: cd / root / mkdir .ssh cd .ssh chmod 700 .ssh nano -w autorisierter_schlüssel service ssh restart Also habe ich root für die Protokollierung über Putty verwendet und es hat funktioniert. Versuchen Sie also, dasselbe mit dem Benutzer zu tun, den Sie in Putty verwenden möchten.

Ich verwende eine PUTTYgen-Datei mit psftp und bin auf meinem Windows Server auf dieses Problem gestoßen, als wir neue Schlüssel für einen Client erstellen mussten. Die .ppk- Datei private_key_name und die Datei open_ssh.txt müssen sich im selben Verzeichnis befinden, damit die Verbindung funktioniert.

In meinem Fall war das Haus auf NFS 777, musste 750 sein. Das hat das Problem behoben.

Ich habe dieses Problem, von dem sshd nur liest authorized_keys2.

Das Kopieren oder Umbenennen der Datei hat das Problem für mich behoben.

cd  ~/.ssh
sudo cat authorized_keys >> authorized_keys2

PS Ich verwende Putty von Windows und verwende PuTTyKeygen für die Schlüsselpaargenerierung.

Beim Versuch, mich über Mobaxterm anzumelden, trat ein ähnliches Problem auf. Der private Schlüssel wurde durch Puttygen generiert. Das Regenerieren des Schlüssels hat in meinem Fall geholfen.

Bei Verwendung von Cpanel können Sie überprüfen, ob der Schlüssel in autorisiert ist

SSH-Zugriff >> Öffentliche Schlüssel >> Verwalten >> Autorisieren oder Deaktivieren.

wenn Sie diesen Fehler in bekommen /var/log/secure

Fehler: key_read: key_from_blob AA
AAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG + rKz93l7em1BsUBzjHPMsswD

Dies bedeutet, dass Ihr Schlüssel über Speicherplatz verfügt. Wenn Sie beim Anzeigen der .ppkDatei einen Schlüssel über puttgen generiert haben , sieht dieser folgendermaßen aus:

AAAAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG+rKz93l7em1BsUBzjHPMsswD
al74MLaJyhQD0pE23NS1izahbo1sJGnSJu2VJ//zxidSsba6xa6OvmeiKTwCz0E5
GMefdGVdpdbTlv99qjBl1+Nw1tDnHIC0+v9XmeZERQfCds9Kp1UivfReoYImntBC
gLtNyqRYrSu8csJCt7E1oY8QK6WP1vfYgAQ2taGyS9+g7FHyyf5VY2vH3oWzzbqz
xjsSLAv3zEQSm1LzSw9Pvc8iwasFyUMBOPj31CKQYTXyX8KpJTr0Zb7oqMauBE5L
VwxZhlcJHbj0FsMbF/+GRjvgexymCi3bHmwGQ6FEADNd0RkhdQ==

und wenn Sie versuchen, es einzufügen, wird beim Lesen des Schlüssels eine Fehlermeldung angezeigt. Versuchen Sie also, den Schlüssel zu bearbeiten, eine Zeile zu machen und es zu versuchen

das sollte wie etwas aussehen

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG+rKz93l7em1BsUBzjHPMsswDal74MLaJyhQD0pE23NS1izahbo1sJGnSJu2VJ//zxidSsba6xa6OvmeiKTwCz0E5GMefdGVdpdbTlv99qjBl1+Nw1tDnHIC0+v9XmeZERQfCds9Kp1UivfReoYImntBCgLtNyqRYrSu8csJCt7E1oY8QK6WP1vfYgAQ2taGyS9+g7FHyyf5VY2vH3oWzzbqzxjsSLAv3zEQSm1LzSw9Pvc8iwasFyUMBOPj31CKQYTXyX8KpJTr0Zb7oqMauBE5LVwxZhlcJHbj0FsMbF/+GRjvgexymCi3bHmwGQ6FEADNd0RkhdQ== username@domainname

Was für mich funktioniert ist das:

• Die ec2-Instanz wurde gestoppt
• Nehmen Sie die Lautstärke ab
• Hängen Sie das Volume mit demselben Schlüssel an die alte Instanz an und konnten Sie SSH
• Hängen Sie das Volume in einen temporären Ordner ein
• überprüfte die Datei im Verzeichnis mount_point / home / ec2-user / .ssh / authorized_keys
  • Idealerweise muss diese Datei unsere wichtigsten Informationen enthalten, aber für mich war diese Datei leer
• kopierte die alte Datei "instance_keys" der Instanz auf das neu bereitgestellte Volume
• Hängen Sie das Gerät aus
• Wiederverbindung mit der ursprünglichen ec2-Instanz
• Starten Sie es und lassen Sie es die Gesundheitsprüfungen bestehen

Diesmal funktioniert es bei mir. Ich weiß jedoch nicht, warum meine Schlüsseldatei beim Start der Instanz zunächst nicht vorhanden ist. Überprüfen Sie auch diesen Link https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html#TroubleshootingInstancesConnectingMindTerm

In meinem Fall war das Problem so: Während der Generierung von SSH-Schlüsseln habe ich absichtlich die Standardverzeichnisse der Schlüssel geändert. Anstatt den von mir gewählten Speicherort ~ / .ssh / autorisierte_Tasten zu verwenden ~/home/user/folder1/.ssh/authorized_keys, sollte ich , damit diese Änderungen funktionieren, dieselben Änderungen am neuen Speicherort in dieser Datei vornehmen /etc/ssh/sshd_config. Aber bis ich 700das merke , habe ich bereits mehrere Lösungen ausprobiert, die von anderen Leuten hier vorgeschlagen wurden, einschließlich des Festlegens der Berechtigung des Home-Ordners auf und des .ssh-Verzeichnisses auf 600.

Schritte zum Beheben des Root-Mount (dem ich gefolgt bin, als ich die Berechtigung mit dem ec2-Benutzerordner und der Autorisierungsschlüsseldatei geändert habe) Dieser Vorgang ähnelt dem Trennen und Anhängen eines USB-Sticks

Im Folgenden finden Sie einige andere Szenarien, denen Sie möglicherweise begegnen:

1. Sie verwenden einen privaten SSH-Schlüssel, aber der entsprechende öffentliche Schlüssel befindet sich nicht in der Datei authorized_keys.
2. Sie haben keine Berechtigungen für Ihre Datei "authorized_keys".
3. Sie haben keine Berechtigungen für den Ordner .ssh.
4. Ihre Datei "authorized_keys" oder der Ordner ".ssh" ist nicht korrekt benannt.
5. Ihre Datei "authorized_keys" oder der Ordner ".ssh" wurde gelöscht.

Schritte, um sie zu beheben

• Stoppen Sie die problematische Ec2-Instanz
• Trennen Sie das Root-Volume (/ dev / sda1).
• Erstellen Sie eine ec2-Instanz oder verwenden Sie eine laufende
• Hängen Sie das getrennte Volume (/ dev / sdvf) in eine neue ec2-Instanz ein

Nachdem Sie sich bei new ec2 angemeldet haben, führen Sie die folgenden Schritte aus

• Lsblk-Befehl - listet alle verfügbaren Reittiere auf
• Wählen Sie den Mount-Wert aus, den Sie aus der problematischen Instanz entfernen
• Führen Sie als ec2-Benutzer "sudo mount / dev / mapper / rootvg-home / mnt" aus. sudo mount /dev/mapper/rootvg-home /mnt
• Wechseln Sie dann in das Verzeichnis / mnt
• Nehmen Sie alle erforderlichen Änderungen vor

Jetzt haben wir unser Volumen mit dem Problem behoben, mit dem wir konfrontiert waren. Meistens kann es sich um ein Problem mit der Benutzerberechtigung handeln - Umount / mnt zum Aufheben der Bereitstellung - Gehen Sie jetzt zur Konsole und zeigen Sie auf das an die neue Instanz angehängte Volume und trennen Sie es. - Fügen Sie es nach dem Trennen als / dev / sda1 an Ihr neues Volume an

Wenn dies gesagt ist, sollten Sie sich erfolgreich anmelden können

Nach meiner Erfahrung sollten Sie Schlüssel aus Kitt generieren, nicht aus Linux. Weil der Schlüssel das alte PEM-Format sein wird. Jedenfalls nur mein Vorschlag. Ich habe die folgenden Schritte ausgeführt und gut mit mir und meinem Team zusammengearbeitet.

1. Generieren Sie ein Schlüsselpaar mit PuTTYGen.exe auf Ihrem lokalen Server (Typ: RSA, Länge: 2048 Bit).

2. Speichern Sie den privaten / öffentlichen Schlüssel als " id_rsa.ppk / id_rsa.pub " -Dateien auf Ihrem lokalen Server .

3. Erstellen Sie eine Datei mit " autorisierten Schlüsseln" in Ihrem lokalen Verzeichnis und geben Sie den öffentlichen Schlüssel in " id_rsa.pub " in " autorisierte Schlüssel " ein. Denken Sie daran, dass der Inhalt mit " ssh-rsa " und nur einer Zeile beginnen muss .

4. Verwenden Sie WinScp (oder den Befehl putty), um " authorized_keys & id_rsa.pub " von Ihrem lokalen Server in Ihr Linux-Benutzer-Home " /home/$USER/.ssh/ " zu kopieren .

5. Führen Sie die folgenden Befehle aus:

   chmod 700 .ssh

   chmod 600 .ssh / autorisierte_Tasten

   chown $ USER: $ USER .ssh -R

6. Testen Sie Ihre Verbindungseinstellung, indem Sie den privaten Schlüssel " id_rsa.ppk " in das PuTTY.exe-Profil laden und dann auf " Öffnen " klicken (geben Sie gegebenenfalls Ihre Passphrase ein).

Überprüfen Sie Ihren Schlüssel. Dies sollte heute ein rsa-Schlüssel (id_rsa.pub) und kein dss-Schlüssel (id_dsa.pub) mehr sein. Verwenden Sie puttygen 0.70 und wählen Sie RSA für den zu generierenden Schlüsseltyp. Ersetzen Sie den öffentlichen Schlüssel auf Host ~ /. ssh / autorisierte_Tasten

Melden ec2-userSie sich nach dem Hinzufügen des Schlüssels so an, als ob Sie einen Amazon Linux-Computer verwenden

Ein weiterer Grund könnte die UTF-8-Stückliste in der authorized_keysDatei sein.