it-swarm.com.de

SSH-Berechtigung verweigert (publickey)

Ich versuche, von meinem lokalen Computer aus eine Verbindung zu einem Linode (Ubuntu 12.04 LTS) herzustellen (auch Ubnutu 12.04 LTS).

Ich habe auf meinem lokalen Computer einen privaten und einen öffentlichen Schlüssel erstellt und meinen öffentlichen Schlüssel in die authorized_keys-Datei meines Linodes kopiert. Wenn ich jedoch versuche, auf meinen Linode zu ssh zuzugreifen, erhalte ich die Fehlermeldung "Permission denied (publickey)".

Es ist kein Problem damit, wie ssh auf meinem Linode eingerichtet ist, da ich mithilfe der Schlüsselauthentifizierung von meinem Windows-Computer aus auf ssh zugreifen kann.

In meinem .ssh-Verzeichnis auf meinem lokalen Ubuntu-Computer befinden sich meine Dateien id_rsa und id_rsa.pub. Muss ich eine authorized_keys-Datei auf meinem lokalen Computer erstellen?

BEARBEITEN: Das bekomme ich, wenn ich ssh -vvv -i id_rsa [youruser] @ [yourLinode] ausführe

debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).
107
Pattle

PubKeyAuthentication

Richten Sie Ihren Client ein

  1. Generieren Sie Ihren Schlüssel
    • ssh-keygen
  2. Konfigurieren Sie ssh für die Verwendung des Schlüssels
    • vim ~/.ssh/config
  3. Kopieren Sie Ihren Schlüssel auf Ihren Server
    • ssh-copy-id -i /path/to/key.pub SERVERNAME

Ihre Konfigurationsdatei von Schritt 2 sollte ungefähr so ​​aussehen:

Host SERVERNAME
Hostname ip-or-domain-of-server
User USERNAME
PubKeyAuthentication yes
IdentityFile ./path/to/key

Sie können IdentitiesOnly yes hinzufügen, um sicherzustellen, dass ssh die IdentityFile und keine anderen Schlüsseldateien während der Authentifizierung verwendet. Dies kann Probleme verursachen und ist keine gute Vorgehensweise.

Fehlerbehebung

  1. benutze die Option "-vvv"
  2. Stellen Sie sicher, dass der Server über Ihren PUBLIC-Schlüssel (.pub) verfügt.
  3. Stellen Sie sicher, dass Ihr IdentiyFile auf Ihren PRIVATEN Schlüssel verweist.
  4. Stellen Sie sicher, dass in Ihrem SSH-Verzeichnis 700 und in Ihren Dateien 700 Berechtigungen vorhanden sind (rwx ------).
  5. tail -f /var/log/auth.log (auf dem Server) und überwachen Sie Fehler, wenn Sie versuchen, sich anzumelden
  6. Wenn Sie über viele Schlüsseldateien verfügen, versuchen Sie IdentitiesOnly yes, um die Authentifizierung auf die Verwendung des einzelnen angegebenen Schlüssels zu beschränken.
90
earthmeLon

Manchmal liegt das Problem an Berechtigungen und Inhabern. Wenn Sie sich beispielsweise als root anmelden möchten, müssen /root, .ssh und authorized_keys zu root gehören. Andernfalls kann sshd sie nicht lesen und daher nicht feststellen, ob der Benutzer berechtigt ist, sich anzumelden.

In Ihrem Heimatverzeichnis:

chown -R your_user:your_user .ssh

Bezüglich der Rechte gehen Sie mit 700 für .ssh und 600 für authorized_keys

chmod 700 .ssh
chmod 600 .ssh/authorized_keys
57
Buzut

Sie brauchen authorized_keys nicht auf Ihrem Client.

Sie müssen den ssh-client anweisen, den von Ihnen generierten Schlüssel tatsächlich zu verwenden. Dafür gibt es verschiedene Möglichkeiten. Nur zum Testen von Typ ssh -vvv -i .ssh/id_rsa [youruser]@[yourLinode]. Sie müssen Ihr Passwort jedes Mal eingeben, wenn Sie eine Verbindung zum Server herstellen möchten.

Wenn das geklappt hat, können Sie den Schlüssel zum ssh-agent mit ssh-add .ssh/id_rsa hinzufügen (Sie müssen die Passphrase nur einmal eingeben und sie sollte funktionieren, solange Sie sich nicht ausloggen/neu starten)

14
guntbert

Überprüfen Sie auch den Wert von PasswordAuthentication in /etc/ssh/sshd_config und ändern Sie ihn in no, wenn es sich um yes handelt. Vergessen Sie nicht, den ssh-Dienst danach neu zu starten.

