ssh fragt niemals nach einem Passwort

Irgendwie möchte mein SSH mich nie nach einem Passwort fragen.

Also richte ich irgendwo auf der Welt einen VPS auf einem zufälligen Server ein und möchte mit ssh eine Verbindung dazu herstellen.

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

ssh -l some-user IP

Ich erhalte den Fehler:

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

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

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

SSH fragt mich jedoch nie nach dem Passwort. Es versucht 5 mal mit was ich vermute ist die publickey Methode und scheitert dann. Warum sollte ssh es nicht mit dem Passwort versuchen ?!

Nur für den Fall, meine ssh_config-Datei hat:

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

Versuchen Sie, sich mit deaktivierter Authentifizierung mit öffentlichem Schlüssel anzumelden

ssh -o PubkeyAuthentication=no root@newserver

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

Auch wenn Sie identityfileunter hostKonfiguration haben, wird es global angewendet. Dies bedeutet, dass sshjede Identitätsdatei (dh der öffentliche Schlüssel) auf jedem Host geprüft wird, bevor eine Aufforderung zur Kennworteingabe vom Server abgefragt wird.

Sie können dies beheben, indem Sie

1. Entfernen aller bis auf eine identityfileZeile oder
2. Hinzufügen PubkeyAuthentication nozu .ssh/configoder
3. Ausführen von ssh mit dem -o PubkeyAuthentication=noParameter.

Von 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 allen Servern, auf die der Client Zugriff haben soll, den passenden öffentlichen Schlüssel zuweisen. Mit anderen Worten, teilen Sie den öffentlichen Schlüssel zwischen den Servern und verwenden Sie niemals denselben privaten Schlüssel auf mehreren Geräten.
2. Generieren Sie immer ein Schlüsselpaar auf Ihrem Gerät und übertragen Sie nur den öffentlichen Schlüssel. Auf diese Weise ist Ihr privater Schlüssel auch dann sicher, wenn der Server kompromittiert wurde. Dies könnte auf überraschende Weise geschehen - zum Beispiel durch Backups.
3. Wenn eine andere Person den Server verwaltet, sollten Sie einen öffentlichen Schlüssel für sie bereitstellen. Sie sollten kein Schlüsselpaar generieren und keinen privaten Schlüssel an Sie senden. Auf diese Weise können sie sich nicht mit Ihrem Schlüssel ausgeben (normalerweise können sie natürlich tun, was sie wollen). Außerdem muss beim öffentlichen Schlüssel nur die Integrität (dh, jemand hat den öffentlichen Schlüssel nicht geändert) geschützt werden. Mit privatem Schlüssel muss die Vertraulichkeit gewahrt werden (dh niemand hat den Schlüssel erhalten), und es ist nicht möglich, absolut sicher zu sein, dass er nicht kompromittiert wurde.
4. Wenn Sie einen Server kompromittieren, werden andere Server nicht kompromittiert, auch wenn Sie denselben privaten Schlüssel für die Verbindung mit mehreren Servern verwenden (es sei denn, Sie haben diesen privaten Schlüssel an den Server übertragen. Tun Sie dies niemals.)
5. Wenn Sie Ihre Workstation kompromittieren, werden Ihre privaten Schlüssel ohnehin freigelegt. Es hilft nicht, mehrere private Schlüssel zu haben (es sei denn, Sie haben unterschiedliche, starke Passphrasen und nicht alle sind für Angreifer verfügbar).

Es gibt einige Ausnahmen, aber nicht zu viele.

Ihr lokaler SSH sollte Sie nicht nach einem Passwort fragen, der SSH-Server am anderen Ende sollte dies tun. Es ist wahrscheinlich, dass der Server so eingerichtet ist, dass die Kennwortauthentifizierung nicht akzeptiert wird. Meins würde Sie auch nicht nach einem Passwort fragen.