Serverfehlkonfiguration SSH, MySQL - nur Zugriff per Rescue-System möglich

juiz

New Member
Liebe Foren-Gemeinde,

für ein privates Communityprojekt haben wir zwei Server bei Hetzner bestellt und wollten diese ungefähr so laufen lassen:
Debian 6 (Squeeze)
Apache 2 mit PHP 5.3 mit mod_ssl,mod_rewrite
ntpdate für die Uhrzeit
Subversion für das Holen der Dateien von unserem SVN-Server
MySQL 5: Master <=> Master Konfiguration
Strato HiDrive Freigabe per davfs2 lokal mounten und dort Dateien ablegen

Das hat auch alles funktioniert, zum Abschluss haben wir dann beide Server noch per "reboot" zur Sicherheit testen wollen, ob noch alles funktioniert und prompt geht quasi nichts mehr. Es ist kein SSH-Login mehr möglich, nmap liefert nur Rückmeldung auf Port 80 & 443, SSH und MySQL scheinen komplett nicht zu laufen.

/var/log/auth.log enthält keinen Eintrag seit dem letzten erfolgreichen SSH-Login

Da wir beide Server exakt gleich konfiguriert haben (alle Befehle jeweils quasi gleichzeitig ausgeführt) und beide Server das identische Problem haben, kann ein Hardwaredefekt wohl ausgeschlossen werden. Ein Zugriff auf das Rescue-System ist möglich, aber wir sehen da nichts was auf den Fehler schließen lässt.

/var/log/user.log enthält nur:
Code:
May  7 12:30:51 srv1 shutdown[14571]: shutting down for system reboot
May  7 12:55:22 srv1 shutdown[1222]: shutting down for system reboot
May  7 13:27:08 srv1 shutdown[1212]: shutting down for system reboot
May  9 21:41:02 srv1 shutdown[1219]: shutting down for system reboot
May  9 21:52:39 srv1 shutdown[1220]: shutting down for system reboot
May  9 22:41:52 srv1 shutdown[1201]: shutting down for system reboot

/var/log/syslog zeigt das:
Code:
May  9 22:26:41 srv1 kernel: [    6.906983] HDA Intel 0000:02:00.1: setting latency timer to 64
May  9 22:26:41 srv1 kernel: [    7.990250] hda-intel: azx_get_response timeout, switching to polling mode: last cmd=0x002f0d00
May  9 22:26:41 srv1 kernel: [    8.543411] Adding 2102456k swap on /dev/md0.  Priority:-1 extents:1 across:2102456k
May  9 22:26:41 srv1 kernel: [    8.577724] EXT3 FS on md2, internal journal
May  9 22:26:41 srv1 kernel: [    8.689833] loop: module loaded
May  9 22:26:41 srv1 kernel: [    9.606861] kjournald starting.  Commit interval 5 seconds
May  9 22:26:41 srv1 kernel: [    9.628101] EXT3 FS on md1, internal journal
May  9 22:26:41 srv1 kernel: [    9.628186] EXT3-fs: mounted filesystem with ordered data mode.
May  9 22:26:41 srv1 kernel: [   10.062736] r8169: eth0: link up
May  9 22:26:41 srv1 kernel: [   10.062787] r8169: eth0: link up
May  9 22:26:41 srv1 acpid: starting up with netlink and the input layer
May  9 22:26:41 srv1 acpid: 1 rule loaded
May  9 22:26:41 srv1 acpid: waiting for events: event logging is off
May  9 22:26:50 srv1 kernel: [   20.137105] eth0: no IPv6 routers present
May  9 22:26:50 srv1 ntpdate[1061]: step time server 192.53.103.108 offset -0.410280 sec
May  9 22:41:52 srv1 shutdown[1201]: shutting down for system reboot
May  9 22:41:52 srv1 init: Switching to runlevel: 6
May  9 22:41:53 srv1 acpid: exiting
May  9 22:41:53 srv1 kernel: Kernel logging (proc) stopped.
May  9 22:41:53 srv1 rsyslogd: [origin software="rsyslogd" swVersion="4.6.4" x-pid="1161" x-info="http://www.rsyslog.com"] exitin
g on signal 15.

