root bleibt bei verbindungsfehler eingeloggt

root bleibt bei verbindungsfehler eingeloggt (24 Beiträge, 215 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

hallo leute!

ich hab mich heut per putty mit meinem root zugang per sshv2 auf meinen FC3 rechner eingeloggt. jetzt hat aber das wlan einen kurzeb verbindungsabbruch gehabt, wodurch putty die verbindung als beendet angesehen hat. mein benutzer (root) war aber weiterhin am system eingeloggt.

kann jetzt zwar nicht mehr passieren da ich den timeout aktiviert habe aber meine frage:

1.) droht dadurch ein sicherheitsrisiko? - diese offen gelassene verbindung zu übernehmen dürfte ja nicht ganz so einfach sein, oder?

2.) wie werfe ich den benutzer aus dem system? - ssh bzw die zugehörige root-sheel killen hats ned wirklich gebracht

mfg sharky

Hi sharky!

Es gibt ja keine "offen gelassene" Verbindung.
So wie du das bescheibts, blieb einfach ein shell-Prozess hängen, wo über das Pseudo-tty einfach keinen IO mehr erfogt.

Mach mal einen:
# ps -fu root

und ermittle aus der Prozessliste deine(n) Prozess(e).
Jene Prozesse die noch eine tty-Zuordnung haben, kommen dabei in Frage.
Naja - und killen kannst diese ja auch problemlos.
Wenn der "kill" ohne Option nichts hilft, sende ihm die "-9" - Option.

Gruß!
Ingenico

ich hab einfach einen neustart gemacht, dann war das auch erledigt..

aber was ich mich erinnern kann wars laut pstree so:
sshd - bash - root

nachdem ich sshd komplett beendet hatte, war auch diese zeile laut pstree nicht mehr da.

allerdings war root laut "who" noch immer auf pts1 angemeldet.

ich hab einfach einen neustart gemacht, dann war das auch erledigt..

Meister! - das "tut man nicht"

Wenn du den sshd killst - hast du den Deamon gekillt.
Ich meinte, du sollst bloß die ssh-session killen, die bei deinem Verbindungs-Abbruch übrig blieb.

nana is ja nur mein heim rechner... da tut ein neustart nicht weh..

ich hab einfach alles gekillt was mit ssh bzw sshd zu tun hat

kann jetzt zwar nicht mehr passieren da ich den timeout aktiviert habe aber meine frage:

timeout - wie konkret, oder hab ich jetzt auf die schnelle einen Parameter übersehen?

Auf jeden Fall hat diese Methode - vor allem bei instabiler Verbindung - auch einen entscheidenden Nachteil: Jeder in der damit beendeten Session laufende Prozess (z.B. ein längerer Compilerlauf) wird damit auch beendet.

1.) droht dadurch ein sicherheitsrisiko? - diese offen gelassene verbindung zu übernehmen dürfte ja nicht ganz so einfach sein, oder?

Soweit ich weiß - Nein! - Zumindest sollte es nicht wesentlich einfacher sein, als die Verbindung zu übernehmen, ohne daß die Client-Seite der Verbindung stirbt.

2.) wie werfe ich den benutzer aus dem system? - ssh bzw die zugehörige root-sheel killen hats ned wirklich gebracht

Die zugehörige root-shell zu killen sollte eigentlich reichen; der zugehörige sshd Prozess stirbt dann eh von selbst.

Dein überzähliger Eintrag bei der Abfrage mittels 'who' könnte daher kommen, daß durchs killen des sshd Prozesses dieser Benutzer nie 'korrekt' abgemeldet (Die Ausgabe von 'who' ist auch nix anderes als ein aufbereitetes Log-File; wenn dort das Abmelden nicht vermerkt wurde, scheint der Benutzer noch angemeldet) wurde.

Jedenfalls konnte ichs damit nachvollziehen: Wenn ich den sshd kille, während die Session noch aktiv ist, dann hab ich danach auch noch eine Schein-Anmeldung auf dem jeweiligen pts; wenn ich die entsprechende shell kille, tritt das Problem nicht auf.

lg
mIstA

timeout - wie konkret, oder hab ich jetzt auf die schnelle einen Parameter
übersehen?

unter /etc/ssh/sshd_config die punkte
ClientAliveInterval 15
ClientAliveCount 3
setzen

dabei wird nach 15 sec inaktivität ein client-alive? packet gesendet.. wenns 3 mal nicht beantwortet wird, wird die session geschlossen

was die verbindung betrifft hab ich mir gedacht:
sollte die session noch offen sein, müsste ein neuer client ja die sequenznummern wissen um die packete richtig einzufügen bzw, da bin ich mir jetzt nicht ganz sicher wie das ssh macht, das "session passwort" falls nicht alles mit dem public key verschlüsselt wird.

was die "who" sache betrifft könntest du durchaus recht haben

unter /etc/ssh/sshd_config die punkte
ClientAliveInterval 15
ClientAliveCount 3

