Putty: Der Server hat unseren Schlüsselfehler abgelehnt


84

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.


2
Haben Sie Putty angewiesen, denselben Schlüssel zu verwenden? Melden Sie sich mit demselben Benutzer an? Ist dies eine Standard-SSH-Installation oder haben Sie sshd_config geändert?
Noam Rathaus

Puttygen generiert 3 Schlüssel: privat, öffentlich und eine eigene Version des privaten Schlüssels mit der Erweiterung .ppk. Ich verwende natürlich .ppk mit putty.exe und füge den öffentlichen Schlüssel in .ssh / authorized_keys auf dem Server ein. Es ist die Standard-SSH-Installation / -Konfiguration. Ich habe sshd_config nicht geändert.
PawelRoman

Übrigens musste ich das .ssh-Verzeichnis und auhtorized_keys erstellen, da es sich um eine neue Ubuntu-Installation handelt und nicht vorhanden war. Vielleicht hat das etwas mit dem Problem zu tun?
PawelRoman

3
Stellen Sie sicher, dass sshd_config für die Verwendung öffentlicher Schlüssel konfiguriert ist. Dies ist möglicherweise nicht der Fall
Noam Rathaus

2
Sehen Sie etwas in /var/log/auth.log? Erhöhen Sie den LogLevel der SSH-Protokolle auf DEBUGund prüfen Sie, ob protokollierte Probleme angezeigt werden. Wenn der Zugriff immer noch nicht angezeigt wird, suchen Sie in der falschen Protokolldatei
Noam Rathaus,

Antworten:


58

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.


7
Genau das gleiche Problem :)
Trefex

Welche Protokolle haben Sie überprüft und wo sind sie? Was ist die Kennung, von der Sie sprechen?
user1046647

3
@ user1046647 LogLevelist definiert in /etc/ssh/sshd_config. Das Standardprotokoll ist, /var/log/auth.logsofern in nicht anders definiert sshd_config.
Axel Kemper

3
Wenn Sie authorized_key in vim öffnen und sofort versuchen, das erste 's' aus 'ssh_rsa' einzufügen, wird dies als vim-Befehl behandelt. Danach wechselt vim in den Einfügemodus und der verbleibende Text wird eingefügt. Wenn Sie zuvor in den Einfügemodus wechseln Das Einfügen (z. B. Verwenden i) der führenden 's' wird nicht ausgeschnitten
Pawel,

1
! sudo service ssh restartdamit die Änderungen wirksam werden. Ansonsten war nichts in meiner Auth-Log-Datei.
Hogan

29

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.


/var/log/existiert, existiert aber securenicht. Wie finde ich heraus, in welches Protokoll geschrieben wird?
Aliteralmind

9
Die Standardeinstellung ist /var/log/auth.logzumindest in meinem Ubuntu 14.04.1.
Axel Kemper

JA! Danke! Es stellte sich heraus, dass meine Pub-Schlüsseldatei am Ende ein unsichtbares \ n hatte
alextsil

1
Linux / Ubuntu ist so frustrierend. Verbrachte gut 20 Minuten damit, herauszufinden, warum es keine secureDatei gab, bevor ich @axel-Kommentare hier las.
JYelton

17

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


1
Dies war die Ursache und Lösung für mich
Pstanton

4
und für mich haben Ordner 700 und autorisierte Schlüssel 600 das Problem gelöst
David Soussan

1
Für mich das gleiche, chmod 700 auf .ssh Ordner und chmod 600 auf autorisierten_keys löste das Problem
Iwo Kucharski

.ssh Ordner 700 und autorisierte Schlüssel 600 haben es für mich behoben.
Deep-B

13

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.


Diese Antwort wurde unterbewertet. Die übersehenen Berechtigungen des Home-Verzeichnisses können die Fehlerbehebung einen ganzen Tag kosten.
chingNotCHing

Danke, dass du für mich gestimmt hast. Ich teile nur, was ich habe.
WesternGun

