it-swarm.com.de

Putty: Getting Server hat unseren Schlüsselfehler zurückgewiesen

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

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

Also ist es korrekt (eine Zeile, keine Kommentare, beginnt mit ssh-rsa usw.)

Die Berechtigungsstufe von .ssh dir ist 700, die Dateiberechtigung von authorized_keys ist 600. Sowohl das Verzeichnis als auch die Datei gehören dem Benutzer, den ich gerade versuche. 

Wenn ich versuche, eine Verbindung herzustellen, bekomme ich 'server refused our key' und der Server fragt nach dem Passwort. Das ist alles. Bei /var/log/auth.log wird nichts protokolliert, wenn Sie versuchen, sich mit dem Schlüssel anzumelden. 

Ich habe überall nachgesehen und alle Artikel und Tipps erwähnen die Einstellung von chmod 600 und 700 für die Datei/das Verzeichnis und die korrekte Formatierung des Schlüssels. Ich habe all das gemacht, immer noch den "Fehler" abgelehnt und ich habe keine Ideen mehr.

65
PawelRoman

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

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

LogLevel DEBUG3

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

47
PawelRoman

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

Zunächst einmal, wie in akzeptierter Antwort erwähnt, bearbeiten

/etc/ssh/sshd_config

und Protokollstufe einstellen:

LogLevel DEBUG3

Versuchen Sie dann, sich zu authentifizieren. Wenn dies fehlschlägt, suchen Sie nach Protokolldatei:

/var/log/secure

Es werden Fehler angezeigt, nach denen Sie suchen.

20
Ranty

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

13
Atif

In meinem Fall liegt ein Erlaubnisproblem vor.

Ich habe die Protokollebene in DEBUG3 geändert, und in /var/log/secure sehe ich diese Zeile:

Authentication refused: bad ownership or modes for directory

Googled und ich habe diesen Beitrag gefunden:

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

Im Grunde sagt es mir:

  • befreien Sie sich von der Gruppe w-Berechtigung Ihres Benutzer-Home-Verzeichnisses
  • Ändern Sie die Berechtigung in 700 des .ssh-Verzeichnisses
  • Ändern Sie die Berechtigung in 600 der authorized_keys-Datei.

Und das funktioniert.

Eine andere Sache ist, dass selbst wenn ich das Root-Login aktiviert habe, ich root nicht zur Arbeit bekomme. Verwenden Sie besser einen anderen Benutzer.

5
WesternGun

Die einfache Lösung, die ich gefunden habe, bestand darin, die authorized_keys-Datei aus dem versteckten .ssh-Verzeichnis zu verschieben und in das ssh-Verzeichnis des Systems zu legen:

/etc/ssh/keys/authorized_keys

Sobald ich dies tat, funktionierte es ohne Probleme.

3
mrbronz

Ich füge diese Antwort hinzu, um jemandem wie mir zu helfen, der Stunden damit verbracht hat, das Internet ohne Erfolg zu durchsuchen.

IHR HOME-ORDNER KANN VERSCHLÜSSELT WERDEN. 

Oder in diesem Fall jeden Ordner, in dem Ihre "authorized_keys" -Datei verschachtelt ist. Mann, das hätte mir viel Zeit gespart. Zur Überprüfung gehen Sie auf Ausführen

ls -A

in dem Verzeichnis, dessen Verschlüsselungsstatus Sie ermitteln möchten. Wenn der Ordner einen Ordner mit dem Namen ".encryptfs" enthält, lautet die Antwort: Ja, dieser Ordner ist verschlüsselt. Dies verhindert, dass Sie auf die Datei "authorized_keys" zugreifen können, die den zur Überprüfung erforderlichen öffentlichen ssh-Schlüssel enthält. 

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

3
Mackie Messer

Vielen Dank!

Vielen Dank für LogLevel DEBUG3 (in meinem Fall CentOS 7 ist das Protokoll in /var/log/secure)

Es stellte sich heraus, dass mein .ssh/authorized_keys-Modus 644 und nicht 600 war, und sshd hielt das alleine für ein No-Go, was ich schließlich beim Lesen dieser Protokolldatei entdeckte!

3
Sxilderik

mit dem gleichen Problem in Windows Server 2008 r2 und viel zu lösen, tat dies schließlich durch Folgendes:

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

entfernen Sie den Kommentar aus den folgenden Zeilen. Nach dem Entfernen sollten sie folgendermaßen 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ß.

3
Ravi Anand

Dank nrathaus und /var/log/auth.log Untersuchung auf dem Debuglevel kommt folgendes.

Ein weiterer Grund ist, dass Ihr Basisverzeichnis andere Berechtigungen als 755 hat.