mag er bei mir nicht
Starting sshd:/etc/ssh/sshd_config: line 20: Bad configuration option: ClientAliveCount

I google, therefore I am
nico

schau mal in der man page nach... eventuell heißen die optionen bei deiner distri anders

shit jetzt hab ich den sshd restartet, er kommt nimma hoch und jetzt kann ich moni kabel umstecken

I google, therefore I am
nico

das kenn ich, aber so macht die netzwerktechnik doch richtig spass oder?

ja total

des schlimmste war aba mal /etc/rc.d/init/network stop
und dann hab i mi gewundert wieso ich im putty nix mehr tippen kann

I google, therefore I am
nico

auch eine möglichkeit sich auszusperren

aber solangs dir nicht so geht:
"ich kann meinen rechner pingen, ich weiß aber nicht wo er ist"

den eigenen rechner in der wohnung zu verlieren ist auch eine leistung *gg*

nette sache übrigens mit dem keyboard und dem nicht vorhandenen monitor

des schlimmste war aba mal /etc/rc.d/init/network stopund dann
hab i mi gewundert wieso ich im putty nix mehr tippen kann

Alter Indianer-Trick!
Wennst einen Ast absägst, ned drauf sitzen

lg
Ingenico

wahaaaa es owned so..

hab kbrd gnommen..
blind eingloggt und config file aufgerufen (alles ohne monitor)
zeile 20 gewählt - zeile 20 gelöscht - cgf gespeichert und sshd gestartet
undgeht wieder

I google, therefore I am
nico

hast eigentlich einen passenden eintrag für den timeout in der man page von sshd_config gefunden?

nope und i trau mi momentan nimma

I google, therefore I am
nico

such amal in da man page vielleicht findest ja was... und bevorsts ausprobierst machst dir halt zuästzlich einen telnet zugang auf.. dann kannsts per telnet wieder zrückstellen falls es nicht gehn sollte

unter /etc/ssh/sshd_config die punkte...

Aso, klar. - Dachte es gäbe eine Eintellung 'timeout' und ich hätt sie übersehen.

sollte die session noch offen sein, müsste ein neuer client ja die sequenznummern wissen um die packete richtig einzufügen bzw,

Also die Sequenznummern bieten da net wirklich Sicherheit; zur Not probier ich alle durch - nicht passende werden eh schon vom TCP/IP Stack verworfen.

Allerdings müßte der Angreifer den Session-Key knacken oder erraten; kann er das ist die Sicherheit von SSH eh ziemlich passe.

Außerdem müßte er die IP Deines Clients komplett 'übernehmen', weil er i.A. ja auch die Antworten an diese empfangen will; wer das schafft könnte Deinen Client auch ohne vorherigen Abbruch aus seiner Verbindung aussperren.

lg
mIstA

ja wie schon gesagt, ich war mir nicht mehr sicher obs einen eigenen session key gibt...

Sicherheitsrisiko entsteht dir keines, denn nach wie vor bräuchte der hijacker den schlüssel für die verbindung. (bei ssh wird über eine asymmetrisch verschlüsselte verbindung ein symmetrischer schlüssel ausgetauscht. anschließend wir nur mehr symmetrisch verschlüsselt)

Dies ist aber nach wie vor ein *extrem* schwieriges Unterfangen - egal ob die verbindung besteht oder nicht. Du brauchst dir also keine Sorgen zu machen.
-------------
Windows = a 64 bit rewrite for a 32 bit extension to a 16 bit GUI on an 8 bit OS written for a 4 bit architecture by a 2 bit company who can't stand 1 bit of competition.
-------------
AMD Athlon XP 3000+ @ 2166/166MHz (stock) | ASUS A7V8X | 1GB DDR-SDRAM | 410GB IDE (gesamt) | Sapphire Atlantis Radeon 9800 Pro @ stock | SB Audigy 2 ZS | Logitech Z-5300

also hab ichs doch richtig in erinnerung gehabt, zuerst asymmetrisch, dann symmetrisch, dann kanns mir ja egal sein...

außerdem betrifft sowieso nur mein heimnetz, übers internet ist der betroffene rechner sowieso nicht erreichbar

außerdem betrifft sowieso nur mein heimnetz, übers internet ist der betroffene rechner sowieso nicht erreichbar

Dann brauchst dir ja absolut keine Gedanken machen

-------------
Windows = a 64 bit rewrite for a 32 bit extension to a 16 bit GUI on an 8 bit OS written for a 4 bit architecture by a 2 bit company who can't stand 1 bit of competition.
-------------
AMD Athlon XP 3000+ @ 2166/166MHz (stock) | ASUS A7V8X | 1GB DDR-SDRAM | 410GB IDE (gesamt) | Sapphire Atlantis Radeon 9800 Pro @ stock | SB Audigy 2 ZS | Logitech Z-5300

was mein heimnetz betrifft natürlich nicht..

für mich als netzwerktechniker ists aber insofern wichtig, da es bei einem unternehmen ja nicht so unproblematisch ist wenn so ein sicherheitsloch bestehen würde.

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung