ssh: Erlaubnis verweigert (publickey)

1197
SoftTimur

Ein Kollege hat an einem Server gearbeitet ssh root@xxx.xxx.xxx.xxxund das Passwort in unserer Dokumentation geschrieben.

Ich habe es gerade ssh-keygenauf meinem Rechner gemacht und habe es ssh -v root@xxx.xxx.xxx.xxxvon meinem Rechner versucht, aber ich habe folgende Fehlermeldung erhalten.

Weiß jemand, wie man es reparieren kann?

OpenSSH_7.6p1, LibreSSL 2.6.2 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 48: Applying options for * debug1: Connecting to xxx.xxx.xxx.xxx port 22. debug1: Connection established. debug1: identity file /Users/softtimur/.ssh/id_rsa type 0 debug1: key_load_public: No such file or directory debug1: identity file /Users/softtimur/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /Users/softtimur/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /Users/softtimur/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /Users/softtimur/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /Users/softtimur/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /Users/softtimur/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /Users/softtimur/.ssh/id_ed25519-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_7.6 debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4p1 Ubuntu-10 debug1: match: OpenSSH_7.4p1 Ubuntu-10 pat OpenSSH* compat 0x04000000 debug1: Authenticating to xxx.xxx.xxx.xxx:22 as 'root' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: curve25519-sha256 debug1: kex: host key algorithm: ecdsa-sha2-nistp256 debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ecdsa-sha2-nistp256 SHA256:Pw4cFx5c2WGJzTwTL+gsx3AMHMEuT0sei1fz5oGCrac debug1: Host 'xxx.xxx.xxx.xxx' is known and matches the ECDSA host key. debug1: Found key in /Users/softtimur/.ssh/known_hosts:4 debug1: rekey after 134217728 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey after 134217728 blocks debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521> debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Offering public key: RSA SHA256:EL7hm5LvdVADZiv662nneDEeoLKy+etj8OT61eugu4Y /Users/softtimur/.ssh/id_rsa debug1: Authentications that can continue: publickey debug1: Trying private key: /Users/softtimur/.ssh/id_dsa debug1: Trying private key: /Users/softtimur/.ssh/id_ecdsa debug1: Trying private key: /Users/softtimur/.ssh/id_ed25519 debug1: No more authentication methods to try. root@xxx.xxx.xxx.xxx: Permission denied (publickey).

Weiß jemand, wie man das beheben kann?

Edit 1:

In meinem lokalen Mac curl ipecho.net/plain ; echokehrt zurück 175.169.13.102. Ich habe es geschafft, eine Konsole aus dem Droplet von Digital Ocean of A zu öffnen, dann habe ich es gemacht ssh-keygen, dann in der Konsole, was ich getan habe ssh-copy-id softtimur@175.169.13.102. Passwort wurde nicht gefragt.

Ich kann immer noch nicht glauben, dass ein Server Dateien auf meinen lokalen Mac schreiben kann, als ob mein lokaler Mac ein Server wäre ...

ssh: Erlaubnis verweigert (publickey)

0
Haben Sie auch den Befehl `ssh-copy-id` ausgeführt? nKn vor 6 Jahren 0
Nein, ich habe `ssh-copy-id` nicht versucht. Eigentlich bin ich verwirrt, ich weiß nicht, welcher / dessen Schlüssel auf dem Server und welcher / dessen Schlüssel in meinem lokalen Server sein sollte ... SoftTimur vor 6 Jahren 0
Private Schlüssel sollten immer auf dem Server verbleiben, der den Schlüssel generiert. Private Schlüssel sollten * niemals * geteilt werden. Wenn Sie "ssh-copy-id user @ host" ausführen und den Host durch den Server ersetzen, mit dem Sie eine Verbindung herstellen möchten, stellen Sie eine Verbindung mit dem anderen Server her und stellen den öffentlichen Schlüssel bereit, für den der gewöhnliche Schlüssel verwendet wird authentifizieren. nKn vor 6 Jahren 0

1 Antwort auf die Frage

1
nKn

Ein Beispiel für die Bereitstellung der Public-Key-Authentifizierungsmethode ist das Folgende. Angenommen, Sie haben Server A (den Server; den Server, zu dem Sie eine Verbindung herstellen möchten) und B (den Client; den Server, von dem Sie mit dem öffentlichen Schlüssel eine Verbindung zu A herstellen möchten ).

  1. Führen Sie auf A den folgenden Befehl aus:

    ssh-keygen

    • Dadurch wird ein Private-Public-Key-Paar generiert, wenn es ohne Argumente ausgeführt wird, erfolgt dies unter ~/.ssh.

  2. Auf A führe Folgendes aus:

    ssh-copy-id [user@]<Bs-IP-address>

    • Dadurch wird der von A generierte öffentliche Schlüssel nach B kopiert . Dies geschieht in einer Datei namens .~/.ssh/authorized_keys

    • Wenn dies aufgrund von Verbindungsproblemen nicht funktioniert oder Sie einfach keine Verbindung von Punkt A nach B herstellen können, gibt es eine alternative (manuelle) Möglichkeit, dies zu tun. Wechseln Sie in Ihrem Computer A zu Ihrem ~/.sshVerzeichnis und suchen Sie nach der Datei mit dem öffentlichen Schlüssel. Dies wird wahrscheinlich eine Datei mit der .pubErweiterung sein. Öffnen Sie es, kopieren Sie den Inhalt und fügen Sie ihn in B in Ihre ~/.ssh/authorized_keysDatei ein. Sehr wichtig : Diese Datei muss dem Benutzer gehören, die Gruppe muss der Benutzer sein und über Berechtigungen verfügen 600. Sonst funktioniert es nicht . Das ist so ziemlich was ssh-copy-id.

  3. Versuchen Sie von B aus, eine Verbindung von SSH zu A herzustellen .

