Mal eine dumme frage (ssh)

[hanseknight]

Ich bekomme in den letzten Tagen immer folgende fehlermeldung :

"Aug 2 00:45:03 server-project sshd[684]: error: Could not get shadow information for NOUSER"

Kann damit jemand was anfangen, die Meldung ist fast täglich in meinem error log

Gruß Tim

[dodolin]

Vermutlich gibts den User in /etc/passwd, dort steht, dass sein PW in /etc/shadow steht, aber dort steht nix. ?

[floschi]

Ist bei mir seit einigen Tagen genauso, evtl. liegt das mit irgendeinem Update zusammen? Welche Distri hast du?

[dodolin]

Ist bei mir seit einigen Tagen genauso, evtl. liegt das mit irgendeinem Update zusammen?

Hm... mal ne dumme Frage am Rande: Führt ihr denn kein Log darüber, wann ihr welches Update macht? Damit ließen sich ja nämlich solche Fehler (sofern sie denn vom Update herrühren) zurückverfolgen bzw. auf wenige Pakete/Updates einschränken.

PS: Bei mir sorgt da apt-listchanges automatisch dafür. ;)

[thorsten]

Das hängt nicht mit einem Update zusammen, das finde ich auf woody wie auf sarge Rechnern.
Auf bugtraq habe ich auch davon gelesen und die Fehlermeldung bei google eingegeben listet dir massig Treffer (auf allen Disributionen sowie *BSD und solaris)
Sorg einfach dafür, dass dein sshd aktuell ist, dazu würde ich natürlich root keinen direkten Login erlauben, aber das ist ja Standard :)

[odysseus]

Ich hab das auf Suse 9.1 (64 Bit) auch gelegentlich mal. Stört aber nicht.

[hanseknight]

Ich hab den Server erst seit 2 wochen, 4-5 Updates habe ich eingepflegt. Aber ein Update Log habe ich noch nicht.

Ich hab Suse 9.1

[Joe User]

http://www.google.com/search?hl=en&ie=U ... gle+Search

[niemand]

Es ist mir auch aufgefallen, dass es in den letzten Tagen/Wochen vermehrt Loginversuche über ssh gibt. Ã?berwiegend wird versucht, auf die User "test" und "guest" zuzugreifen, seltener "root", oder "admin". Scheint eine Art Wurm oder ein neues Spielzeug unserer geliebten Scriptkiddies zu sein. Außer, dass es die Logs zumüllt, scheint es harmlos zu sein.

cu

[captaincrunch]

Liest hier niemand Mailinglisten o.ä.?

Ausgangspost: http://lists.netsys.com/pipermail/full- ... 24340.html
Interessant dabei: http://lists.netsys.com/pipermail/full- ... 24478.html

[niemand]

Liest hier niemand Mailinglisten o.ä.?

Welche von den etwa 27.000 bekanntesten sind denn die, mit denen man alles abdeckt? ;)

Mal ernsthaft: Ich habe etwa 6 für dieses Thema abonniert, in keiner wurde das Problem ernsthaft aufgegriffen. Thx 4 link.

cu

[floschi]

Liest hier niemand Mailinglisten o.ä.?

Nun, nachdem wir hier ja genug Leute haben, die das von Berufswegen tun müssen, mache ich mir wegen solchen Sachen nicht die Arbeit, jede Liste zu lesen und beschränke mich auf die Basics - eine Risikoabwägung ;)

Aber es ist gut zu wissen, dass diejenigen, die das alles lesen, sich hier auch mit dem Wissen bei Bedarf melden. Thx

[Joe User]

Ebenfalls lesenswert:
http://lists.netsys.com/pipermail/full- ... 24544.html
http://lists.netsys.com/pipermail/full- ... 24557.html

[nyxus]

In diesem Zusammenhang: Wie sicher ist eigentlich die "Shell" /bin/false?

Wenn ich jetzt einen User "test" mit password "test" hätte, dieser aber obige Shell hätte, gäbe es dann Möglichkeiten für den Angreifer trotzdem weiterzukommen? Mal angenommen auf dem System sind keine weiteren Dienste die mit diesem Account genutzt werden könnten.

[captaincrunch]

Exploits und Buffer Overflows scheren sich herzlich wenig um die Login-Shell eines Users. ;)

[nyxus]

Exploits und Buffer Overflows scheren sich herzlich wenig um die Login-Shell eines Users. ;)

ok, wenn sowas da ist und schon bei der Userüberprüfung ausgenutzt werden kann dann ist es natürlich vorbei (egal welche Shell der User hat). Aber ich interpretiere die Antwort mal so, daß Du zumindest auch keine Schwäche von /bin/false kennst um die man sich Sorgen machen müßte?

[captaincrunch]

/bin/false an sich ist im Normalfall schon eine recht gute Maßnahme, mir selbst wäre (außer den bereits genannten Dingen) nichts bekannt, wie sich das umgehen ließe .