10
iman

Das Problem, das ich hatte, war die Verwendung der falschen Schlüssel auf dem Client. Ich hatte id_rsa und id_rsa.pub in etwas anderes umbenannt. Sie können sie entweder wieder in die Standardeinstellung umbenennen oder den Befehl ssh folgendermaßen verwenden

ssh -i ~/.ssh/private_key [email protected]
7
Todd

Stellen Sie außerdem sicher, dass das Home-Verzeichnis des Benutzers (auf dem Server) tatsächlich dem Benutzer gehört, in den ssh'ing (in meinem Fall root: root).

Gewesen sein sollte:

Sudo chown username:username /home/username;
7
canoodle

Ich bin kürzlich mit meinem Webserver auf dieses Problem gestoßen.

Normalerweise behalte ich eine Liste der autorisierten Schlüssel auf allen meinen Servern in ~/.ssh/authorized_keys2. Nach meiner Erfahrung sucht sshd standardmäßig nach ~/.ssh/authorized_keys oder ~/.ssh/authorized_keys2.

Bei meinem Webserver hatte der /etc/ssh/sshd_config diese Zeile

AuthorizedKeysFile    %h/.ssh/authorized_keys

anstatt von

AuthorizedKeysFile    %h/.ssh/authorized_keys2

Ich habe letzteres angewendet, meinen ssh-Daemon neu gestartet und mein Problem beim Anmelden mit ssh mit meinem Pubkey gelöst.

3
Justin C

Eine weitere mögliche Ursache könnte in der AllowedUsers Konfiguration in /etc/ssh/sshd_conf liegen. HINWEIS: Die Liste ist Leerzeichen (nicht durch Kommas getrennt), wie ich auf die harte Tour gelernt habe.

AllowUsers user1 user2 user3
2
cmbind55

Einige Benutzer, die sich fragen, haben möglicherweise den ssh-Zugriff so eingerichtet, dass er nur auf dem Root-Konto als Schlüssel fungiert. Dann haben sie einen neuen Benutzer erstellt und nicht erkannt, dass dies erforderlich ist

ssh [email protected]

rsync --archive --chown=[user]:[user] ~/.ssh /home/[user]

logout

Dann versuche es nochmal. Ersetzen Sie [Benutzer] durch Ihr neues Benutzerkonto.

Dies ist häufig der Fall, wenn Sie einen neuen Server auf DigitalOcean einrichten, während Sie beim Setup ssh-keys verwendet haben.

https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-18-04

1
LpLrich

Das hat bei mir funktioniert, das Update ist nicht meins, aber ich würde es lieber hier aufschreiben, falls jemand anderes das gleiche Problem hat.

Der ursprüngliche Autor hat es hier gepostet: digital-ocean-public-access-key-denied

Sudo nano /etc/ssh/sshd_config

Ersetzen Sie diese

UsePAM yes
IgnoreUserKnownHosts no
PasswordAuthentication no

Mit diesem

UsePAM no
IgnoreUserKnownHosts no
PasswordAuthentication yes

Speichern Sie die Datei und starten Sie ssh neu

reload ssh

ssh sollte jetzt funktionieren und nach einem Passwort fragen

1
mau

Funktioniert auch unter Ubuntu 16.04.

Das Problem befindet sich in der Datei sshd_config

Hier ist die ultimative Lösung:

Melden Sie sich als root bei Ihrem Ubuntu-Server an

vi /etc/ssh/sshd_config

Gehen Sie jetzt ganz nach unten und ändern Sie den Wert von "no" in "yes".

Es sollte so aussehen:

Ändern Sie den Wert in no, um getunnelte Klartextkennwörter zu deaktivieren

PasswordAuthentication yes
service sshd reload

in Kraft treten.

Jetzt können Sie einfach einen Schlüssel mit folgendem Befehl von Ihrem LOKALEN Computer (auch bekannt als Laptop usw.) eingeben

Öffnen Sie also ein neues Terminalfenster und melden Sie sich NICHT beim Server an. Geben Sie einfach den folgenden Befehl ein:

ssh-copy-id john @ serverIPAddress

(Ersetzen Sie John durch Ihren Benutzernamen).

du solltest gehen, um zu gehen

1
Galapagos

