Kein Remote-Login mehr nach System-Update

R

robind

Registered User
Hallo liebe Community.

Ich habe ein riesen großes Problem bei meinem Strato vServer. Und zwar habe ich gestern mit Hilfe von YUM ein System-Update von openSUSE10.1 auf openSUSE10.2 gemacht. Lief auch alles bestens danach, bis ich heute den Server neugestartet hab. Danach konnte ich mich nicht mehr in die Konsole vom Server einloggen. Der ssh Service ist also down.
Ich habe schon versucht über das Rescue-System den Dienst neuzustarten, aber wenn ich dann wieder von Festplatte starte ist immer noch kein Remote-Login möglich. In den log Dateien hab ich auch schon geguckt, da steht rein gar nix (jedenfalls nicht zu ssh). Kann mir jmd helfen das Problem zu lösen?

Vielen Dank im Voraus, Robin

Edit: Ach ja, vielleicht noch eine kleine Anmerkung: Wenn ich versuche mich mit PuTTY ins System einzuloggen, dann kommt die Fehlermeldung "Connection refused".
 
Last edited by a moderator:
Hast du mal nachgesehen, ob SSH überhaupt beim Neustart des Systems gestartet wird? Das kannst du am Besten in den Ordnern für die einzelnen Runlevels machen. Soweit ich das noch richtig im Kopf hab, startet Suse normalerweise in rc3. Also sollte in dem Ordner ein Link auf das SSH-Startscript sein.

Wenn das alles in Ordnung ist, würde ich mir mal die SSHd.conf vornehmen, und nachsehen, ob die Ports sauber gesetzt sind, und ob die anderen Zugriffsberechtigungen in dieser Datei sauber gesetzt sind.

Gruß Mordor
 
Hallo, danke für deine Antwort.

Im Ordner /etc/init.d/rc3.d sind folgende Dateien bzw. Verlinkungen aufgelistet:

lrwxrwxrwx 1 root root 7 Jan 1 18:29 K12sshd -> ../sshd
lrwxrwxrwx 1 root root 9 Jan 1 18:29 K12xinetd -> ../xinetd
lrwxrwxrwx 1 root root 9 Jan 1 18:29 K15syslog -> ../syslog
lrwxrwxrwx 1 root root 10 Sep 26 16:43 K16network -> ../network
lrwxrwxrwx 1 root root 12 Sep 26 16:43 K19haldaemon -> ../haldaemon
lrwxrwxrwx 1 root root 7 Sep 26 16:43 K20dbus -> ../dbus
lrwxrwxrwx 1 root root 7 Sep 26 16:43 S01dbus -> ../dbus
lrwxrwxrwx 1 root root 12 Sep 26 16:43 S02haldaemon -> ../haldaemon
lrwxrwxrwx 1 root root 10 Sep 26 16:43 S05network -> ../network
lrwxrwxrwx 1 root root 9 Jan 1 18:29 S06syslog -> ../syslog
lrwxrwxrwx 1 root root 7 Jan 1 18:29 S09sshd -> ../sshd

SSH ist also dabei.

In der Datei /etc/ssh/sshd_config steht folgendes:

# $OpenBSD: sshd_config,v 1.72 2005/07/25 11:59:40 markus 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
#AddressFamily any
#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 no
#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 no


#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#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
Click to expand...

Sollte also eigentlich auch richtig konfiguriert sein. Wenn ich den SSH Dämon manuell vom Rescue-System aus starte, lässt er sich starten. Aber er scheint beim booten von Festplatte nicht zu starten.

LG; Robin
 
Hallo,

robind said:
Wenn ich den SSH Dämon manuell vom Rescue-System aus starte, lässt er sich starten. Aber er scheint beim booten von Festplatte nicht zu starten.
Click to expand...

mit dem Runleveleditor (Yast) den SSHd auf Runlevel 3 setzen. Dazu in das installierte System chrooten.
 
Mit welchem User willst du dich denn über SSH anmelden? Mit Root?
Das wird dann aber nicht funktionieren, denn um sich mit Root anzumelden müsstest du die Direktive
Code: 
PermitRootlogin
auf yes stellen.

Wenn du dich mit einem anderen User einloggst, so sollte dieser in der SSHD.conf drin stehen, sonst lässt ihn SSH nicht zu.

Gru Mordor
 