2
Intel83

Ich bin heute auf dieses Problem gestoßen und mein Problem war, dass beim Kopieren des öffentlichen Schlüssels aus der Datei auch neue Zeilenzeichen eingefügt werden. Sie können ": set list" in vim verwenden, um alle ausgeblendeten neuen Zeilen zu sehen und sicherzustellen, dass alle neuen Zeilen außer der letzten gelöscht werden. Am Anfang fehlte auch mein Schlüssel "ssh-rsa". Stellen Sie sicher, dass Sie auch das haben.

2
hyeuc

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

Bearbeiten Sie/etc/selinux/config und legen Sie Folgendes fest, und starten Sie den Host neu.

selinux=disabled

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

1
sagaya

Ich hatte den gleichen Fehler auf 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 üblich mit authorized_keys verwenden.

1
Bruno Ruess

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

PermitRootLogin no

Geändert in yes, startete den Dienst neu und stieg normal ein.

1
Alex Fortuna

Für diejenigen, die diesen Fehler von Windows Server erhalten haben, habe ich denselben Fehler erhalten, und es war ein Problem mit dem Benutzerkonto. In vielen Organisationen können Gruppenrichtlinien für Administratoren das Einrichten von SSH-Server und Verbindungen nicht zulassen. Bei dieser Art von Setup muss dies vom lokalen Admin-Konto aus erfolgen. Es könnte sich lohnen, nachzusehen, wenn Sie bestätigt haben, dass der öffentliche Schlüssel keine Tippfehler enthält.

1
Andrew Campbell

Ich habe dieses Problem gelöst, puttygen ist eine Software eines Drittanbieters. Der ssh-Schlüssel wurde nicht direkt verwendet. Daher müssen Sie einige Änderungen vornehmen. So sieht es beispielsweise aus 

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

Ich lasse einige Alphabete in der Mitte aus, ersetzt durch *, falls nicht, StackOverflow sagte mir, dass das Code-Format falsch ist, lass mich nicht 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== [email protected]

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

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

und füge ssh-rsa am Anfang hinzu, füge [email protected] als letztes hinzu . note : Nicht delete== im letzten und Sie müssen "yourname" und "hostname" für Sie ändern. In meinem Fall ist [email protected]. Ihr Name ist, dass Sie sich in Ihrem vps anmelden möchten Wenn all dies geschehen ist, können Sie den public-key in uaskhs home~/.ssh/authorized_keys durch cat public-key >> ~/.ssh/authorized_keys hochladen, dann Sudo chmod 700 ~/.sshSudo chmod 600 ~/.ssh/authorized_keys. Dann müssen Sie/etc/ssh/sshd_config ändern , RSAAuthentication yesPubkeyAuthentication yesAuthorizedKeysFile .ssh/authorized_keys mein Betriebssystem ist CentOS 7, Dies ist mein erstes Mal, um eine Frage zu beantworten. Ich werde mich bemühen, Danke zu machen!

0
toffee

Ich habe dieses Problem, bei dem sshd nur aus authorized_keys2 liest.

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

cd  ~/.ssh
Sudo cat authorized_keys >> authorized_keys2

P.S. Ich verwende PuTTY von Windows und verwende PuTTyKeygen für die Schlüsselpaargenerierung.

0
Chad Liu

In meinem Fall zu Hause auf nfs war 777, musste 750 sein. Das Problem wurde behoben.

0
dghadge

Ich hatte ein ähnliches Problem, als ich versuchte, mich über Mobaxterm anzumelden. Der private Schlüssel wurde durch Puttygen generiert. Die Wiederherstellung des Schlüssels half in meinem Fall.

0
Prada

Schritte zum Beheben des Root-Mount (Dies ist der Fall, als ich die Berechtigung mit dem Ordner ec2-user und der Autorisierungsschlüsseldatei geändert habe) Dieser Vorgang ähnelt dem Trennen und Anschließen eines USB-Sticks

Im Folgenden sind einige andere Szenarien aufgeführt, auf die Sie möglicherweise stoßen -  

  1. Sie verwenden einen privaten SSH-Schlüssel, der entsprechende öffentliche Schlüssel befindet sich jedoch nicht in der Datei authorized_keys.
  2. Sie haben keine Berechtigungen für die Datei "authorized_keys".
  3. Sie haben keine Berechtigungen für den .ssh-Ordner.
  4. Ihre authorisierte_keys-Datei oder der .ssh-Ordner wurde nicht korrekt benannt.
  5. Ihre authorisierte_keys-Datei oder der .ssh-Ordner 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 Instanz
  • Hängen Sie das freistehende Volume (/ dev/sdvf) an die neue ec2-Instanz an 