Ich hatte das gleiche Problem beim Kopieren des öffentlichen Schlüssels eines regulären Benutzers (z. B. johndoe) von einem cPanel Centos-System auf einen Ubuntu-Server unter AWS. Wie von gertvdijk oben vorgeschlagen, habe ich /var/log/auth.log überprüft und es stand Authentication refused: bad ownership or modes for directory /home/johndoe. Es stellte sich heraus, dass ich fälschlicherweise /home/johndoe gewählt hatte, als ich versuchte, /home/johndoe/public_html als Standard-Dokumentstamm für den virtuellen Host für Apache2 festzulegen (dies wird auch für diese Aufgabe nicht benötigt).

Siehe auch die Antworten hier und hier

Der Server muss nur den öffentlichen Schlüssel in .ssh/authorized_keys haben, und der Client (Computer, an dem Sie arbeiten) muss den privaten Schlüssel (.pem oder bei Verwendung von SFTP mit Filezilla, .ppk) haben.

1
site80443

Ich mein Fall, der Client ist Ubuntu 14.04lts, der Server war Win 2012 Server mit Cygwin. Ich habe 'ssh [email protected]' verwendet, als das 2012-Serververzeichnis in cygwin/home/Administrator lautete. Wenn ich also 'ssh [email protected]' ausprobierte (beachte das Großbuchstaben A bei Administrator), funktionierte es einwandfrei.

Eine Fehlermeldung wie "Benutzer nicht gefunden" hätte mich viel schneller zur Lösung geführt als "Berechtigung verweigert (öffentlich, tastaturinteraktiv)".

1
Kent

Für die PuTTY-Benutzer wie mich, die zu diesem Thread gekommen sind, wird dieser Fehler möglicherweise auch angezeigt, wenn Sie vergessen haben, den Benutzer user @ Ip!

Andere mit Erlaubnis für Schlüsseldatei (chmod bis 600)

ssh 1.1.1.1 -i /path/to/.pem file 
Permission denied (publickey).`

ssh [email protected] -i /path/to/.pem file 
1
Alex Punnen

Ich hatte das gleiche Problem wie in der Frage beschrieben. Die Ausgabe von ssh -vvv -i id_rsa [youruser]@[yourLinode] auf dem Client-Computer war ähnlich der in der Frage beschriebenen. Ich habe alle Datei- und Verzeichnisberechtigungen überprüft, wie in den anderen Antworten angegeben, und sie waren korrekt.

Es stellte sich heraus, dass beim Kopieren der generierten Datei id_rsa.pub auf den Server-Rechner als Datei ~username/.ssh/authorized_keysich hatte versehentlich das Wort ssh-rsa von Anfang an weggelassen. Das Hinzufügen löste das Problem.

1
Teemu Leisti

Wenn alles andere fehlschlägt, überprüfen Sie, ob Ihr angemeldeter Benutzer zur AllowedGroup von ssh gehört. Das heißt, Ihre Benutzer sind Mitglied der Gruppe, die in der folgenden Zeile in /etc/ssh/sshd_config auf dem Server angezeigt wird:

AllowGroups ssh #Here only users of 'ssh' group can login
1
biocyberman

In meinem Fall wurde das Problem durch Kopieren über ein .ssh -Verzeichnis von einem älteren Computer verursacht. Es stellte sich heraus, dass meine ältere SSH-Konfiguration DSA-Schlüssel verwendete, die seitdem veraltet waren. Der Wechsel zu einem neuen Schlüsselpaar, diesmal RSA-basiert, löste das Problem für mich.

0
Glutanimate

Die folgende Methode funktioniert möglicherweise, wenn Sie unabhängig von Maschine A und Maschine B zugreifen können (z. B. von Maschine C).

Wenn ssh-copy-id nicht funktioniert, kann die Kennwortauthentifizierung deaktiviert werden. Folgendes ist eine Problemumgehung.

Wenn der öffentliche Schlüssel von Maschine A in den autorisierten Schlüsseln von Maschine B enthalten ist (d. H. ~/.Ssh/authorized_keys), können Sie von Maschine A aus ssh ausführen. Dies gilt auch für scp.

Nach dem Generieren der Schlüsselpaare mit: ssh-keygen

Führen Sie auf machineAcat ~/.ssh/id_rsa.pub aus

Beispielausgabe:

ssh-rsa AAAAB3NzaSGMFZW7yB [email protected]

Kopieren Sie den gedruckten Schlüssel (⌘ Command+C, oder CRTL+C) und fügen Sie es dann in die Datei ~/.ssh/authorized_keys unter machineB ein.

Führen Sie beispielsweise Folgendes auf machineB aus:

echo 'ssh-rsa AAAAB3NzaSGMFZW7yB [email protected]' >> ~/.ssh/authorized_keys

0
anask