Clemens Priemer wrote:
Hi Alle zusammen,
Unser SSH will nicht mehr. Wenn wir ssh Starten (rcsshd start) gibt er uns nur folgendes aus:
Starting SSH deamon ... faild
In den Logs
/var/log/messages steht nur folgendes drin:
May 11 09:56:24 homer sshd(3543): fatal: daemon() failed:Success
/var/log/war
May 11 09:56:24 homer sshd(3543):fatal: daemon() faild:Success
Wir haben den dienst auch 3 mal neu Installiert aber es bringt irgendwie alles nichts.
Zur Fehlereingrenzung: a) sicherstellen, das kein sshd Prozess läuft (mittels ps/kill) b) in Shell als root: "/usr/sbin/sshd -Dde" starten - sshd geht nicht in den Hintergrund - sshd schreibt alles auf stderr raus Nach Fehler suchen Andreas
Am Mittwoch, 11. Mai 2005 11:13 schrieb Kyek, Andreas, VF-DE:
Clemens Priemer wrote:
Hi Alle zusammen,
Unser SSH will nicht mehr. Wenn wir ssh Starten (rcsshd start) gibt er uns nur folgendes aus:
Starting SSH deamon ... faild
In den Logs
/var/log/messages steht nur folgendes drin:
May 11 09:56:24 homer sshd(3543): fatal: daemon() failed:Success
/var/log/war
May 11 09:56:24 homer sshd(3543):fatal: daemon() faild:Success
Wir haben den dienst auch 3 mal neu Installiert aber es bringt irgendwie alles nichts.
Zur Fehlereingrenzung:
a) sicherstellen, das kein sshd Prozess läuft (mittels ps/kill) b) in Shell als root: "/usr/sbin/sshd -Dde" starten
- sshd geht nicht in den Hintergrund - sshd schreibt alles auf stderr raus
Nach Fehler suchen So wenn ich den Befehl /usr/sbin/sshd -Dde ausführe komm ich drauf sobald ich runter gehe nicht mehr. Um wieder drauf zu kommen muss ich den Befehl wieder Ausführen. Leider nicht das Optimale da der Server etwas weiter weg steht. Hier das was mir /usr/sbin/sshd -Dde beim Login Sagt:
homer:/etc/ssh # /usr/sbin/sshd -Dde debug1: sshd version OpenSSH_3.9p1 debug1: private host key: #0 type 0 RSA1 debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-Dde' debug1: Bind to port 22 on 195.95.x.x. Server listening on 195.95.x.x port 22. Generating 768 bit RSA key. RSA key generation complete. debug1: Server will not fork when running in debugging mode. debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7 debug1: sshd version OpenSSH_3.9p1 debug1: private host key: #0 type 0 RSA1 debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA debug1: inetd sockets after dupping: 3, 3 Connection from 195.95.221.25 port 2874 debug1: Client protocol version 2.0; client software version OpenSSH_3.9p1 debug1: match: OpenSSH_3.9p1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-1.99-OpenSSH_3.9p1 debug1: permanently_set_uid: 71/65 debug1: list_hostkey_types: ssh-rsa,ssh-dss debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: client->server aes128-cbc hmac-md5 none debug1: kex: server->client aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: userauth-request for user cpriemer service ssh-connection method none debug1: attempt 0 failures 0 debug1: PAM: initializing for "cpriemer" debug1: PAM: setting PAM_RHOST to "195.95.x.x" debug1: PAM: setting PAM_TTY to "ssh" Failed none for cpriemer from 195.95.x.x port 2874 ssh2 Failed none for cpriemer from 195.95.x.x port 2874 ssh2 debug1: userauth-request for user cpriemer service ssh-connection method keyboard-interactive debug1: attempt 1 failures 1 debug1: keyboard-interactive devs debug1: auth2_challenge: user=cpriemer devs= debug1: kbdint_alloc: devices 'pam' debug1: auth2_challenge_start: trying authentication method 'pam' Postponed keyboard-interactive for cpriemer from 195.95.x.x port 2874 ssh2 debug1: PAM: num PAM env strings 0 Postponed keyboard-interactive/pam for cpriemer from 195.95.x.x port 2874 ssh2 Accepted keyboard-interactive/pam for cpriemer from 195.95.x.x port 2874 ssh2 Accepted keyboard-interactive/pam for cpriemer from 195.95.x.x port 2874 ssh2 debug1: monitor_child_preauth: cpriemer has been authenticated by privileged process debug1: PAM: reinitializing credentials debug1: permanently_set_uid: 1000/508 debug1: Entering interactive session for SSH2. debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] debug1: session_new: init debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: server_input_channel_req: channel 0 request pty-req reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req pty-req debug1: Allocating pty. debug1: session_new: init debug1: session_new: session 0 debug1: session_pty_req: session 0 alloc /dev/pts/1 debug1: server_input_channel_req: channel 0 request env reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req env debug1: server_input_channel_req: channel 0 request shell reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req shell debug1: PAM: setting PAM_TTY to "/dev/pts/1" debug1: Setting controlling tty using TIOCSCTTY.
Clemens Priemer wrote:
So wenn ich den Befehl /usr/sbin/sshd -Dde ausführe komm ich drauf sobald ich runter gehe nicht mehr. Um wieder drauf zu kommen muss ich den Befehl wieder Ausführen. Leider nicht das Optimale da der Server etwas weiter weg steht. Hier das was mir /usr/sbin/sshd -Dde beim Login Sagt:
Die Option -D verhindert den Start als Daemon. Ohne diese sollte es dann laufen. Jedenfalls spricht das dafür, dass beim Start von sshd entweder eine falsche config verwendet wird oder das falsche Binary, was noch etwas angsteinflößender ist. Welches binary wird denn genau gestartet durch dein Startscript? In /etc/init.d/sshd sollte die Zeile stehen: SSHD_BIN=/usr/sbin/sshd Was sagt der Befehl which sshd Sandy
Am Mittwoch, 11. Mai 2005 14:48 schrieb Sandy Drobic: sagt:>
Die Option -D verhindert den Start als Daemon. Ohne diese sollte es dann laufen. Jedenfalls spricht das dafür, dass beim Start von sshd entweder eine falsche config verwendet wird oder das falsche Binary, was noch etwas angsteinflößender ist. Du machst mir mut ;-)
Also ohne D geht es trotzdem nicht.
Welches binary wird denn genau gestartet durch dein Startscript? In /etc/init.d/sshd sollte die Zeile stehen: SSHD_BIN=/usr/sbin/sshd
Also bei mir kommt folgendes: homer:/etc/ssh # ln /etc/init.d/sshd ln: „./sshd“: Datei existiert
Was sagt der Befehl which sshd homer:/etc/ssh # which sshd /usr/sbin/sshd
-- Mit freundlichen Gruessen / Best Regards i. A. Clemens Priemer
Clemens Priemer wrote:
Am Mittwoch, 11. Mai 2005 14:48 schrieb Sandy Drobic: sagt:>
Die Option -D verhindert den Start als Daemon. Ohne diese sollte es dann laufen. Jedenfalls spricht das dafür, dass beim Start von sshd entweder eine falsche config verwendet wird oder das falsche Binary, was noch etwas angsteinflößender ist.
Du machst mir mut ;-)
Wenn Dienste wie ssh nicht mehr sauber laufen und man nicht weiss warum, dann ist das wirklich höchste Alarmstufe! Immerhin wird ssh zur Fernwartung verwendet. Dazu scheint dein Server noch aus dem Internet per ssh erreichbar zu sein. ssh ist eines der Pakete, die Rootkits häufig austauschen. Ein Server von meiner früheren Firma wurde mal gehackt, und das machte sich bemerkbar, als wir versuchten, in per ssh zu erreichen. Wirklich kein gutes Zeichen.
Welches binary wird denn genau gestartet durch dein Startscript? In /etc/init.d/sshd sollte die Zeile stehen: SSHD_BIN=/usr/sbin/sshd
Also bei mir kommt folgendes: homer:/etc/ssh # ln /etc/init.d/sshd ln: „./sshd“: Datei existiert
Uh, hier steht das Wort "in" wie "in dieser Datei"... Mit "ln" wie "LN" erzeugst du einen Link. # grep SSHD_BIN /etc/init.d/sshd SSHD_BIN=/usr/sbin/sshd test -x $SSHD_BIN || exit 5
homer:/etc/ssh # which sshd /usr/sbin/sshd
Das sieht ja noch gut aus. Hier mal die Checksumme von meiner sshd (von Suse 9.2): md5sum /usr/sbin/sshd 98a394b0614c0440058c1f87a449df82 /usr/sbin/sshd Wenn da etwas anderes bei dir herauskommt (bei Suse 9.2), dann würde ich wirklich mal chkrootkit und Konsorten testen lassen. Sandy
Am Mittwoch, 11. Mai 2005 17:08 schrieb Sandy Drobic:
Dazu scheint dein Server noch aus dem Internet per ssh erreichbar zu sein. Aus dem www ist er nicht Erreichbar. Du wirst wahrscheinlich auf die IP Ansprechen 195.95.x.x! Unser Ganzez Netz hat die IP Adressen. Das hat VPN Technische und Ablauftechnische Gründe. Wir benötigen die Gekauften IP Ranges. Der Besagte Rechner ist aus dem www her nicht erreichbar. Er sitzt hinter 4 Firewalls ( 2 x Paket Alarm, 1 x Sonic Wall und 1. mal BenHur2). Daher ist es fast Unmöglich den Server aus dem www zu erreichen also können wir einen Haker Angriff ausschliesSen.
Uh, hier steht das Wort "in" wie "in dieser Datei"... Mit "ln" wie "LN" erzeugst du einen Link.
# grep SSHD_BIN /etc/init.d/sshd SSHD_BIN=/usr/sbin/sshd test -x $SSHD_BIN || exit 5
homer:/etc/ssh # which sshd /usr/sbin/sshd Der dienst Existiert auch die Verlink. Wir können den Dienst ja auch Manuell für Genau 1. Sitzung anstossen mit:
/usr/sbin/sshd -Dde
Das sieht ja noch gut aus. Hier mal die Checksumme von meiner sshd (von Suse 9.2): md5sum /usr/sbin/sshd 98a394b0614c0440058c1f87a449df82 /usr/sbin/sshd 581e8b9289e6eb6fa8cc2e716a59c181 /usr/sbin/sshd ist meine
Wenn da etwas anderes bei dir herauskommt (bei Suse 9.2), dann würde ich wirklich mal chkrootkit und Konsorten testen lassen. Die MD5sum ist Unterschiedlich auch auf unseren 9.2 Maschienen Sandy
-- Mit freundlichen Gruessen / Best Regards i. A. Clemens Priemer
Clemens Priemer wrote:
Am Mittwoch, 11. Mai 2005 17:08 schrieb Sandy Drobic:
Dazu scheint dein Server noch aus dem Internet per ssh erreichbar zu sein.
Aus dem www ist er nicht Erreichbar. Du wirst wahrscheinlich auf die IP Ansprechen 195.95.x.x! Unser Ganzez Netz hat die IP Adressen. Das hat VPN Technische und Ablauftechnische Gründe. Wir benötigen die Gekauften IP Ranges. Der Besagte Rechner ist aus dem www her nicht erreichbar. Er sitzt hinter 4 Firewalls ( 2 x Paket Alarm, 1 x Sonic Wall und 1. mal BenHur2). Daher ist es fast Unmöglich den Server aus dem www zu erreichen also können wir einen Haker Angriff ausschliesSen.
Ausschließen kann man einen Hackerangrinn dadurch nicht, aber er wird ziemlich unwahrscheinlich.
Uh, hier steht das Wort "in" wie "in dieser Datei"... Mit "ln" wie "LN" erzeugst du einen Link.
Der dienst Existiert auch die Verlink. Wir können den Dienst ja auch Manuell für Genau 1. Sitzung anstossen mit:
Präziser ausgedrückt, sagte die Meldung, ln hat die Datei sshd dort bereits vorgefunden und legt deshalb NICHT einen Link dort an. Sonst hätte er die Datei sshd mit dem Link überschrieben!
/usr/sbin/sshd -Dde
Starte doch mal mit: /usr/sbin/sshd -dd Bei mir ergibt das: /usr/sbin/sshd -dd debug2: load_server_config: filename /etc/ssh/sshd_config debug2: load_server_config: done config len = 300 debug2: parse_server_config: config /etc/ssh/sshd_config len 300 debug1: sshd version OpenSSH_3.9p1 debug1: read PEM private key done: type RSA debug1: private host key: #0 type 1 RSA debug1: read PEM private key done: type DSA debug1: private host key: #1 type 2 DSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-dd' debug2: fd 3 setting O_NONBLOCK debug1: Bind to port 22 on 0.0.0.0. Bind to port 22 on 0.0.0.0 failed: Address already in use. socket: Address family not supported by protocol Cannot bind any address. Der Fehler ist bei mir korrekt, da sshd bei mir schon läuft und deshalb nicht noch einmal gestartet werden kann.
Das sieht ja noch gut aus. Hier mal die Checksumme von meiner sshd (von Suse 9.2):
OpenSSH_3.9p1, OpenSSL 0.9.7d 17 Mar 2004 Welche Version verwendest du genau?
md5sum /usr/sbin/sshd 98a394b0614c0440058c1f87a449df82 /usr/sbin/sshd
581e8b9289e6eb6fa8cc2e716a59c181 /usr/sbin/sshd ist meine
Sandy
Am Donnerstag, 12. Mai 2005 08:44 schrieb Clemens Priemer:
Das sieht ja noch gut aus. Hier mal die Checksumme von meiner sshd (von Suse 9.2): md5sum /usr/sbin/sshd 98a394b0614c0440058c1f87a449df82 /usr/sbin/sshd
581e8b9289e6eb6fa8cc2e716a59c181 /usr/sbin/sshd ist meine
Bei mir auf einer aktuellen SuSE 9.2 ist die md5sum identisch mit der von Sandy # md5sum /usr/sbin/sshd 98a394b0614c0440058c1f87a449df82 /usr/sbin/sshd MFG Markus
participants (4)
-
Clemens Priemer
-
Kyek, Andreas, VF-DE
-
Markus Wunder
-
Sandy Drobic