Ein paar Dinge zu beachten:

  • Mit dem Befehl in Punkt 2 wird der öffentliche Schlüssel nur für den Remote-Benutzer bereitgestellt, zu dem Sie eine Verbindung herstellen. Das bedeutet, dass tomein Benutzer, dessen Benutzername jerrynicht verwendet werden kann, den Schlüssel nicht bei sich zu Hause bereitstellen kann. Kurz gesagt, die Bereitstellung erfolgt pro Benutzer.
  • Wenn Sie versuchen, den Schlüssel für die Verbindung zu A bereitzustellen root, stellen Sie sicher, dass die PermitRootLoginDirektive in /etc/ssh/sshd_configentweder den Wert yesoder prohibit-password(vorzugsweise) hat. Wenn auf festgelegt ist no, funktioniert die Authentifizierung mit öffentlichen Methoden nicht.
  • Teilen Sie niemals einen privaten Schlüssel mit jemandem.
Vielen Dank dafür ... Ich möchte nur klarstellen, dass ich von meinem lokalen Computer (** B ** in Ihrer Antwort?) Eine Verbindung zum Server (** A ** in Ihrer Antwort?) Herstellen möchte Ich bekomme '"? SoftTimur vor 6 Jahren 0
Ja, in meinem Fall ist ** A ** der Server und ** B ** der Client. Normalerweise läuft 'ifconfig' auf ** B ** und Sie können seine IP-Adresse sehen. nKn vor 6 Jahren 0
1) Stehen die `~ / .ssh / authorised_keys` in ** A ** oder ** B **? 2) In Schritt 2 kann ich immer noch nicht glauben, dass etwas auf meinen lokalen Computer geschrieben werden kann. Was ist, wenn mein Gerät ausgeschaltet ist, wenn Leute eine "ssh-copy-id" in ** A ** ausführen? SoftTimur vor 6 Jahren 0
1) Die Datei mit den autorisierten Schlüsseln sollte auf ** B ** stehen. Diese Schlüssel (Sie können beliebig viele haben) sind die, die zur Authentifizierung mit SSH über die Authentifizierung mit öffentlichen und privaten Schlüsseln verwendet werden. 2) `ssh-copy-id` verwendet das SSH-Protokoll zur Bereitstellung des Schlüssels. Deshalb ist die IP-Adresse von B notwendig. Sie werden aufgefordert, auch das Kennwort zu schreiben. Dies ist normal, da ** A ** nicht berechtigt ist, eine Verbindung zu ** B ** über die Methode der privaten und öffentlichen Authentifizierung herzustellen. Ja, Ihr Computer sollte beim Bereitstellen des Schlüssels online sein. nKn vor 6 Jahren 0
Bitte sehen Sie das Update meines OPs ... SoftTimur vor 6 Jahren 0
Das scheint ein Verbindungsproblem zu sein. Leiten Sie den Port "22 / TCP" an Ihren lokalen Computer in Ihrer Firewall weiter? Hat Ihr lokaler Maschinenport '22 / TCP' für diese Verbindung geöffnet? nKn vor 6 Jahren 0
Bitte sehen Sie sich meine Bearbeitung an, konkret Punkt 2. Ich habe eine manuelle Methode für die Bereitstellung des öffentlichen Schlüssels hinzugefügt. nKn vor 6 Jahren 0
Nochmals vielen Dank ... Ich habe es endlich geschafft, den öffentlichen Schlüssel von ** A ** in meine lokalen `.ssh / authorised_keys 'zu kopieren. Die Erlaubnis für die Datei lautet "600", der Benutzer ist "softtimur" und die Gruppe ist "staff", aber "ssh root @ xxx.xxx.xxx.xxx" gab erneut "Permission denied (publickey)" zurück. Soll ich die Gruppe der Datei ändern (auf was)? SoftTimur vor 6 Jahren 0
Weitere Informationen finden Sie unter "Ihr öffentlicher Schlüssel muss sich in der Datei authorized_keys auf Ihrem Droplet befinden ..." dieses Threads] (https://www.digitalocean.com/community/questions/error-permission-denied-publickey-when- i-try-to-ssh), deine Antwort und seine Antwort sind im Gegenteil ... SoftTimur vor 6 Jahren 0
Wir sagen genau dasselbe. In diesem Fall gehe ich davon aus, dass er versucht, sich von seinem Droplet auf seinem lokalen Computer zu authentifizieren, während Sie versuchen, das Gegenteil zu tun. Der öffentliche Schlüssel muss sich in den `Authorized_keys 'der Maschine befinden, die sich mit dem Server verbinden möchte, was er eigentlich sagt. Haben Sie geprüft, ob auf der Serverseite "PermitRootLogin" bis "verbot-password" oder "yes" vorhanden ist? nKn vor 6 Jahren 0

Verwandte Probleme