Ist mein Passwort kompromittiert, weil ich vergessen habe, nach dem SSH-Benutzernamen die Eingabetaste zu drücken?

Ich habe gerade versucht, mich mit SSH (PuTTY, Windows) auf einem Fedora- Server (Version 13 Goddard) anzumelden. Aus irgendeinem Grund ging Entermein Benutzername nach der Eingabe nicht durch und ich gab mein Passwort ein und drück erneut die Eingabetaste. Ich habe meinen Fehler erst gemerkt, als der Server mich mit einem fröhlichen Gruß begrüßte

Das Passwort von myusername MYPASSWORD @ server.example.com:

Zu diesem Zeitpunkt habe ich die Verbindung abgebrochen und mein Kennwort auf diesem Computer geändert (über eine separate SSH-Verbindung).

... jetzt ist meine Frage: Wird solch ein fehlgeschlagenes Login in einer Logdatei im Klartext gespeichert? Mit anderen Worten, habe ich gerade mein (inzwischen veraltetes) Passwort vor die Augen des Remote-Administrators gezwungen, wenn er das nächste Mal seine Protokolle scannt?

Aktualisieren

Vielen Dank für alle Kommentare zu der implizierten Frage "Was tun, um dies in Zukunft zu verhindern?". Für schnelle, einmalige Verbindungen verwende ich jetzt diese PuTTY-Funktion:

um die Option "Benutzername automatisch anmelden" zu ersetzen

Ich werde auch häufiger mit der Verwendung von ssh-Schlüsseln beginnen, wie in den PuTTY-Dokumenten erläutert .

Kurzum: ja.

# ssh 192.168.1.1 -l "myuser mypassword"
^C
# egrep "mypassword" /var/log/auth.log
Oct 19 14:33:58 host sshd[19787]: Invalid user myuser mypassword from 192.168.111.78
Oct 19 14:33:58 host sshd[19787]: Failed none for invalid user myuser mypassword from 192.168.111.78 port 53030 ssh2

Wenn ich mich gut erinnere, wird es in der Tat im Protokoll registriert, wenn die Protokollstufe auf DEBUG oder TRACE gesetzt ist.

BEARBEITEN: Es wurde bestätigt, dass ich versucht habe, mich auf meinem Server anzumelden, und dies in meinen Protokollen gefunden habe.

Oct 19 14:34:24 sd-xxxx sshd[26563]: pam_unix(sshd:auth): authentication failure; logname=     uid=0 euid=0 tty=ssh ruser= rhost=xxx-xxx-xxx-xxx.rev.numericable.fr 
Oct 19 14:34:26 sd-xxxx sshd[26563]: Failed password for invalid user toto from xxx.xxx.xxx.xxx port 56685 ssh2

Hinweis: IPs sind ausgeblendet

Oder für zusätzliche Sicherheit und Bequemlichkeit sollten Sie wirklich darüber nachdenken, SSH-Schlüssel einzurichten ...

# ssh-keyget -t rsa
(Akzeptiere alle Standardeinstellungen)

und du bekommst ...

~ / .ssh / id_rsa
~ / .ssh / id_rsa.pub

Randnotiz: Sie können Ihre Schlüsseldateien umbenennen, wenn Sie ~ / .ssh / config mit so etwas wie dem folgenden Inhalt hinzufügen:

# cat ~ / .ssh / config
Gastgeber *
IdentityFile ~ / .ssh / ddopson_employer_id_rsa

Cat den Inhalt Ihres öffentlichen Schlüssels (wird eine einzelne Zeile sein):

# cat ~ / .ssh / id_dsa.pub
ssh-rsa AAAAB3NzaC1kc3MAAACBAOOVBqYHAMQ8J ... BbCGGaeBpcqlALYvA == ddopson @ hostname

Melden Sie sich jetzt in der Zielbox an und fügen Sie diese Zeile in ~ / .ssh / authorized_keys ein.

Randnotiz: Die Pubkey-Zeile endet in einer vom Menschen lesbaren Zeichenfolge wie "ddopson @ hostname". Sie können dies ändern, um den von Ihnen verwendeten Schlüssel genauer zu beschreiben (z. B. wenn Sie viele Schlüssel haben). Diese Zeichenfolge wird NICHT als Teil der Authentifizierung verwendet und dient nur zur Beschreibung des Schlüssels für andere Menschen.

Das ist es. Wenn Sie jetzt zum Host senden, werden Sie nicht einmal zur Eingabe eines Kennworts aufgefordert.

Wenn Sie Bedenken haben, Ihren privaten Schlüssel (id_rsa) zu speichern, können Sie dem Schlüssel selbst eine Passphrase hinzufügen (siehe ssh-keygen), um ihn vor der Verwendung durch jeden zu schützen, der Zugriff auf Ihre Dateien hat. Anschließend können Sie den Schlüssel mit ssh-agent entschlüsseln und sicher im Speicher ablegen, damit er für mehrere SSH-Verbindungen verwendet werden kann.

Das Passwort wurde bei der Übertragung verschlüsselt. Ja, es ist möglich, dass Ihr Kennwort kompromittiert wurde, weil es im Protokoll auf dem Zielserver gedruckt wurde. Ich würde jedoch auch sagen, dass jedes Mal, wenn Sie Ihr Kennwort auf Ihrem Computer eingeben, eine Gefährdung eintreten kann, da sich auf Ihrem Computer möglicherweise Spyware-Software oder ein an Ihren Computer angeschlossener Keylogger befindet.

Wenn Sie der einzige Administrator dieses Systems sind und der Meinung sind, dass dieses System nicht kompromittiert wurde, können Sie mit relativer Sicherheit davon ausgehen, dass Ihr Kennwort nicht kompromittiert wurde, so wie Sie normalerweise davon ausgehen, dass sich auf Ihrem Computer keine Spyware befindet, weil Sie dies nicht getan haben erlebte etwas Verdächtiges. Sie können das Protokoll auf diesem Server bearbeiten und den Verweis auf Ihr Kennwort entfernen.

Dieser Vorfall ist ein Grund, warum die Verwendung von SSH-Schlüsseln anstelle von Kennwörtern besser ist. Selbst wenn jemand das Kennwort erhält, das Sie auf Ihrem Computer eingegeben haben, um den privaten Schlüssel auf Ihrem Computer zu entschlüsseln, kann er dennoch nicht auf den Remote-Server zugreifen. Sie benötigen auch die private Schlüsseldatei. Sicherheit dreht sich alles um Schichten. Nichts ist perfekt, aber wenn Sie genügend Ebenen hinzufügen, ist es schwierig genug, dass der Angreifer einfach weitergeht, oder Sie fangen sie, weil es länger dauert.

Ich würde das oben genannte nicht tun, wenn Ihr Passwort sehr vertrauliche Informationen oder kritische Ressourcen schützt. Es hängt davon ab, wie vertraulich Ihr Passwort ist.