Nun, nachdem Sie sich bei der neuen ec2 angemeldet haben, führen Sie die folgenden Schritte aus  

  • Lsblk-Befehl - listet alle verfügbaren Mounts auf
  • Wählen Sie den Mount-Wert aus, den Sie aus der problematischen Instanz entfernen möchten 
  • Führen Sie als ec2-Benutzer "Sudo mount/dev/mapper/rootvg-home /mnt" aus Sudo mount /dev/mapper/rootvg-home /mnt
  • Dann wechseln Sie in das Verzeichnis/mnt
  • Nehmen Sie alle erforderlichen Änderungen vor

Jetzt haben wir unser Volumen mit dem Problem, mit dem wir konfrontiert waren, korrigiert. Meistens könnte es sich um ein Problem mit der Benutzerberechtigung handeln - Umount/mnt, um die Bereitstellung aufzuheben - Gehen Sie nun zur Konsole und zeigen Sie auf das Volume, das der neuen Instanz zugeordnet ist, und trennen Sie es - Ihr neues Volume als/dev/sda1 

Mit diesem solltest du dich erfolgreich einloggen können  

0

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

Der Anleitung folgen: https://winscp.net/eng/docs/guide_windows_openssh_server Es war einfach, eine Verbindung mit dem Windows-Login username und password herzustellen. Bei der Authentifizierung mit username in Kombination mit einem private key lautete die Antwort jedoch server refused our key.

Damit es mit einem öffentlichen Schlüssel funktioniert, mussten die Berechtigungen für die Datei erfüllt werden: C:\ProgramData\ssh\administrators_authorized_keys

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

Beenden Sie die beiden OpenSSH-Dienste und öffnen Sie dann einen command Prompt mit admin permissions. Führen Sie dann Folgendes aus: C:\OpenSSH-Win32>c:\OpenSSH-Win32\sshd.exe -ddd

Hinweis: Geben Sie den vollständigen Pfad zur Exe an, ansonsten beschwert sich sshd. Dadurch wird ein einmal verwendbarer Verbindungs-Listener erstellt. Der -ddd ist ausführlich Level 3.

Nachdem Sie eine Verbindung hergestellt haben, haben Sie beim Scannen der Protokolle Folgendes festgestellt:

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 kopieren Sie den public key-Text hinein, z. B .: ssh-rsa AAAA................MmpfXUCj rsa-key-20190505 Und speichern Sie dann die Datei. Ich habe die Datei als UTF-8 mit dem BOM gespeichert. ANSI nicht getestet.

Führen Sie dann die einmalige Befehlszeile erneut aus. In den Protokollen wurde 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-11 ist der Name, der der System gegeben wird.

Um den Bad permissions zu korrigieren, klicken Sie mit der rechten Maustaste auf die administrators_authorized_keys-Datei, wechseln Sie zum Security Tab, klicken Sie auf die Schaltfläche Advanced und entfernen Sie geerbte Berechtigungen. Löschen Sie dann den gesamten Group or user names: mit Ausnahme des Windows-Anmeldenamens, z. B .: YourMachineName\username Die Berechtigungen für diesen username sollten Read Allow sein, Write Deny alles andere ist deaktiviert. Der Besitzer der Datei sollte auch YourMachineName\username sein

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 von WinSCPnet.dll zum Herstellen einer Verbindung zum OpenSSH-Server: https://winscp.net/eng/docs/library#csharp

Hier ist das Code-Snippet, um eine Verbindung mit dem WinSCPnet.dll herzustellen:

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 SshHostKeyFingerprint und SshPrivateKeyPath durch Ihre eigenen Werte.

Bearbeiten: Screenshot der Dateiberechtigungen von administrators_authorized_keys hinzugefügt:  enter image description here 

Wenn OpenSSH SSH Server als Dienst ausgeführt wird, sollte nur System über die Berechtigung verfügen. Wenn Sie jedoch sshd.exe über den Befehl Eingabeaufforderung ausführen, sollte nur der aktuelle Benutzer aufgeführt sein (Leseberechtigung, Schreibverweigerung).

0
Loathing

melden Sie sich als ec2-user an, wenn Sie einen Amazon Linux-Computer verwenden

0
sachin_ur

überprüfen Sie Ihren Schlüssel. Dies sollte heute ein rsa-Schlüssel (id_rsa.pub) sein und kein dss-Schlüssel (id_dsa.pub) mehr. 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/authorized_keys

0
Don Matteo

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

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

0
Tomás Cot