/var/log/messages
Code:
May  9 22:26:41 srv1 kernel: [    8.577724] EXT3 FS on md2, internal journal
May  9 22:26:41 srv1 kernel: [    8.689833] loop: module loaded
May  9 22:26:41 srv1 kernel: [    9.606861] kjournald starting.  Commit interval 5 seconds
May  9 22:26:41 srv1 kernel: [    9.628101] EXT3 FS on md1, internal journal
May  9 22:26:41 srv1 kernel: [    9.628186] EXT3-fs: mounted filesystem with ordered data mode.
May  9 22:26:41 srv1 kernel: [   10.062736] r8169: eth0: link up
May  9 22:26:41 srv1 kernel: [   10.062787] r8169: eth0: link up
May  9 22:41:52 srv1 shutdown[1201]: shutting down for system reboot
May  9 22:41:53 srv1 kernel: Kernel logging (proc) stopped.
May  9 22:41:53 srv1 rsyslogd: [origin software="rsyslogd" swVersion="4.6.4" x-pid="1161" x-info="http://www.rsyslog.com"] exitin
g on signal 15.

Könnte es damit zu tun haben, dass wir für Strato HiDrive einen neuen Key generiert haben? Befehl war:
Code:
ssh-keygen -b 2048 -t rsa

Vielleicht weiß jemand von Euch noch Rat? Was könnte man noch tun, damit Debian sagt, was los ist? Ich weiß nicht mehr, was man noch an Logging aktivieren kann, auch der Cron Log hat nichts gebracht.

Bora
 
Bei Hetzner kannst du doch ne LARA anschliessen lassen.

Schau doch mal beim ersten Server wo er stehen bleibt und warum nichts mehr weiter geht.

Hast du die Konfiguration von ssh kontrolliert?
 
Vielen Dank für deine schnelle Antwort! :-)

Die SSH Konfiguration (wir haben da aber nichts "bewusst" geändert) sieht so aus:

Code:
root@rescue /mnt/etc/ssh # tail -n 1000 sshd_config
# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

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

# Logging
SyslogFacility AUTH
LogLevel DEBUG

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile

LARA kannte ich bis jetzt noch nicht, ist soeben beauftragt!
 
Last edited by a moderator:
Kurze Anmerkung zu deinem SSH Konfig Datei.
Sofern du SSH-Key Authentifizierung benutzen möchtest, solltest du deine Konfig um folgendes erweitern, bzw abändern:

Code:
[...]
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      %h/.ssh/authorized_keys
[...]

Bei dir war der AuthorizedKeyFile Punkt auskommentiert.

Code:
#AuthorizedKeysFile
 
Hui vielen Dank! Beide Tips waren super:

1. Mithilfe von LARA haben wir feststellen können, dass der Apache2 an einem SSL-Zertifikat hängt, für das man einen Key eingeben muss. Gibt man ihn ein, startet das System perfekt. Echt, dass das SSH,MySQL und alles so krass aufhält - hui!

2. Mithilfe des anderen Tipps können wir jetzt auch von einem auf den anderen perfekt zugreifen, da gab's vorher Probleme!

Geniales Forum - geniale Leute - D - A - N - K - E ! ! !
 
Bei dir war der AuthorizedKeyFile Punkt auskommentiert.

Was hat man bei Debian denn da wieder rumgepfuscht? Der offizielle Default entspricht OOTB dem jetzt beim OP gesetztem Pfad und somit darf die Option auf einem unverpfuschtem System getrost kommentiert sein.
 
Ich verwende auch Debian (ein System noch mit Lenny, eins mit Squeeze) und habe die Option bei mir auskommentiert gelassen - ohne Probleme. Da hat Debian also nix verpfuscht, das oben wird wohl nicht an dieser Option gelegen haben.
 
Back
Top