5

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: Geben Sie hier die Bildbeschreibung ein

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).


3
Sie haben hier viele Dinge getan, die geholfen haben. Zuerst wird sshd mit dem Debug-Flag in der Befehlszeile ausgeführt. Windows Service System-Protokolle zeigten nur sehr wenig und waren für das Debuggen völlig nutzlos. Zweitens die Haupttatsache, dass es als Administrator einen Fehler gibt, der nur in der Datei administrators_authorized_keys und nicht im erwarteten Ordner "Users .ssh" für autorisierte_keys angezeigt wird (jeder ist traurig, wenn er sshd unter Windows ausführt). Endlich der Ordner 'ssh' in ProgramData! Ich habe mich gefragt, wo die Server-Zertifikate usw. abgelegt wurden. Nur Ihre Informationen hier haben mir geholfen, nachdem ich mir etwa einen Tag lang den Kopf gekratzt hatte. Vielen Dank!
Meister James

Diese Antwort war die einzige, die für mich auf einer neuen kostenlosen Stufe der ec2-Instanz Windows 2019 funktioniert hat.
Yolob 21.

3

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.


3

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.


3

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ß.


ssh wird manchmal installiert, wobei die autorisierte Schlüsseldatei auskommentiert ist, so dass es nicht weiß, wo nach der autorisierten Schlüsseldatei gesucht werden soll :-(
kenyee

Welche Berechtigungen sind für die Datei authorized_keys erforderlich? Und muss es sich im Benutzerverzeichnis oder im Verzeichnis von OpenSSH befinden?
GarfieldKlon

Es sollte sich im OpenSSH-Verzeichnis befinden oder dort, wo Sie OpenSSH installiert haben. Sie sollten es finden können
Ravi Anand

Stellen Sie sicher, dass Sie es mit dem Administratorkonto einrichten.
Ravi Anand

2

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.


Ihr Home-Verzeichnis sollte 700 sein, das ist die Standardeinstellung unter CentOS.
Karatedog

2

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.


1
Ähnlich hier: Beim Kopieren aus PuttyGen hatte ich neue Zeilen nach "ssh-rsa" und nach dem Schlüssel. Nachdem sie entfernt wurden, funktionierte es.
Lucian P.

1

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.


1

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.


1
Anstatt SELinux zu deaktivieren, können Sie den Sicherheitskontext im Ordner .ssh ändern. chcon -R -t ssh_home_t .ssh
palehorse

1

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.


1

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

PermitRootLogin no

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


1

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!


1
@ Ronak Bhatt, Vielen Dank für meine Bemühungen. Ich habe versucht, die Codes klarer zu gestalten. Für all diesen Code habe ich Strg + K verwendet, aber StackOverflow sagte mir, "Ihre Antwort enthält Codes, bitte verwenden Sie das richtige Format", und ich weiß nicht warum Es ist anders zwischen schriftlich und eingereicht. Ich kann meine Antwort nicht einreichen, was dazu führt, dass ich zeilenweise Codes in 'Code' einfügen muss. Ich werde das Markdown-Format lernen, denkt.
Toffee

In der aktuellen Version zeigt PuttyGen den öffentlichen Schlüssel im richtigen Format zum Kopieren und Einfügen an. Es ist also nicht mehr erforderlich, den Putty-Pub-Schlüssel manuell in das richtige Format zu konvertieren.
Erik Kalkoken

1

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.


0

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.


0

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


0

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.


0

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.


0

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.


0

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


0

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


0

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.


0

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


0

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 .

Geben Sie hier die Bildbeschreibung ein

  1. 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 .

Geben Sie hier die Bildbeschreibung ein

  1. Führen Sie die folgenden Befehle aus:

    chmod 700 .ssh

    chmod 600 .ssh / autorisierte_Tasten

    chown $ USER: $ USER .ssh -R

  2. 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).

Geben Sie hier die Bildbeschreibung ein

Geben Sie hier die Bildbeschreibung ein


0

Ü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


0

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


Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.