Re: SSH bricht ab
moin andras,
- 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.
bisher bin ich gut damit gefahren.
stable ist nach meiner erfahrung in diversen bereichen nicht
ausreichend für bestimmte aufgaben; dann musste ich doch wieder auf
pakete aus unstable gehen und habe mir probleme mit den
unterschiedlichen abhängigkeiten eingehandelt.
die kombination "sarge mit paketen aus unstable" läuft bei mir seit
sarge veröffentlicht wurde auf bestimmt einem dutzend servern, nicht
nur zum testen, und bisher ist mir recht zufriedenstellend (ausnahmen
nerven, bestätigen aber die regel und treten nicht mehr oder weniger
häufig auf als bei woody z.b.)
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.
ok, das wusste ich nicht. danke für die info!
- 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.
das ursprünglich durchgeführte
apt-get install ssh
auf einem sargesystem mit unstable-sources installiert diese aber; und
i.d.r. läuft der kram damit - siehe oben.
Dann wars evtl. deine sshd_config. Was wir nicht mehr nachpruefen
koennen.
doch - ich habe nur das verzeichnis gelöscht, aber die konfig
gesichert.
allerdings entspricht die sshd_konfig einer default installation mit
drei änderungen:
Port 2222
AuthorizedKeysFile %h/.ssh/authorized_keys2
Banner /etc/issue.net
und dieselbe konfig läuft auf allen anderen rechern in unserem netz.
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.
richtig. hatte ich aber auch schon gecheckt, bevor ich meinen frust
hier abgelassen habe ;-)
ich sag ja: testweise ...
Unstable ist besser? Ich glaube kaum.
für mich: es _kann_ mehr.
Hmm, ich hab hier nur 3 private IP's (192.168.X.Y) und mein sshd hat
bisher keine Probleme gemacht.
dieses problem hatte ich bisher so auch noch nicht.
da ich ausser einer re-installation nichts an dem setting geändert
habe, bleibt nur ein fehler in einer der vielen zu ssh(d) gehörigen
dateien.
grobe unstimmigkeiten in der sshd_config sollte der sshd beim starten
bemängeln.
apt-get update gemacht.
Ja wass denn nun? Updates gemacht oder nicht? apt-get update
aktualisiert nur die Paketliste.
apt-get update ohne ein anschliessendes apt-get upgrade íst für mich
nur begrenzt sinnvoll; also: natürlich apt-get update && apt-get
upgrade
Wieso ssh aus unstable?
weil ich base-config bzw. tasksel immer sage, dass ich die pakete aus
unstable haben möchte.
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.
danke; also wirst du mir sicher die bedeutung dieser fehlermeldungen
erklären können ;-)
Ich verstehe immernoch
nicht warum du den sshd aus unstable brauchst.
es geht nicht um unstable des sshd wegen; s.o.
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.
da kann ich jetzt nicht folgen; dem sshd sollte es ziemlich egal sein,
von wo der aufruf erfolgt - oder meinst du, dass der server nicht
weiss, wohin er die antworten schicken soll...?
bisher habe ich connections ssh - sshd wild in und durch und über
alle(n) netze(n) betrieben, geforwarded, redirected - alles kein
problem.
die tests sind jetzt ja auch erfolgreich, nachdem ich ssh nicht mehr
über das initskript starte - so what?!
Ja. Es waere schon sehr merkwuerdig das das bei etlichen anderen Usern
funktioniert und bei dir nicht, weil was am sshd kaputt ist.
ich habe auffällig oft probleme mit sshd auf linuxsystemen; auf meinem
mac läuft ein sshd, der unauffällig seinen dienst tut (am rande:
spitzen-uptime des mac übrigens 3 wochen, dann macht er immer schlapp),
und auf windows habe ich sshd nur selten installiert bzw.
administriert.
ok, stress mit ssh habe ich vielleicht alle halbe jahre mal 8so wie
jetzt), aber wenn meine kaffeemaschine dermassen unzuverlässig liefe,
würde ich sie reklamieren.
Eher ist
dein Setup nicht in Ordnung. Da du uns weder deine Konfig
s.o.; im anhang die gesamte sshd-config
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,
linux auf dem desktop kenne ich nur von bildern in der ct ;-)
Mein root-Server laeuft jetzt
71 Tage durch,
süss.
meine uptimes sind in der regel bei 300 tagen; mit den neueren debian
sarges habe ich allerdings gleich mehrfach server neu starten müssen.
natuerlich wird da nicht viel gemacht, der hat >1MB
Traffic am Tag...
auch niedlich.
ich habe hier, wie gesagt, etwa ein dutzend server stehen, die nicht
ohne grund per gigabit am 4500er cisco angeschlossen sind.
und in letzter zeit häufen sich die probleme mit linux, was darauf
schliessen lässt, dass a) ich immer dümmer werde, b) immer unachtsamer
ob meines alters oder c) die systeme immer anfälliger.
Ansonsten faellt mir noch Zope als Server-Prozess ein,
welcher regelmaessig neu gestartet werden sollte. Aber Rechner neu
starten?? Naja wenn du meinst...
wie gesagt: ist nicht aus begeisterung am reboot .....
Und ein Dienst-Neustart hat nicht geholfen?
nein, hat nicht geholfen.
ich starte auch lieber einen dienst neu als einen server, schon allein,
damit meine windows-freudigen kollegen nicht wieder was zu meckern
haben.
Vllt. war auch einfach das
FS kaputt und er hat beim Reboot erstmal nen fsck gemacht?
ich habe nicht vor dem gerät gestanden beim boot, aber es war
verdächtig schnell wieder erreichbar, und die 180 tage für den nächsten
filesystemcheck waren ebenso wenig erreicht wie die anzahl der reboots.
gruss
lars
# Package generated configuration file
# See the sshd(8) manpage for details
Port 2222
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 768
SyslogFacility AUTH
LogLevel DEBUG2
LoginGraceTime 120
PermitRootLogin yes # testweise, sonst no
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys2
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
X11Forwarding yes
Banner /etc/issue.net
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes
Reply to: