ssh fragt niemals nach einem Passwort

14

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

ssh password Alexis Wilke
quelle

17

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

ssh -o PubkeyAuthentication=no root@newserver

Klaus-Dieter Warzecha
quelle

Okay! Das hat funktioniert! Ich habe das "Gegenteil" ohne Erfolg versucht ... (dh -o PasswordAuthentication=yes). Aber das ist es, wonach ich gesucht habe.

Alexis Wilke

3

@AlexisWilke Ich bin froh, dass es funktioniert! Aber bitte lies auch Ollis Antwort. Er hat definitiv recht damit, dass mit deinem noch etwas nicht stimmt .ssh/config. Das -o PubkeyAuthentication=noist als dauerhafte Lösung nicht schön.

Klaus-Dieter Warzecha

Dieser Trick (-o PubkeyAuthentication = no) funktionierte gut auf einem Computer mit mehreren Identitätsdateien.

Valerio Schiavoni

17

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

Entfernen aller bis auf eine identityfileZeile oder
Hinzufügen PubkeyAuthentication nozu .ssh/configoder
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:

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

Olli
quelle

2

Aaah! Ich habe "zu viele" identifizierende Dateien und es werden 5 von ihnen überprüft und gestoppt. Ich habs! Das erklärt alles. Ich nehme an, ich sollte alle in einem Unterordner verschieben, damit sie nicht automatisch gefunden werden und die Passwortfunktion wieder automatisch funktioniert ...

Alexis Wilke

3

Wenn möglich, sollten / könnten Sie für jeden Dienst, den Sie benötigen, nur einen öffentlichen Schlüssel verwenden. Sehr selten gibt es einen Grund, es anders zu machen. Wenn jemand Ihren öffentlichen Schlüssel (Inhalt von authorized_keys) stiehlt , kann er damit nichts anfangen. Und wenn sich ohnehin alle Ihre privaten Schlüssel ( id_rsa/ id_dsa) auf demselben Computer befinden, spielt es keine Rolle, mehr als einen zu verwenden.

Olli

4

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.

Marc
quelle

1

Der andere Server ist ein brandneuer Server, und Sie werden dazu aufgefordert, genau das zu tun. Nicht nur das, mein Partner konnte sich problemlos einloggen! Auf meinem Computer ist etwas faul, was verhindert, dass er nach dem Kennwort sucht ... Wenn Sie sich die Protokolle ansehen, enthält die autorisierte Authentifizierung tatsächlich "Kennwort". Daher SOLLTE mich mein lokaler ssh-Client nach dem Passwort fragen, aber er beschließt, es zu überspringen.

Alexis Wilke

Es ist einfacher zu verstehen, warum der Server Sie nicht zur Eingabe eines Kennworts auffordert, als zu verstehen, warum Ihr Client Ihnen diese Option nicht bietet, wenn der Server dies anbietet. Es gibt viele Konfigurationsoptionen und nur wenige von Ihnen. Möglicherweise hat jemand mit Ihrer IP-Adresse zu oft versucht, sich ohne das richtige Kennwort anzumelden, und zukünftige Versuche Ihrer IP-Adresse wurden deaktiviert. Schieß, ich habe gerade Ollis Antwort gelesen. Das ist es.

Marc

ssh fragt niemals nach einem Passwort

Antworten: