☰

ssh fragt nie nach einem Passwort

tag-icon • tag-icon ssh password
ssh fragt nie nach einem Passwort

Aus irgendeinem Grund fragt mich mein SSH nie nach einem Passwort.

Ich richte also einen VPS auf einem beliebigen Server irgendwo auf der Welt ein und möchte per SSH eine Verbindung dazu herstellen.

Ich kann einen Schlüssel einrichten, aber wenn ich dies tue:

ssh -l some-user IP

Ich erhalte die Fehlermeldung:

Received disconnect from ##.##.##.##: 2: Too many authentication failures for some-user

Wenn ich mir die Details ansehe, sehe ich, dass „Passwort“ eine der Optionen ist:

debug1: Offering RSA public key: some-user@computer
debug1: Authentications that can continue: publickey,password

Dennoch fragt mich SSH nie nach dem Passwort. Es versucht es fünfmal mit einer Methode, von der ich annehme, dass es die Publickey-Methode ist, und schlägt dann fehl. Warum versucht es SSH nicht mit dem Passwort?!

Nur für den Fall, meine ssh_config-Datei enthält:

PasswordAuthentication yes

Vollständiges Protokoll

ssh -v -l root ##.##.##.##
OpenSSH_6.1p1 Debian-4, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /home/someuser/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to ##.##.##.## [##.##.##.##] port 22.
debug1: Connection established.
debug1: identity file /home/someuser/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/someuser/.ssh/id_rsa-cert type -1
debug1: identity file /home/someuser/.ssh/id_dsa type -1
debug1: identity file /home/someuser/.ssh/id_dsa-cert type -1
debug1: identity file /home/someuser/.ssh/id_ecdsa type -1
debug1: identity file /home/someuser/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.2p2 Ubuntu-6
debug1: match: OpenSSH_6.2p2 Ubuntu-6 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.1p1 Debian-4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA XX:XX:...:XX:XX
debug1: Host '##.##.##.##' is known and matches the ECDSA host key.
debug1: Found key in /home/someuser/.ssh/known_hosts:38
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/someuser/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: someuser@computer
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: someuser@computer
debug1: Authentications that can continue: publickey,password
debug1: Offering DSA public key: someuser@computer
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: someuser@computer
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: someuser@computer
Received disconnect from ##.##.##.##: 2: Too many authentication failures for root

Antwort1

Versuchen Sie, sich mit deaktivierter Public Key-Authentifizierung anzumelden, mit

ssh -o PubkeyAuthentication=no root@newserver

Antwort2

Höchstwahrscheinlich enthält identityfileIhre .ssh/configDatei mehr als eine Zeile.

Auch wenn Sie eine identityfilesolche hostKonfiguration haben, wird sie global angewendet. Das bedeutet, dass sshjede Identitätsdatei (also jeder öffentliche Schlüssel) auf jedem Host ausprobiert wird, bevor der Server nach einem Passwort gefragt wird.

Sie können dieses Problem beheben, indem Sie

  1. Alle identityfileZeilen bis auf eine entfernen, oder
  2. Hinzufügen PubkeyAuthentication nozu .ssh/configoder
  3. SSH mit -o PubkeyAuthentication=noParameter ausführen.

Aus man 5 ssh_config:

PubkeyAuthentication
    Specifies whether to try public key authentication.  The argument to this
    keyword must be “yes” or “no”.  The default is “yes”.  This option applies 
    to protocol version 2 only.

IdentityFile
    ...
    It is possible to have multiple identity files specified in configuration
    files; all these identities will be tried in sequence.  Multiple 
    IdentityFile directives will add to the list of identities tried (this 
    behaviour differs from that of other configuration directives).

Einige allgemeine Anweisungen mit öffentlichen Schlüsseln:

  1. Im Allgemeinen sollten Sie nur einen einzigen privaten Schlüssel pro Client (Arbeitsstation) haben und den passenden öffentlichen Schlüssel auf allen Servern hinterlegen, auf die der Client Zugriff haben soll. Mit anderen Worten: Geben Sie den öffentlichen Schlüssel für mehrere Server frei und verwenden Sie niemals denselben privaten Schlüssel auf mehreren Geräten.
  2. Generieren Sie Schlüsselpaare immer auf Ihrem Gerät und übertragen Sie nur den öffentlichen Schlüssel. Auf diese Weise ist Ihr privater Schlüssel auch bei einem Angriff auf den Server sicher und geschützt. Dies kann auf überraschende Weise passieren – beispielsweise durch Backups.
  3. Wenn jemand anderes den Server verwaltet,Dusollten ihnen einen öffentlichen Schlüssel zur Verfügung stellen; sie solltennichtSchlüsselpaar generieren und Ihnen den privaten Schlüssel senden. Auf diese Weise können sie sich nicht mit Ihrem Schlüssel als Sie ausgeben (natürlich können sie normalerweise tun, was sie wollen). Außerdem muss bei einem öffentlichen Schlüssel nur die Integrität geschützt werden (d. h., jemand hat den öffentlichen Schlüssel nicht geändert); bei einem privaten Schlüssel muss die Vertraulichkeit geschützt werden (d. h., niemand sonst hat den Schlüssel erhalten) und es ist nicht möglich, absolut sicher zu sein, dass er nicht kompromittiert wurde.
  4. Die Kompromittierung eines Servers führt nicht zur Kompromittierung anderer Server, selbst wenn Sie für die Verbindung mit mehreren Servern denselben privaten Schlüssel verwenden (außer wenn Sie diesen privaten Schlüssel an den Server übermittelt haben. Tun Sie das niemals).
  5. Wenn Ihre Workstation kompromittiert wird, werden Ihre privaten Schlüssel ohnehin offengelegt. Mehrere private Schlüssel helfen dabei nicht (außer wenn Sie unterschiedliche, starke Passphrasen haben und nicht alle davon für Angreifer verfügbar sind).

Es gibt einige Ausnahmen, aber nicht zu viele.

Antwort3

Ihr lokales SSH sollte Sie nicht nach einem Passwort fragen, der SSH-Server am anderen Ende schon. Wahrscheinlich ist der Server so eingestellt, dass er keine Passwortauthentifizierung akzeptiert. Meins würde Sie auch nicht nach einem Passwort fragen.

Antwort4

Eine weitere Ursache habe ich gefunden. Ich hatte:

Host *
   PreferredAuthentications publickey

in ~/.ssh/config(von einem anderen Benutzer kopiert, da ich dachte, es sei „Präferenz“). PreferredAuthenticationsGibt tatsächlich „zulässige“ Methoden und Reihenfolge an.

Löschen Sie entweder die PreferredAuthenticationsZeile oder fügen Sie sie hinzupassword

Host *
   PreferredAuthentications publickey,password

Achtung: Nach dem Komma kein Leerzeichen!

verwandte Informationen