robind said:
In der Datei /etc/ssh/sshd_config steht folgendes:
Code: 
PermitRootLogin no
PasswordAuthentication no
UsePAM no
Sollte also eigentlich auch richtig konfiguriert sein.
Click to expand...

Hallo!

Sieht gut abgesichert aus...hast du denn einen User (nicht root) auf dem Server für den du auch einen Key auf deinem Rechner hast, mit dem du dich verbinden willst, und der Key ist dem Server bekannt? Sonst sehe ich bei der sshd_config keine Chance dich anzumelden - egal, ob sshd läuft oder nicht - und laut auszug von robind startet sshd ja auch in runlevel 3...sollten nur richtig konfiguriert werden ;-)

mfg tyler

p.s.: man sshd_config hilft weiter
 
Naja, ein Key sollte nicht unbedingt nötig sein, dass man erst mal auf den Server kommt. Wie schon gesagt, ich würde erst mal Root-Login erlauben, und dann zusehen, dass du nen Connect hinbekommst. Dann kannst du überlegen, wie es weiter geht.

Gruß Mordor
 
Hallo.

Hab jetzt ein viel größeres Problem. Nachdem ich laut dem Vorschlag von charli einige Einstellungen im Runlevel-Editor vorgenommen habe, z.B. dass SSH, MySQL & Apache startet, komm ich - nachdem ich im Kundenmenü im normalen Modus booten wollte - weder ins Rescue-System (wegen fehledem PW) noch kann ich irgendwelche Backup-Einstellungen etc. vornehmen. Kann mir jmd. weiter helfen, wie ich den Server zurücksetzen könnte?
LG; Robin
 
Weshalb funktioniert dein normales Passwort nicht? Daran hast du ja eigentlich nichts verändert?

Oder ist der Server beim Reboot hängen geblieben? Dann musst du ihn wohl vom Support neu starten lassen.
 
Hast Du die evtl. die sshd.config des Rescue-Systems verändert?
Du weißt schon, daß meist die Festplatte zu mounten ist, oder?
Und welches Rescue nutzt Du eigentlich?
Strato hat ein "Rescue" und eine "serielle Console". Evtl. solltest Du einfach mal sehen, ob Du mit Letzterem weiter kommst.

huschi.
 
Ich benutze das Strato Rescue-System, also nicht die serielle Konsole. Dabei legt Strato für jeden Rescue-Boot-Vorgang ein neues root Passwort fest (nur für das Rescue-System). Die sshd_config vom Rescue-System hab ich nicht geändert. Hab die Festplatte voher gemountet und chroot gemacht. Ich glaube die serielle Konsole steht einem beim vServer (jedenfalls bei Strato) nicht zur Verfügung, oder täusch ich mich da? Glaub ich muss das System wirklich vom Support rebooten lassen.
 
Normalerweise wenn immer ein neues Passwort vergeben ist, wenn man das Rescue aufruft, sollte es doch eigentlich kein Problem geben. Du gibst dann einfach nur das erhaltene Passwort ein.

Wenn das eben ned geht, dann setz dich mit dem Support in Verbindung.
 
So jetzt geht der Server wieder, nur SSH geht immer noch nicht. Wie kann ich den überprüfen, ob der Dienst gestartet wurde? Ich glaube nämlich nicht, dass es ein Einstellunsfehler ist, denn da hab ich nichts geändert. Und ja, der key für den User "RobiN" ist noch auf dem Server unter dem Pfad /home/Robin/.ssh/authorized_key2.

Es ist so, dass ich nicht mal ein Benutzereingeben kann, sondern dass PuTTY mich gleich mit "Connection refused" zurückweist. Hat vllt. jemand noch ne Idee?

Übrigens kommt jetzt, wenn ich ssh restarten will die Fehlermeldung "startproc: exit status of parent of /usr/sbin/sshd: 255", allerdings schreibt er daneben auch "done" hin.
 
Last edited by a moderator:
Hab das Problem jetzt gelöst, in dem ich einfach beim alten System (SuSE 10.1) geblieben bin. Aber schon komisch, dass SSH bei SUSE 10.2 nicht geht.
 
Hallo,

ich hab Suse 10.3, da geht's dann wieder. :rolleyes:

Liegt vermutlich am Yast-Update, da geht meistens was schief dabei. Besser Neuinstallation als 10.2 oder gleich 10.3.
 
Hmm.. Okay =) Meinst du ich sollte das Update nochmal mit 10.3 versuchen? Funktioniert da auch Plesk?
 
You must log in or register to reply here.
Back
Top