Was für mich funktioniert, ist:

  • Die ec2-Instanz wurde angehalten
  • trennen Sie die Lautstärke
  • das Volume mit der alten Instanz mit demselben Schlüssel verbinden und konnte SSH
  • mounten Sie das Volume in einem temporären Ordner
  • überprüfte die Datei im Verzeichnis mount_point/home/ec2-user/.ssh/authorised_keys
    • Im Idealfall muss diese Datei unsere Schlüsselinformationen enthalten, aber für mich war diese Datei leer
  • kopierte die alte Instanz authorized_keys auf den neu geladenen Datenträger
  • demontieren Sie das Gerät
  • verbinden Sie sich wieder mit der ursprünglichen ec2-Instanz
  • starten Sie es und lassen Sie die Gesundheitskontrollen bestehen

Diesmal klappt es bei mir. Ich weiß jedoch nicht, warum meine Schlüsseldatei beim Start der Instanz nicht vorhanden ist. Überprüfen Sie auch diesen Link https://docs.aws.Amazon.com/AWSEC2/latest/UserGuide/FehlerbehebungInstanzenConnecting.html#FehlerbehebungInstanzenConnectingMindTerm

0
Sohaib Mustafa

Ich verwende eine PUTTYgen-Datei mit psftp. Dieses Problem ist auf meinem Windows Server aufgetreten, als neue Schlüssel für einen Client erstellt werden mussten. Die Datei private_key_name .ppk und die Datei open_ssh.txt müssen sich im selben Verzeichnis befinden, damit die Verbindung funktioniert. 

0
Geir Borse

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

fehler: key_read: key_from_blob AA
AAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG + rKz93l7em1BsUBzjHPMsswD

es bedeutet, dass Ihr Schlüssel über Speicherplatz verfügt. Wenn Sie beim Anzeigen der .ppk-Datei einen Schlüssel über puttgen generiert haben, sieht das folgendermaßen aus:

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

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

das sollte etwas aussehen

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG+rKz93l7em1BsUBzjHPMsswDal74MLaJyhQD0pE23NS1izahbo1sJGnSJu2VJ//zxidSsba6xa6OvmeiKTwCz0E5GMefdGVdpdbTlv99qjBl1+Nw1tDnHIC0+v9XmeZERQfCds9Kp1UivfReoYImntBCgLtNyqRYrSu8csJCt7E1oY8QK6WP1vfYgAQ2taGyS9+g7FHyyf5VY2vH3oWzzbqzxjsSLAv3zEQSm1LzSw9Pvc8iwasFyUMBOPj31CKQYTXyX8KpJTr0Zb7oqMauBE5LVwxZhlcJHbj0FsMbF/+GRjvgexymCi3bHmwGQ6FEADNd0RkhdQ== [email protected]

0
Sandeep Chhabra

In meinem Fall war das Problem so, bei der Erzeugung von SSH-Schlüsseln habe ich absichtlich die Standardverzeichnisse der Schlüssel geändert. Anstatt den Speicherort ~/.ssh/authorised_keys zu verwenden, entschied ich mich, ~/home/user/folder1/.ssh/authorized_keys zu verwenden. Damit diese Änderungen funktionieren, sollte ich die gleichen Änderungen des neuen Speicherorts in dieser Datei /etc/ssh/sshd_config vornehmen. Aber bis ich mir dessen bewusst bin, hatte ich bereits mehrere Lösungen ausprobiert, die von anderen Leuten hier vorgeschlagen wurden, einschließlich der Erlaubnis für den Home-Ordner auf 700 und das .ssh-Verzeichnis auf 600.

0
jstMusa

Aus meiner Erfahrung heraus empfehle ich, dass Sie Schlüssel aus PuTTY generieren und nicht aus Linux. Weil der Schlüssel das alte PEM-Format hat. Jedenfalls nur mein Vorschlag. Ich habe als Schritte unten und gut mit mir und mit meinem Team gearbeitet.

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

  2. Speichern Sie den privaten/öffentlichen Schlüssel als " id_rsa.ppk/id_rsa.pub " Datei in Ihrem lokalen Verzeichnis.

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

 enter image description here 

  1. Verwenden Sie WinScp (oder den PuTTY-Befehl), um " authorized_keys & id_rsa.pub " von Ihrem lokalen zu Ihrem Linux-Benutzer " /home/$USER/.ssh/ " zu kopieren.

 enter image description here 

  1. Führen Sie diese Befehle aus:

    chmod 700 .ssh

    chmod 600 .ssh/authorized_keys

    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 ggf. Ihre Passphrase ein).

 enter image description here 

 enter image description here 

0
m.nguyencntt