freetz-devel-5210: ssh-Zugriff bei deaktiviertem PW-Login trotzdem mit PW möglich

ao · 12 Jul 2010

Hallo,

eben staunte ich, als ich nur mit dem Freetz-GUI Passwort (identisch zur passphrase des private rsa keys) und ohne public key ssh-Zugriff auf meine FB bekam, obwohl der ssh PW-Login deaktiviert ist.
Es kam lediglich diese Meldung:

Code:

login as: root
Server refused our key
root@[COLOR=Blue]fb1[/COLOR]'s password:

Und nach Eingabe des Freetz-GUI Passworts war ich drin.
Das scheint offenbar zu funktionieren, wenn man zwar einen private key angibt, der public key im dropbear GUI aber fehlt oder falsch eingetragen ist.
Ist das so gewollt (als Fallback) oder ein Fehler?

Noch etwas:
Die Meldung oben lautet eigentlich nicht "...fb1's...", sondern anstelle von "fb1" steht da meine öffentliche DynDNS-Adresse (habe ich hier mit "fb1" überschrieben).
War das schon immer so?

RalfFriedl · 12 Jul 2010

Das Fallback ist sicher gewollt. Nur weil Du einen Key hast, ist es nicht erstrebenswert, daß Du Dich auf keinem Server mehr anmelden kannst, auf dem diese Key nicht hinterlegt ist.

Statt dem "fb1" steht vermutlich der Host-Name, den Du beim SSH-Client angegeben hast.

olistudent · 12 Jul 2010

So ganz verstanden hab ich das jetzt nicht? Wenn du in Putty ein Keyfile angibst, in dropbear die Passwortauthentifizierung deaktivierst obwohl du keinen gültigen Key drin hast, dann kommt die Passwortabfrage? Dann macht die in meinen Augen auch Sinn, sonst könntest du dich ja gar nicht anmelden.

MfG Oliver

edit: Bei mir kommt kein Login, wenn ich kein Key auf der Box habe, aber den Passwort Login "verbiete":

Code:

Using username "root".
Server refused our key

und fertig

ao · 12 Jul 2010

Genau, und das "refused" kommt bei mir nicht mehr (wie "früher"). Seltsam...
Aber weshalb soll man die PW-Auth deaktivieren und nur Keys akzeptieren, wenn es das Fallback auf PW gibt?
Ich hatte gedacht, dass die Key-Auth ein Plus an Sicherheit sei, vor allem, wenn der Key selbst mit einer Passphrase geschützt ist.
So kann nur derjenige sich anmelden, der den Key und die Passphrase hat. Das ist doch sicherer als nur ein PW.
Oder sehe ich das alles falsch?
Wie auch immer: Ich hatte angenommen, dass "deaktiviert" eben auch so zu verstehen ist, also ohne Fallback.
Wenn man sich ausgesperrt hat, kann man doch immer noch (vor Ort) über das WebGUI rein.

olistudent · 12 Jul 2010

Hast du mein edit gelesen?

MfG Oliver

ao · 12 Jul 2010

Ja, habe ich. Und als ich oben schrieb, dass bei mir kein "refused" kommt, sondern die PW-Abfrage, war ich unterwegs, also remote ssh mit Key auf einem Stick.

Zu Hause sieht es (ohne Key auf der Box) aber so aus:

Code:

user@ubuntu-vm:~$ ssh fb1
Enter passphrase for key '/home/user/.ssh/ssh-2_rsa_private_open-ssh': 
Permission denied (publickey).

Das ist schon merkwürdig. Liegt es daran, dass auf meiner ubuntu-vm der Key abgelegt und die config wie folgt definiert ist?

Code:

user@ubuntu-vm:~/.ssh$ cat config 
Host fb1
    HostName fb1
    User root
    ServerAliveInterval 30
    ServerAliveCountMax 60
    IdentityFile ~/.ssh/ssh-2_rsa_private_open-ssh

RalfFriedl · 12 Jul 2010

ao schrieb:
obwohl der ssh PW-Login deaktiviert ist.

Was genau hast Du getan, um das zu deaktivieren?

olistudent · 12 Jul 2010

Wahrscheinlich lief der Daemon noch mit den alten Einstellungen wegen dem anderen (inetd) Problem?

MfG Oliver

ao · 13 Jul 2010

RalfFriedl schrieb:
Was genau hast Du getan, um das zu deaktivieren?

Den Haken im GUI gesetzt und Änderung übernommen:

Code:

Konfiguration speichern:
 Saving settings...done.
Saving dropbear.cfg...done.

Updating inetd config for dropbear: active.
Reloading inetd...done.

Writing /var/flash/freetz...done.
31232 bytes written.

Evtl. liegt es wirklich an inetd. Aber das Problem scheint ja nur von remote zu kommen.
Ich teste das später noch einmal (inetd vs. automatisch), wenn cuma einen Fix rausgebracht hat.

ao · 22 Jul 2010

Hallo, gibt es hierzu etwas Neues? (sorry, falls ich es übersehen habe)

olistudent · 22 Jul 2010

Hast du das Problem mit dem aktuellen Trunk immer noch? Ich hatte den Verdacht, dass durch einen Fehler in der modlibrc der dropbear nicht mit den im Webinterface gemachten/angezeigten Einstellungen gelaufen ist. Das sollte aber jetzt durch cuma behoben sein.

MfG Oliver

Languages

Suche

Languages

Suche

freetz-devel-5210: ssh-Zugriff bei deaktiviertem PW-Login trotzdem mit PW möglich

ao

Aktives Mitglied

RalfFriedl

IPPF-Urgestein

olistudent

IPPF-Urgestein

ao

Aktives Mitglied

olistudent

IPPF-Urgestein

ao

Aktives Mitglied

RalfFriedl

IPPF-Urgestein

olistudent

IPPF-Urgestein

ao

Aktives Mitglied

ao

Aktives Mitglied

olistudent

IPPF-Urgestein

Zurzeit aktive Besucher

Neueste Beiträge

Statistik des Forums