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

Ich habe auf meinem lokalen Computer einen privaten und einen öffentlichen Schlüssel erstellt und meinen öffentlichen Schlüssel in die authorized_keys-Datei von Linode kopiert. Wenn ich jedoch versuche, auf meinen Linode zu sshen, wird die Fehlermeldung angezeigt Permission denied (publickey).

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

In meinem .sshVerzeichnis auf meinem lokalen Ubuntu-Rechner habe ich meine id_rsaund id_rsa.pubDateien. Muss ich eine authorized_keys-Datei auf meinem lokalen Computer erstellen?

EDIT: Das bekomme ich, wenn ich renne ssh -vvv -i id_rsa [youruser]@[yourLinode]:

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

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 aus 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 hinzufügen, IdentitiesOnly yesum sicherzustellen, dass sshdie IdentityFileund keine anderen Schlüsseldateien während der Authentifizierung verwendet werden . 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, die Authentifizierung auf den einzelnen angegebenen Schlüssel zu beschränken.

Manchmal liegt das Problem an Berechtigungen und Inhabern. Zum Beispiel möchten , wenn Sie als root anmelden, /root, .sshund authorized_keysmuss 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 .sshund 600 fürauthorized_keys

chmod 700 .ssh
chmod 600 .ssh/authorized_keys

Sie brauchen nicht authorized_keysauf 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 Ihre Passphrase jedes Mal eingeben, wenn Sie eine Verbindung zum Server herstellen möchten.

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

Überprüfen Sie auch den Wert von PasswordAuthenticationin /etc/ssh/sshd_configund noändern Sie ihn in yes. Vergessen Sie nicht, den ssh-Dienst danach neu zu starten.

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 username@host

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

Gewesen sein sollte:

sudo chown username:username /home/username;

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. Aus meiner Erfahrung sshdwird gesucht ~/.ssh/authorized_keysoder ~/.ssh/authorized_keys2standardmäßig.

Bei meinem Webserver hatte der /etc/ssh/sshd_configdiese Leitung

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.

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

AllowUsers user1 user2 user3

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 /etc/ssh/sshd_configauf dem Server angezeigt wird :

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

Ich mein Fall, der Client ist Ubuntu 14.04lts, der Server war Win 2012 Server mit Cygwin. Ich habe 'ssh administrator @ xxxx' verwendet, als das 2012-Serververzeichnis in cygwin / home / Administrator lautete. Wenn ich 'ssh Administrator @ xxxx' ausprobierte (beachte die Groß- und Kleinschreibung von A auf Administrator), funktionierte dies einwandfrei.

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

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 oben von gertvdijk vorgeschlagen , habe ich es überprüft /var/log/auth.logund es stand fest Authentication refused: bad ownership or modes for directory /home/johndoe. Es stellte sich heraus, dass ich zu Unrecht /home/johndoeversucht hatte, /home/johndoe/public_htmldas virtuelle Dokument als Standard-Stammverzeichnis für Apache2 festzulegen (dies wird auch für diese Aufgabe nicht benötigt).

Siehe auch die Antworten hier und hier

Auf dem Server muss nur der öffentliche Schlüssel .ssh/authorized_keysund auf dem Client (auf dem Sie arbeiten) der private Schlüssel (.pem oder bei Verwendung von SFTP mit Filezilla, .ppk) vorhanden sein.

Für diejenigen Putty-Benutzer wie mich, die zu diesem Thread gekommen sind, kann dieser Fehler auch auftreten, 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 user@1.1.1.1 -i /path/to/.pem file 

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

Ich hatte das gleiche Problem wie in der Frage beschrieben. Die Ausgabe der Ausführung 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 , wenn die erzeugte Datei kopieren id_rsa.pubauf dem Server - Rechner, als Datei ~username/.ssh/authorized_keys, würde ich versehentlich das Wort verzichtet ssh-rsavon Anfang an . Das Hinzufügen löste das Problem.

Funktioniert auch unter Ubuntu 16.04.

Das Problem ist in der sshd_configDatei

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

Einige Leute, die sich fragen, haben möglicherweise den ssh-Zugang so eingerichtet, dass er nur auf dem Root-Konto als Schlüssel fungiert

ssh root@your-ip-address

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

In meinem Fall wurde das Problem durch das Kopieren eines .sshVerzeichnisses von einem älteren Computer verursacht. Es stellt sich heraus, dass meine ältere SSH-Konfiguration DSA-Schlüssel verwendet hat, die inzwischen veraltet sind . Der Wechsel zu einem neuen Schlüsselpaar, diesmal RSA-basiert, löste das Problem für mich.

Die folgende Methode funktioniert möglicherweise, wenn Sie unabhängig (z. B. von ComputerC) auf ComputerA und ComputerB zugreifen können.

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

Wenn der öffentliche Schlüssel von Maschine A in den autorisierten Schlüsseln von Maschine B enthalten ist (z. B. ~ / .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

Auf Maschine A ausführencat ~/.ssh/id_rsa.pub

Beispielausgabe:

ssh-rsa AAAAB3NzaSGMFZW7yB anask@mahineA

Kopieren Sie den gedruckten Schlüssel ( ⌘ Command+ Coder CRTL+ C) und fügen Sie ihn in die Datei ~ / .ssh / authorized_keys auf Maschine B ein .

Führen Sie beispielsweise Folgendes auf Maschine B aus :

echo 'ssh-rsa AAAAB3NzaSGMFZW7yB anask@mahineA' >> ~/.ssh/authorized_keys