Re: SSH bricht ab
moin, andreas und liste,
ok, problem nicht gelöst, aber umgangen.
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)
- dann habe ich _testweise_ mal das ssh aus testing re-installiert,
aber dann gab es keine konfigs mehr in /etc/ssh/.
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.
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.
Mar 9 18:45:30 iis2 sshd[4047]: Connection from 217.91.25.239 port
42779
Mar 9 18:45:30 iis2 sshd[4047]: debug1: Client protocol version 2.0;
client
software version OpenSSH_4.2p1 Debian-5
Das ist ein altes Testing, jedenfalls ist ssh in Sarge -4 und nicht -5.
Mar 9 18:45:30 iis2 sshd[4047]: debug1: Local version string
SSH-2.0-OpenSSH_4.2p1 Debian-7
Und das ist ebenfalls ein testing-Server.
Wer Testing auf einem oeffentlichen Server installiert (und sei es nur
sshd) der sollte _sehr_ genau wissen was er tut.
ich sag ja: testweise ...
Permission denied (publickey).
Wenn ich das richtig deute wird eine Pub-Key authentifizierung
versucht.
Kannst du vllt. mal auf dem Client die Verbose-Option einschalten.
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.
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.
?? Was kann Debian fuer deine Fehler?
naja ...
ok, das mit dem ssh-verzeichnis war nicht ganz ernst gemeint.
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 - an der sshd_config habe ich
lediglich den port geändert. login von den systemen aus, mit denen ich
jetzt probleme habe, problemlos möglich.
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.
ich habe dann einen anderen clientrechner getestet mit demselben fehler.
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 ;-)
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 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 habe es mit der hand gelöscht,
Sowas macht man nicht, wenn dann benennt man sowas um.
bzw. verschiebt es irgendwohin. da ich - siehe oben - immer ähnliche
settings benutze, kopiere ich mir sonst auch gerne mal ein konfig-file
von einem anderen server.
den server neu gestartet
Wozu sowas?
ich vermeide es auch gern und bin nach wie vor stolz auf einen meiner
ersten linuxserver, den ich unefähr 2001 aufgesetzt habe und der
irgendwann eine uptime von 900 tagen gemeldet hat.
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.
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 ssh- aus testing neu installiert
Ach dann ist obiges ssh doch aus Sarge? Wage ich ein wenig zu
bezweifeln, denn dann waere /etc/ssh definitiv weg (grad getestet). Und
wenn das bei dir nicht passiert ist hat sich apt-get bestimmt gemeldet.
nein, definitiv nicht. es sei denn, dass alle syslogs auf stdout
gegangen sind bis auf diese ... ;-)
danke und gruss
lars
Reply to: