ubuntuusers.de

ssh-Anmeldung nach 2FA Einrichtung nicht mehr möglich: "debug3: receive packet: type 51"

Status: Gelöst | Ubuntu-Version: Kubuntu 20.04 (Focal Fossa)
Antworten |

colombo1980

Avatar von colombo1980

Anmeldungsdatum:
23. September 2008

Beiträge: 1294

Hallo, ich dachte zunächst es wäre ein sshfs-Problem und habe deshalb einen Thread mit einem falschen Titel (https://forum.ubuntuusers.de/topic/nutzung-von-sshfs-mit-2fa-keine-anmeldung-moeg/#post-9274449) aufgemacht. Es scheint aber ein generelles ssh Problem bei mir zu sein. Deshalb dieser neue Thread.

Problem: Ich habe neuerdings 2FA (mit Google Authenticator) eingerichtet (vorher hat alles problemlos funktioniert) und kann mich als User mit Systemverwalterechten (nennen wir ihn "admin") auch immer noch auf meinem Raspberry Pi problemlos einloggen: mit Passwort plus zweitem Faktor. Als eingeschränkter User (nennen wir ihn "user") kann ich dies leider nicht. Ich erhalte lediglich eine 3-malige "Password:" Abfrage, gefolgt von einer "user@meinserver.de's password:"-Abfrage, gefolgt von einem connection closed:

$ ssh -p 1234 user@meinserver.de
Password: 
Password: 
Password: 
user@meinserver.de's password: 
Connection closed by 184.82.106.0 port 1234

Ich habe nun auch mal -vvv versucht und beide User verglichen. Beim User admin bekomme ich nach dem Passwort ein "debug3: receive packet: type 60" und es geht mit dem Verification Code weiter. Beim User "user" erhalte ich nach dem Passwort ein "debug3: receive packet: type 51" und es nimmt dann einen anderen Lauf. Ich kann hiermit aber nichts anfangen, dafür verstehe ich zu wenig von der Materie. Beide Ausschnitte poste ich hier, einmal als Admin:

$ ssh -vvv -p 1234 admin@meinserver.de
[...]
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/felix/.ssh/id_rsa
debug3: no such identity: /home/felix/.ssh/id_rsa: No such file or directory
debug1: Trying private key: /home/felix/.ssh/id_dsa
debug3: no such identity: /home/felix/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/felix/.ssh/id_ecdsa
debug3: no such identity: /home/felix/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /home/felix/.ssh/id_ecdsa_sk
debug3: no such identity: /home/felix/.ssh/id_ecdsa_sk: No such file or directory
debug1: Trying private key: /home/felix/.ssh/id_ed25519
debug3: no such identity: /home/felix/.ssh/id_ed25519: No such file or directory
debug1: Trying private key: /home/felix/.ssh/id_ed25519_sk
debug3: no such identity: /home/felix/.ssh/id_ed25519_sk: No such file or directory
debug1: Trying private key: /home/felix/.ssh/id_xmss
debug3: no such identity: /home/felix/.ssh/id_xmss: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug3: send packet: type 50
debug2: we sent a keyboard-interactive packet, wait for reply
debug3: receive packet: type 60
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password: 
debug3: send packet: type 61
debug3: receive packet: type 60
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Verification code: 
debug3: send packet: type 61
debug3: receive packet: type 60
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 0
debug3: send packet: type 61
debug3: receive packet: type 52
debug1: Authentication succeeded (keyboard-interactive).
[...]

... und einmal als user:

$ ssh -vvv -p 1234 user@meinserver.de
[...]
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/felix/.ssh/id_rsa
debug3: no such identity: /home/felix/.ssh/id_rsa: No such file or directory
debug1: Trying private key: /home/felix/.ssh/id_dsa
debug3: no such identity: /home/felix/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/felix/.ssh/id_ecdsa
debug3: no such identity: /home/felix/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /home/felix/.ssh/id_ecdsa_sk
debug3: no such identity: /home/felix/.ssh/id_ecdsa_sk: No such file or directory
debug1: Trying private key: /home/felix/.ssh/id_ed25519
debug3: no such identity: /home/felix/.ssh/id_ed25519: No such file or directory
debug1: Trying private key: /home/felix/.ssh/id_ed25519_sk
debug3: no such identity: /home/felix/.ssh/id_ed25519_sk: No such file or directory
debug1: Trying private key: /home/felix/.ssh/id_xmss
debug3: no such identity: /home/felix/.ssh/id_xmss: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug3: send packet: type 50
debug2: we sent a keyboard-interactive packet, wait for reply
debug3: receive packet: type 60
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password: 
debug3: send packet: type 61
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug2: userauth_kbdint
debug3: send packet: type 50
debug2: we sent a keyboard-interactive packet, wait for reply
debug3: receive packet: type 60
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password: 
debug3: send packet: type 61
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug2: userauth_kbdint
debug3: send packet: type 50
debug2: we sent a keyboard-interactive packet, wait for reply
debug3: receive packet: type 60
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password: 
debug3: send packet: type 61
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: 
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
user@meinserver.de's password: 
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
Connection closed by 184.82.106.0 port 1234

Das Passwort muss eigentlich richtig sein. Bin mir 100% sicher. Wer hat eine Idee und kann helfen? Welche Infos kann ich noch liefern?

colombo1980

(Themenstarter)
Avatar von colombo1980

Anmeldungsdatum:
23. September 2008

Beiträge: 1294

Ich löse selbst: nach vielen Stunden habe ich durch Blick in die "var/log/auth.log" (?) auf dem Server herausgefunden, dass ich für den User "user" noch nicht "google-authenticator" ausgeführt hatte, der User also noch keine ".google_authenticator" o.ä. in seinem Home Verzeichnis hatte...

frostschutz

Avatar von frostschutz

Anmeldungsdatum:
18. November 2010

Beiträge: 7790

Willst du dich von fremden Systemen ohne SSH-Keys einloggen können oder wofür braucht man das eigentlich?

Werden wiederholte Loginversuche gesperrt oder muss mans einfach nur lange genug probieren bis mal zufällig das 2FA Token gezogen wird?

colombo1980

(Themenstarter)
Avatar von colombo1980

Anmeldungsdatum:
23. September 2008

Beiträge: 1294

das ist mein erster raspberry / Server, hatte noch nie sowas gemacht und da habe ich mich gegen SSH keys entschieden, um nicht auf bestimmte Geräte beschränkt zu sein. ich denke auch immer noch, dass es mich flexibler macht, sollte mal was kaputt gehen (wie mein laptop zufälligerweise vor 2 Wochen). Nur Passwort ist aber auch nicht das Gelbe vom Ei, also schien mir 2FA ziemlich genau zu sein, was ich möchte.

Und deine 2te Frage, nein das 2FA Token wurde nie angefordert, weil keine .google_authenticator Datei existierte. Das hätte nie funktionieren können. Ob diese Versuche von fail2ban erkannt wurden, habe ich jetzt gar nicht explizit nachgeschaut, aber ich denke schon, denn ja, es gab eine zeitliche Sperre bevor wieder ein neuer Versuch möglich war.

Antworten |