PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Probleme beim Start von sshd



Thovan
20.06.06, 12:43
Hallo,

nach einem Update von ClamAV über YAST läuft auf einer SUSE 9.3 ssh auf einmal nicht mehr.
/var/log/messages enthält dazu diese Fehlermeldung
fatal: daemon() failed: no such device

Leider ist google zu diesem Thema sprachlos.
Hat jemand von euch eine Idee, was da passiert ist und wie ich es wieder hinbekomme?

MiGo
21.06.06, 09:29
Wenn du vielleicht ein wenig mehr Fehler posten koenntest? Das ist doch schon sehr geschnitten :)

Thovan
21.06.06, 09:46
Wenn du vielleicht ein wenig mehr Fehler posten koenntest? Das ist doch schon sehr geschnitten :)

Das richtig böse ist ja: Es gibt keine weiteren Fehlermeldungen!
Das einzige was fehlt ist der Timestamp der Prozess (sshd) und eine lange Nummer (wohl irgendein Prozess-Identifier oder so).
Jedenfalls nichts woraus man m.E. auf den Fehler schließen könnte.
Ich hab's weggalssen, weil ich mir das ja nicht per ssh an meiner Workstation anschauen kann, sondern dafür immer in den Serverraum laufen muss.


Ich hatte per YAST ein Online-Update für ClamAV gemacht.
Dabei kam noch das eine oder andere Paket mit (wegen der Abhängigkeiten von ClamAV).
Als ich dann ein paar Tage später mit Putty auf den Server wollte kam da nur "Connection refused".
Dachte zuerst es liegt an der Netzauslastung da die Bandbreite zu diesem zeitpunkt voll ausgenutzt wurde.
Als es nicht besser wurde habe ich mir die Prozessliste auf der Masterkonsole angeschaut und da gesehen, dass sshd nicht lief.
Ein Startversuch über das entsprechende init-Script schlug fehl und bei der Fehlersuche stieß ich in /var/log/messages auf oben genannten Fehler.

In welchem logfile könnte ich denn noch nach detaillierteren Meldungen suchen?

bla!zilla
21.06.06, 10:25
fatal: daemon() failed: no such device

Poste mal bitte deine sshd_config.

Thovan
21.06.06, 11:34
Poste mal bitte deine sshd_config.

Schwierig. Mangels SCP komme ich da ja nicht von meiner Workstation aus ran und vom Server aus kann ich nicht ins Forum.

Hast Du einen bestimmten parameter im verdacht oder eine Idee, wie ich die Datei hierher bekomme?

bla!zilla
21.06.06, 11:44
Mich würde interessieren ob sich der SSHd direkt an eine NIC oder eine IP bindet. Hast du hosts.deny oder hosts.allow angepasst oder was anderes geändert?

marce
21.06.06, 11:47
@thovan: ein
mail -s sshd-config Du@Bei.Dir < sshd.conf geht nicht?

Thovan
21.06.06, 12:01
An diese Möglichkeit hatte ich noch nicht gedacht.


# $OpenBSD: sshd_config,v 1.69 2004/05/23 23:59:53 dtucker Exp $

# This is the sshd server system-wide configuration file. See # sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options change a # default value.

#Port 22
#Protocol 2,1
#ListenAddress 0.0.0.0
#ListenAddress ::

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key #KeyRegenerationInterval 1h #ServerKeyBits 768

# Logging
#obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts #RhostsRSAAuthentication no # similar for protocol version 2 #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # RhostsRSAAuthentication and HostbasedAuthentication #IgnoreUserKnownHosts no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
#PermitEmptyPasswords no

# Change to no to disable s/key passwords #ChallengeResponseAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable support for the deprecated 'gssapi' authentication # mechanism to OpenSSH 3.8p1. The newer 'gssapi-with-mic' mechanism is included # in this release. The use of 'gssapi' is deprecated due to the presence of # potential man-in-the-middle attacks, which 'gssapi-with-mic' is not susceptible to.
#GSSAPIEnableMITMAttack no


# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication mechanism.
# Depending on your PAM configuration, this may bypass the setting of
# PasswordAuthentication, PermitEmptyPasswords, and
# "PermitRootLogin without-password". If you just want the PAM account and
# session checks to run without PAM authentication, then enable this but set
# ChallengeResponseAuthentication=no
UsePAM yes

#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression yes
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10

# no default banner path
#Banner /some/path

# override default of no subsystems
Subsystem sftp /usr/lib/ssh/sftp-server

# This enables accepting locale enviroment variables LC_* LANG, see sshd_config(5).
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL


Wie man sieht, ist es weder an eine NIC oder IP gebunden.
Ich hatte ja auch bis auf die Updates nichts geändert!

bla!zilla
21.06.06, 12:08
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no




Kann mir mal kurz einer bestätigen das das nicht klappen kann?! Keine Pubkey Authentifizierung und Authentifizierung über Passwort auch deaktiviert?

marce
21.06.06, 12:15
hm, also die PubKey-Auth funktioniert bei mir unter Suse 9.3, obwohl der entsprechende Eintrag im Konfigfile auskomentiert ist, allerdings habe ich die PW-Auth noch auf on - will da aber gerade nicht rumspielen...

Hängt davon ab, was vom sshd als default angenommen wird, AFAIK ist das, was in den Kommentaren als default-Einstellung drin, wenn nicht abgeändert...

choener
21.06.06, 12:19
Default für PubkeyAuth ist allerdings Yes...
aber ich werde das jetzt grad nicht an meinem Server ausprobieren :D

Thovan
21.06.06, 12:20
Kann mir mal kurz einer bestätigen das das nicht klappen kann?! Keine Pubkey Authentifizierung und Authentifizierung über Passwort auch deaktiviert?
Na dann probier ich das dochmal.
Komisch nur, dass es ohne veränderung vorher lief!

Thovan
21.06.06, 12:57
Also daran lag's nicht.
Da wäre die Fehlermeldung auch etwas komisch!

MiGo
21.06.06, 13:04
Kann mir mal kurz einer bestätigen das das nicht klappen kann?! Keine Pubkey Authentifizierung und Authentifizierung über Passwort auch deaktiviert?
Das bezieht sich nur auf "tunneled clear text passwords"; bei mir steht's auch auf "no" und ich kann mich mit Passwort einloggen :)

MiGo
21.06.06, 13:10
Das richtig böse ist ja: Es gibt keine weiteren Fehlermeldungen!
Wenn du dir sicher bist, dass das alles ist, was damit zusammenhängt, gut.
Meistens ists allerdings mehr als nur eine Zeile...
Du könntest noch versuchen
a) in /var/log/syslog zu schauen und
b) den Loglevel hochzusetzen

marce
21.06.06, 13:21
starte den Server doch mal im Debug-Modus, vielleicht jagt er dann ein paar sinnvolle Ausgaben mehr raus...

Thovan
21.06.06, 14:08
starte den Server doch mal im Debug-Modus, vielleicht jagt er dann ein paar sinnvolle Ausgaben mehr raus...
Ist debug-Modus jetzt mit höherem Logleve gleichzusetzen?

marce
21.06.06, 14:09
könnte man so sagen

("ja" in *zehnzeichen*-Form)

Thovan
30.06.06, 12:00
So, nur zur Info:

Ein ganz normaler Reboot hat das Problem gelöst!