Re: SSH bricht ab
On 09.03.06 22:12:37, lars wrote:
> moin, andreas und liste,
> >>OpenSSH auf debian sarge (aso das per apt-get installierte aus testing)
> >
> >Also wohl eher Etch als Sarge.
>
> äähm - kleines missverständnis:
>
> - ursprünglich war unstable die quelle (beim installieren)
Nimms mir nicht uebel, aber unstable auf einem oeffentlich erreichbaren
Server zu fahren ist grob fahrlaessig, IMHO.
Weiterhin erklaert es wo dein Problem ist: In unstable ist "ssh" ein
Pseudo-Paket, beim apt-get purge ssh passiert gar nichts weiter (ausser
das das Paket aus der Liste der installierten Pakete entfernt wird).
openssh-server und openssh-client sind die Pakete die du purgen kannst
um die Konfig in /etc loszuwerden.
> - dann habe ich _testweise_ mal das ssh aus testing re-installiert, aber dann
> gab es keine konfigs mehr in /etc/ssh/.
Die Konfigs hast du selbst geloescht. Das Paket ssh enthaelt keine
Konfigs.
> jetzt habe ich die rsa- und dsa-keys neu erzeugt und den ssh einfach über
> /usr/bin/ aufgerufen - läuft, dh zugriff über beide NICs ist jetzt möglich.
> ohne änderungen an den NICs oder der fwall.
Dann wars evtl. deine sshd_config. Was wir nicht mehr nachpruefen
koennen. Was passiert bei einem apt-get --purge remove openssh-server
und anschliessendem apt-get install openssh-server? Danach solltest du
ja wieder das Problem haben, sofern du nicht an der Config rumgeschraubt
hast.
> >>eb, wenn ich mich von eth0 aus einloggen will; von eth1 aus geht es;
> >
> >Was soll das heissen? Hoert der sshd mal auf eth0 und mal auf eth1 oder
> >konfigurierst du den Client dass er mal ueber eth0 und mal ueber eth1
> >rausgeht?
>
> bisher konnte ich auch auf systemen mit mehreren NICs den ssh auf allen NICs
> erreichen, wenn ich die sshd-conf nicht grundlegend geändert habe.
Das konnte ich auch schon immer. Also hoerte der sshd auf 2 Interfaces?
Das wollte ich nur klaeren.
> >Wer Testing auf einem oeffentlichen Server installiert (und sei es nur
> >sshd) der sollte _sehr_ genau wissen was er tut.
>
> ich sag ja: testweise ...
Unstable ist besser? Ich glaube kaum.
> >>finde ich nichts, wo ich ansetzen könnte. DNS-problem...?
> >
> >Eventuell. Dann hast du also doch was wo du ansetzen koenntest. Wenn es
> >auf einem IF geht udn auf dem anderen nicht, dann solltest du erstmal
> >schauen wo genau der Unterschied zwischen beiden liegt.
>
> an dem "nicht funktionerenden" ist eine public IP, an dem "funktionierenden"
> eine aus RFC1918
> jetzt läuft der ssh über /usr/sbin/ssh und meine selbst gestrickte konfig und
> die manuell erzeugten keys, und die NICs sind nicht geändert.
Hmm, ich hab hier nur 3 private IP's (192.168.X.Y) und mein sshd hat
bisher keine Probleme gemacht.
> >>ich habe eine ssh-konfig out-of-the-box von debian genommen, und die
> >>funktionierte auch etwa zwei wochen lang.
> >
> >Was hat sich in der Zwischenzeit geaendert?
>
> apt-get update gemacht.
Ja wass denn nun? Updates gemacht oder nicht? apt-get update
aktualisiert nur die Paketliste.
> aber: vor zwei wochen habe ich mit debian sarge-cd 3.1 einen server ebenfalls
> mit zwei NICs und ssh out-of-the-box bzw. per apt aus unstable von
> ftp.debian.org installiert
Wieso ssh aus unstable?
> mit derselben cd und denselben apt-quellen habe ich vor ein paar tagen besagtes
> system aufgesetzt und ebenfalls lediglich den sshd-port geändert. heute habe
> ich den zugang über die zweite NIC versucht (und nix an der sshd_config
> geändert) - und konnte zwar auf den port zugreifen (der gedebugte sshd hat ja
> fleissig was gemeldet), aber bekam diese meldungen, mit denen ich nicht so
> recht was anfangen konnte.
Dann solltest du keine sshd's administrieren. Ich verstehe immernoch
nicht warum du den sshd aus unstable brauchst.
Du machst die Tests aber nicht rein zufaellig aus demselben Netz in dem
der Server steht oder? Das kann nicht funktionieren, jedenfalls nicht
ohne wilde Verrenkungen aufm Router.
> ich habe dann einen anderen clientrechner getestet mit demselben fehler.
Im selben Netz.
> jetzt habe ich *lediglich* den ssh reinstalliert und die konfigs gelöscht -
> und es geht wieder; nur leider nicht mit dem startscript aus /etc/init.d/ -
> aber klaro, wird schon irgendwie mein fehler sein ;-)
Ja. Es waere schon sehr merkwuerdig das das bei etlichen anderen Usern
funktioniert und bei dir nicht, weil was am sshd kaputt ist. Eher ist
dein Setup nicht in Ordnung. Da du uns weder deine Konfig noch ein
ausfuehrliches Log der Session vom Client aus zeigst ist das aber eh
alles Spekulation.
> ich hatte übrigens bereits des öfteren probleme mit dem ssh, sowohl server-
> wie auch client-seitig; aber wen es tröstet: meine kollegen, die putty und /
> oder ZOC auf windowsrechern benutzen, erleben auch ständig probleme mit den
> unterschiedlichen programmversionen client - server.
Ich hab leider nur einen stable-sshd und einen unstable-sshd, beide
haben bisher keinerlei Probleme gemacht (Linux+Win Client). Niemals.
> ich hätte nur ganz gern gewußt, wo der fehler im gezeigten ssh-dialog liegt
> bzw. wo er zu suchen gewesen sein könnte.
Ich hab da nur ein Problem gesehen: Die Public-Key-Authentifizierung ist
fehlgeschlagen. Mehr war nicht zu erkennen. Es war weder zu sehen ob das
die einzige Authentifizierungsmethode des Clients war, noch was der
Server dazu sagte (ausser diese komische Hostname-Meldung).
> nach ein paar jahren erfahrung mit windows, mac und linux bin ich aber
> mittlerweile zu der überzeugung gelangt, dass ich ohne einen gelegentlichen
> reboot der systeme die arbeit mit den kisten vergessen könnte - und da tun
> sich die linuxserver nur unwesentlich hervor.
Hmm, bei Desktops mag das sein, insbesondere sowas wie Mozilla oder OOo
moegen es wohl nicht zu lange zu laufen. Mein root-Server laeuft jetzt
71 Tage durch, natuerlich wird da nicht viel gemacht, der hat >1MB
Traffic am Tag... Ansonsten faellt mir noch Zope als Server-Prozess ein,
welcher regelmaessig neu gestartet werden sollte. Aber Rechner neu
starten?? Naja wenn du meinst...
> kleines beispiel: auf einem nameserver hatte ich heute ein defektes zonefile
> (falscher timestamp drin). nach einiger arbeit an dem nameserverdienst und den
> konfigs bzw. zonefiles habe ich den gesamten server neu gestartet, und das
> problem war verschwunden. ich habe es zwar auf der mailingliste der software
> gepostet, aber auch mal wieder gesehen, dass ein reboot effektiver sein kann
> als stundenlanges herumgefrickel - und dass er notwenig sein kann, wenn auch
> nicht bei 99,9% der kollegen hier, aber bei mir...
Und ein Dienst-Neustart hat nicht geholfen? Vllt. war auch einfach das
FS kaputt und er hat beim Reboot erstmal nen fsck gemacht?
Andreas
--
Your step will soil many countries.
Reply to: