Linupedia.org - Benutzerbeiträge [de]

Grub, Raid1 Ausfallsicherheit

2006-08-28T17:33:12Z

Carsten:

''Wie alles hier ist auch das ohne Gewähr!! Wer seine Platten und oder Controller schrottet hat selbst Schuld !!!!''

==== Vorbemerkungen ====

Ausgangssituation ist ein PC mit 2 Festplatten im RAID1-Verbund (Soft-RAID), der aber im Fehlerfall der Platte 1 (hier sda2) nicht von der Spiegelplatte (hier sdb2) bootet.
Ziel ist, daß bei Fehlern an beiden Platten jeweils von der anderen Platte gebootet und gearbeitet werden kann.

==== Bootloader [[Der_Bootloader_Grub|grub]] auf beiden Platten installieren ====

Dazu eine Konsole öffnen und eingeben

grub

Damit öffnet man die Konsole von grub.

Nun eingeben:
grub>root (hd0,1)
grub>setup (hd0)
grub>root (hd1,1)
grub>setup (hd1)

Damit wird grub in die MBR's der zweiten Partitionen der beiden Festplatten geschrieben. Ist bei mir, siehe oben, halt so. Kann natürlich auch anders partitioniert werden, dann müssen eben die Einträge geändert werden.

==== Konfigurationsdatei /boot/grub/menu.lst ändern ====

Was nun noch fehlt, ist der Hinweis für grub, dass er, sollte von der ersten Platte nicht gebootet werden können, automatisch auf der zweiten Platte nach einer Bootmöglichkeit suchen soll.

Dazu wird folgende Datei geändert:
'''/boot/grub/menu.lst'''

# Booten automatisch nach 10 Sekunden
timeout 10
# Standard Booten von hd0
default 0
# Fallback auf hd1, falls hd0 scheitert
fallback 1
# Booten disc 0 kernel
title Booten Platte 1
kernel (hd0,1)/boot/vmlinuz root=/dev/md0
initrd (hd0,1)/boot/initrd
# Booten disc 1 kernel
title Booten Platte 2
kernel ((hd1,1)/boot/vmlinuz root=/dev/md0
initrd (hd1,1)/boot/initrd

Damit weiß grub, von welcher Platte/Partition er alternativ booten soll.

==== RAID-Funktion testen ====

Um sicher zu sein, dass erst mal alles richtig läuft, kann man sich den Status des RAID-Arrays so anzeigen lassen:

mdadm --detail /dev/md0

Da müssten oben 2 Raid-Devices und der Status "Clean" sowie ganz unten die beiden Platten mit Status "active sync" stehen. Ist das der Fall, läuft das RAID ordnungsgemäß.

Jetzt geht's los:
Den Stromstecker der ersten Platte ziehen und den Server neu starten. SCSI-Platten und Controller sollten das verkraften. Bei IDE-Platten unbedingt VORHER runterfahren und ausschalten!! Läuft alles richtig, dann bootet die Kiste trotzdem ohne Probleme.

Dann wieder neu starten aber vorher die abgehängte Platte wieder anschließen. Auch jetzt muß die Kiste ohne Probleme booten. Am System anmelden und eingeben:

mdadm --detail /dev/md0

Das zeigt den Status des RAIDs "md0". Ganz unten sieht man jetzt, dass nur noch eine Platte den Status "active sync /dev/sda2" hat. In meinem Fall ist also nur noch die Partition sda2 im RAID aktiv.

Eine weitere Partition wird noch als Zeile aufgeführt, steht aber auf Status "removed". Das heißt, dass durch das Abstöpseln dieser Platte diese aus dem RAID-Verbund fällt. Der wird auch nicht automatisch wiederhergestellt, nur wenn man den Stecker wieder einsteckt.

Steckt man die Platte im noch laufenden System wieder ein, dann wird sie im RAID zwar angezeigt aber als nicht mehr synchron deaktiviert. Ist das der Fall, dann muss die Platte erst aus dem RAID entfernt werden mit

mdadm /dev/md0 -r /dev/sdb2

Ist sie draussen, dann kann sie mit

mdadm /dev/md0 -a /dev/sdb2

wieder in den RAID-Verbund eingehängt werden und wird automatisch synchronisiert.
Mit

mdadm --detail /dev/md0

kann man den Stand der Synchronisierung sehen. Da steht dann nämlich z.B.:

Rebuid Status : 52% complete

und ganz unten sieht man eine neue Platte mit Status '''"spare rebuilding"'''.

Ist der Rebuild abgeschlossen, hat man wieder ein schönes RAID1 mit zwei Platten und Status '''"active sync"'''.

Das ganze funktioniert tatsächlich nun bei beiden Platten, d.h. egal welche ausfällt, ob im laufenden Betrieb oder beim Reboot, die Kiste läuft weiter. Jetzt muß ich nur noch rauskriegen, wie man mdadm dazu bekommt, das RAID online zu überwachen und hübsch per mail laut zu geben, wenn sich eine Platte verabschiedet. Dann bin ich glücklich und zufrieden - mindestens was das Thema RAID angeht.

Und hier noch die Ergänzung zum Thema automatische Benachrichtigung:

==== Automatische Benachrichtigung einrichten ====
===== Postfix =====

In meinem Fall übernimmt der Server normalerweise keinerlei Mail-Funktionen. Das soll auch so bleiben. Damit er aber immerhin interne Mails korrekt verschicken kann, muß trotzdem eine Minimalkonfiguration in der Datei '''/etc/postfix/main.cf'''erfolgen.

Die folgenden drei Zeilen zu ändern bzw. zu aktivieren (# entfernen) reichte in meinem Fall aus:

myorigin = $myhostname
mynetworks = Mein.IP.Adresskreis.0/24, 127.0.0.0/8
relayhost = [IP.Adresse.meines.Mailservers]

Nicht vergessen: Nach der Änderung der main.cf muß die Konfiguration noch in der Konsole mit
postfix reload

geladen werden.
 Postfix wird bei Suse standardmäßig mit installiert und gestartet. Da braucht man sonst nichts zu machen. Der Schritt hier ist also nicht unbedingt notwendig.

===== mdadm konfigurieren =====

Sehr einfach: In der Datei '''/etc/mdadm.conf''' wird die Zeile
MAILADDR admin@meine.domain.de
angehängt. Kann natürlich jede x-beliebige Mail-Adresse sein. Allerdings nur eine einzige. 
Falls diese Datein nicht vorhanden ist kann die Mailadresse auch im sysconfig-Editor bei system/File Systems/Mdadm/Mdadm_Mail eingetragen werden. Wenn weiterhin eine Weiterleitung von root-mails an den Hauptbenutzer eingerichtet ist reicht als Adresse root@localhost

===== mdadm als Daemon starten =====

Einfach über den Yast/System/Runlevel-Editor den Dienst mdadmd starten

Erfolg: Fällt jetzt eine Platte aus, geht eine Fehlermeldung per Mail an die oben eingestellte Mail-Adresse raus, die freundlicherweise mitteilt, welches Array an welchem Server betroffen ist.

PMBOSS

[[Category:Bootmanager]]

Grub, Raid1 Ausfallsicherheit

2006-08-28T17:32:17Z

Carsten:

''Wie alles hier ist auch das ohne Gewähr!! Wer seine Platten und oder Controller schrottet hat selbst Schuld !!!!''

==== Vorbemerkungen ====

Ausgangssituation ist ein PC mit 2 Festplatten im RAID1-Verbund (Soft-RAID), der aber im Fehlerfall der Platte 1 (hier sda2) nicht von der Spiegelplatte (hier sdb2) bootet.
Ziel ist, daß bei Fehlern an beiden Platten jeweils von der anderen Platte gebootet und gearbeitet werden kann.

==== Bootloader [[Der_Bootloader_Grub|grub]] auf beiden Platten installieren ====

Dazu eine Konsole öffnen und eingeben

grub

Damit öffnet man die Konsole von grub.

Nun eingeben:
grub>root (hd0,1)
grub>setup (hd0)
grub>root (hd1,1)
grub>setup (hd1)

Damit wird grub in die MBR's der zweiten Partitionen der beiden Festplatten geschrieben. Ist bei mir, siehe oben, halt so. Kann natürlich auch anders partitioniert werden, dann müssen eben die Einträge geändert werden.

==== Konfigurationsdatei /etc/grub.conf ändern ====

Was nun noch fehlt, ist der Hinweis für grub, dass er, sollte von der ersten Platte nicht gebootet werden können, automatisch auf der zweiten Platte nach einer Bootmöglichkeit suchen soll.

Dazu wird folgende Datei geändert:
'''/boot/grub/menu.lst'''

# Booten automatisch nach 10 Sekunden
timeout 10
# Standard Booten von hd0
default 0
# Fallback auf hd1, falls hd0 scheitert
fallback 1
# Booten disc 0 kernel
title Booten Platte 1
kernel (hd0,1)/boot/vmlinuz root=/dev/md0
initrd (hd0,1)/boot/initrd
# Booten disc 1 kernel
title Booten Platte 2
kernel ((hd1,1)/boot/vmlinuz root=/dev/md0
initrd (hd1,1)/boot/initrd

Damit weiß grub, von welcher Platte/Partition er alternativ booten soll.

==== RAID-Funktion testen ====

Um sicher zu sein, dass erst mal alles richtig läuft, kann man sich den Status des RAID-Arrays so anzeigen lassen:

mdadm --detail /dev/md0

Da müssten oben 2 Raid-Devices und der Status "Clean" sowie ganz unten die beiden Platten mit Status "active sync" stehen. Ist das der Fall, läuft das RAID ordnungsgemäß.

Jetzt geht's los:
Den Stromstecker der ersten Platte ziehen und den Server neu starten. SCSI-Platten und Controller sollten das verkraften. Bei IDE-Platten unbedingt VORHER runterfahren und ausschalten!! Läuft alles richtig, dann bootet die Kiste trotzdem ohne Probleme.

Dann wieder neu starten aber vorher die abgehängte Platte wieder anschließen. Auch jetzt muß die Kiste ohne Probleme booten. Am System anmelden und eingeben:

mdadm --detail /dev/md0

Das zeigt den Status des RAIDs "md0". Ganz unten sieht man jetzt, dass nur noch eine Platte den Status "active sync /dev/sda2" hat. In meinem Fall ist also nur noch die Partition sda2 im RAID aktiv.

Eine weitere Partition wird noch als Zeile aufgeführt, steht aber auf Status "removed". Das heißt, dass durch das Abstöpseln dieser Platte diese aus dem RAID-Verbund fällt. Der wird auch nicht automatisch wiederhergestellt, nur wenn man den Stecker wieder einsteckt.

Steckt man die Platte im noch laufenden System wieder ein, dann wird sie im RAID zwar angezeigt aber als nicht mehr synchron deaktiviert. Ist das der Fall, dann muss die Platte erst aus dem RAID entfernt werden mit

mdadm /dev/md0 -r /dev/sdb2

Ist sie draussen, dann kann sie mit

mdadm /dev/md0 -a /dev/sdb2

wieder in den RAID-Verbund eingehängt werden und wird automatisch synchronisiert.
Mit

mdadm --detail /dev/md0

kann man den Stand der Synchronisierung sehen. Da steht dann nämlich z.B.:

Rebuid Status : 52% complete

und ganz unten sieht man eine neue Platte mit Status '''"spare rebuilding"'''.

Ist der Rebuild abgeschlossen, hat man wieder ein schönes RAID1 mit zwei Platten und Status '''"active sync"'''.

Das ganze funktioniert tatsächlich nun bei beiden Platten, d.h. egal welche ausfällt, ob im laufenden Betrieb oder beim Reboot, die Kiste läuft weiter. Jetzt muß ich nur noch rauskriegen, wie man mdadm dazu bekommt, das RAID online zu überwachen und hübsch per mail laut zu geben, wenn sich eine Platte verabschiedet. Dann bin ich glücklich und zufrieden - mindestens was das Thema RAID angeht.

Und hier noch die Ergänzung zum Thema automatische Benachrichtigung:

==== Automatische Benachrichtigung einrichten ====
===== Postfix =====

In meinem Fall übernimmt der Server normalerweise keinerlei Mail-Funktionen. Das soll auch so bleiben. Damit er aber immerhin interne Mails korrekt verschicken kann, muß trotzdem eine Minimalkonfiguration in der Datei '''/etc/postfix/main.cf'''erfolgen.

Die folgenden drei Zeilen zu ändern bzw. zu aktivieren (# entfernen) reichte in meinem Fall aus:

myorigin = $myhostname
mynetworks = Mein.IP.Adresskreis.0/24, 127.0.0.0/8
relayhost = [IP.Adresse.meines.Mailservers]

Nicht vergessen: Nach der Änderung der main.cf muß die Konfiguration noch in der Konsole mit
postfix reload

geladen werden.
 Postfix wird bei Suse standardmäßig mit installiert und gestartet. Da braucht man sonst nichts zu machen. Der Schritt hier ist also nicht unbedingt notwendig.

===== mdadm konfigurieren =====

Sehr einfach: In der Datei '''/etc/mdadm.conf''' wird die Zeile
MAILADDR admin@meine.domain.de
angehängt. Kann natürlich jede x-beliebige Mail-Adresse sein. Allerdings nur eine einzige. 
Falls diese Datein nicht vorhanden ist kann die Mailadresse auch im sysconfig-Editor bei system/File Systems/Mdadm/Mdadm_Mail eingetragen werden. Wenn weiterhin eine Weiterleitung von root-mails an den Hauptbenutzer eingerichtet ist reicht als Adresse root@localhost

===== mdadm als Daemon starten =====

Einfach über den Yast/System/Runlevel-Editor den Dienst mdadmd starten

Erfolg: Fällt jetzt eine Platte aus, geht eine Fehlermeldung per Mail an die oben eingestellte Mail-Adresse raus, die freundlicherweise mitteilt, welches Array an welchem Server betroffen ist.

PMBOSS

[[Category:Bootmanager]]

Grub, Raid1 Ausfallsicherheit

2006-08-28T17:00:34Z

Carsten:

''Wie alles hier ist auch das ohne Gewähr!! Wer seine Platten und oder Controller schrottet hat selbst Schuld !!!!''

==== Vorbemerkungen ====

Ausgangssituation ist ein PC mit 2 Festplatten im RAID1-Verbund (Soft-RAID), der aber im Fehlerfall der Platte 1 (hier sda2) nicht von der Spiegelplatte (hier sdb2) bootet.
Ziel ist, daß bei Fehlern an beiden Platten jeweils von der anderen Platte gebootet und gearbeitet werden kann.

==== Bootloader grub auf beiden Platten installieren ====

Dazu eine Konsole öffnen und eingeben

grub

Damit öffnet man die Konsole von grub.

Nun eingeben:
grub>root (hd0,1)
grub>setup (hd0)
grub>root (hd1,1)
grub>setup (hd1)

Damit wird grub in die MBR's der zweiten Partitionen der beiden Festplatten geschrieben. Ist bei mir, siehe oben, halt so. Kann natürlich auch anders partitioniert werden, dann müssen eben die Einträge geändert werden.

==== Konfigurationsdatei /etc/grub.conf ändern ====

Was nun noch fehlt, ist der Hinweis für grub, dass er, sollte von der ersten Platte nicht gebootet werden können, automatisch auf der zweiten Platte nach einer Bootmöglichkeit suchen soll.

Dazu wird folgende Datei geändert:
'''/boot/grub/menu.lst'''

# Booten automatisch nach 10 Sekunden
timeout 10
# Standard Booten von hd0
default 0
# Fallback auf hd1, falls hd0 scheitert
fallback 1
# Booten disc 0 kernel
title Booten Platte 1
kernel (hd0,1)/boot/vmlinuz root=/dev/md0
initrd (hd0,1)/boot/initrd
# Booten disc 1 kernel
title Booten Platte 2
kernel ((hd1,1)/boot/vmlinuz root=/dev/md0
initrd (hd1,1)/boot/initrd

Damit weiß grub, von welcher Platte/Partition er alternativ booten soll.

==== RAID-Funktion testen ====

Um sicher zu sein, dass erst mal alles richtig läuft, kann man sich den Status des RAID-Arrays so anzeigen lassen:

mdadm --detail /dev/md0

Da müssten oben 2 Raid-Devices und der Status "Clean" sowie ganz unten die beiden Platten mit Status "active sync" stehen. Ist das der Fall, läuft das RAID ordnungsgemäß.

Jetzt geht's los:
Den Stromstecker der ersten Platte ziehen und den Server neu starten. SCSI-Platten und Controller sollten das verkraften. Bei IDE-Platten unbedingt VORHER runterfahren und ausschalten!! Läuft alles richtig, dann bootet die Kiste trotzdem ohne Probleme.

Dann wieder neu starten aber vorher die abgehängte Platte wieder anschließen. Auch jetzt muß die Kiste ohne Probleme booten. Am System anmelden und eingeben:

mdadm --detail /dev/md0

Das zeigt den Status des RAIDs "md0". Ganz unten sieht man jetzt, dass nur noch eine Platte den Status "active sync /dev/sda2" hat. In meinem Fall ist also nur noch die Partition sda2 im RAID aktiv.

Eine weitere Partition wird noch als Zeile aufgeführt, steht aber auf Status "removed". Das heißt, dass durch das Abstöpseln dieser Platte diese aus dem RAID-Verbund fällt. Der wird auch nicht automatisch wiederhergestellt, nur wenn man den Stecker wieder einsteckt.

Steckt man die Platte im noch laufenden System wieder ein, dann wird sie im RAID zwar angezeigt aber als nicht mehr synchron deaktiviert. Ist das der Fall, dann muss die Platte erst aus dem RAID entfernt werden mit

mdadm /dev/md0 -r /dev/sdb2

Ist sie draussen, dann kann sie mit

mdadm /dev/md0 -a /dev/sdb2

wieder in den RAID-Verbund eingehängt werden und wird automatisch synchronisiert.
Mit

mdadm --detail /dev/md0

kann man den Stand der Synchronisierung sehen. Da steht dann nämlich z.B.:

Rebuid Status : 52% complete

und ganz unten sieht man eine neue Platte mit Status '''"spare rebuilding"'''.

Ist der Rebuild abgeschlossen, hat man wieder ein schönes RAID1 mit zwei Platten und Status '''"active sync"'''.

Das ganze funktioniert tatsächlich nun bei beiden Platten, d.h. egal welche ausfällt, ob im laufenden Betrieb oder beim Reboot, die Kiste läuft weiter. Jetzt muß ich nur noch rauskriegen, wie man mdadm dazu bekommt, das RAID online zu überwachen und hübsch per mail laut zu geben, wenn sich eine Platte verabschiedet. Dann bin ich glücklich und zufrieden - mindestens was das Thema RAID angeht.

Und hier noch die Ergänzung zum Thema automatische Benachrichtigung:

==== Automatische Benachrichtigung einrichten ====
===== Postfix =====

In meinem Fall übernimmt der Server normalerweise keinerlei Mail-Funktionen. Das soll auch so bleiben. Damit er aber immerhin interne Mails korrekt verschicken kann, muß trotzdem eine Minimalkonfiguration in der Datei '''/etc/postfix/main.cf'''erfolgen.

Die folgenden drei Zeilen zu ändern bzw. zu aktivieren (# entfernen) reichte in meinem Fall aus:

myorigin = $myhostname
mynetworks = Mein.IP.Adresskreis.0/24, 127.0.0.0/8
relayhost = [IP.Adresse.meines.Mailservers]

Nicht vergessen: Nach der Änderung der main.cf muß die Konfiguration noch in der Konsole mit
postfix reload

geladen werden. Postfix wird bei Suse standardmäßig mit installiert und gestartet. Da braucht man sonst nichts zu machen.

===== mdadm konfigurieren =====

Sehr einfach: In der Datei '''/etc/mdadm.conf''' wird die Zeile
MAILADDR admin@meine.domain.de
angehängt. Kann natürlich jede x-beliebige Mail-Adresse sein. Allerdings nur eine einzige.

===== mdadm als Daemon starten =====

Einfach über den Yast/System/Runlevel-Editor den Dienst mdadmd starten

Erfolg: Fällt jetzt eine Platte aus, geht eine Fehlermeldung per Mail an die oben eingestellte Mail-Adresse raus, die freundlicherweise mitteilt, welches Array an welchem Server betroffen ist.

PMBOSS

[[Category:Bootmanager]]

Was alles bei einem root-Server wichtig ist

2006-08-20T08:31:43Z

Carsten: /* Sicherer Zugriff mit putty und ssh key auf einen Linux Server */

Achtung: Dieses HOWTO ist noch im entstehen und als vorlaeufig (Draft) zu betrachten!

Dieses ist eine Sammlung von HOWTOs, die die wichtigstens Aktionen beschreiben, die bei einem Aufsetzen und Betreiben eines root Servers wenigstens durchzufuehren sind um einen in Grundzuegen sicheren root Server zu erhalten.

Exclamation Diese HOWTO's entlasten einen root Server Betreiber aber nicht von der Verantwortung für diesen Exclamation .

Wer zu dem Thema etwas beitragen will, der melde sich bitte per PN bei mir, da die Struktur beibehalten werden sollte, wie sie im hier angegegebenen Inhalt vorhanden ist.--[[Benutzer:Yehudi|Yehudi]] 17:38, 16. Aug 2006 (CEST)

=== [[Allgemein]] ===

Warum man ohne Linuxknowhow keinen root server mietet
http://www.linux-club.de/ftopic48323.html

Keine Ahnung aber root Server...
http://www.linux-club.de/ftopic63549.html

http://www.netsecond.net/howto/

http://www.linux-magazin.de/Artikel/ausgabe/2002/11/debserv/debserv.html

weitere Links folgen, und können auch gerne hizugefügt werden.

--[[Benutzer:Yehudi|Yehudi]] 17:37, 16. Aug 2006 (CEST)

=== [[Sicherer Zugriff mit putty und ssh key auf einen Linux Server]] ===
(Dieser Teil stammt von framp)
Dieses HOWTO beschreibt, welche Schritte notwendig sind um sicher von einem Windows Rechner per ssh mit putty und nur mit einem ssh key auf einen Linux Server mit SuSE zuzugreifen.

Saemtliche Schritte auf dem Server werden mittels putty mit Konsolbefehlen und keiner graphischen Oberflaeche beschrieben. Eine graphische Oberflaeche birgt eine Menge Sicherheitsprobleme und aus langer Linuxerfahrung leidgepruefter Serveradministratoren sollte keine graphische Oberflaeche (X, KDE, GNOME) auf einem Server installiert sein. Die konkrete Anleitung geht davon aus, dass keine Passwoerter mehr zur Authentifiziereung benutzt werden sondern asymmetrische keys. Diese kann man durch eine Passphrase sichern oder aber auch auf die Passphrase verzichten.
Der Vorteil bei keiner Passphrase ist, dass ein Zugriff immer ohne Passworteingabe moeglich ist. Der Nachteil ist, dass jeder, der den private key hat oder illegalerweise kopiert unbegrenzten Zugriff hat. Wer also ohne Passwort fahren will muss seine keys absolut sicher verwahren!

Saemtliche Konfigurationsaktionen auf dem Server werden per putty mit einem normalen user und seinem password gemacht. Ein paar Aenderungen benoetigen auch den user root mit seinem passwort. Erst am Ende nach erfolgreichem Test wird die Passwortauthentifizierung ausgeschaltet. Danach ist ein ssh Zugriff nur noch mit keys moeglich und jegliche Anmeldeversuche am Linux Server sind ohne key zum Scheitern verurteilt.

Achtung: Am Ende der Konfiguration kann sich aus Sicherheitsgruenden niemand mehr als root per ssh auf den Server anmelden! Dieses ist nur noch dem einen Benutzer der konfiguriert wurde mit seinem Key moeglich! Wenn root Zugriff benoetigt wird muss sich erst als normaler user anmelden und kann dann mit su - root Rechte bekommen. Sind Zugriffe von weiteren Usern notwendig sind die Steps 1-2 entsprechend zu wiederholen.

Konkret wurde die HOWTO Schritte mit putty 0.58 sowie OpenSSH 4.1p1 mit SuSE 10.0 erstellt. Konkret wird in der StepByStep Anleitung das Einrichten eines eines ssh Zugriffs mit putty fuer den user framp auf dem ssh Server obelix eingerichtet.

Folgende Schritte sind notwendig um sich letzendlich per putty und ssh key auf einen ssh Server anmelden zu koennen:

1) Erzeugen eines privaten und public keys mit putty
2) Anpassen des putty public keys an OpenSSH und kopieren des public OpenSSH Keys auf den Server und Aufnahme des keys in der authorized_keys Datei
3) Aenderung der sshd Konfiguration so dass keys akzeptiert benutzt werden
4) Einrichten des putty um mit dem key auf den Server zugreifen zu koennen und Test des Zugriffs mit key
5) Aenderung der sshd Konfiguration so dass keine passwoerter mehr erlaubt sind sondern nur moch mit keys moeglich ist
6) Hardening des sshd Servers, d.h. Pruefen von wichtigen Parametern auf die richtige sichere Einstellung

1) Erzeugen eines privaten und public keys mit putty

a) Starten des Programms puttygen auf dem WindowsClient. Dann ssh-2 RSA waehlen und number of bits in generated key auf 2048 setzen. 
b) Druecken von Generate 
c) Save the generated key druecken und sichern des public und private keys in C:\Program Files\putty als id_rsa und id_rsa_priv.ppk.

2) Anpassen des putty public keys an OpenSSH und kopieren des public OpenSSH Keys auf den Server und Aufnahme des keys in der authorized_keys Datei

a) Oeffnen eines Befehlsfensters und kopieren des putty public files id_rsa in id_rsa_linux mit dem befehl copy id_rsa id_rsa_linux[/i] 
b) Mit einem Windows Editor muss die Datei id_rsa_linux sorgfaeltig geandert werden: Die ersten zwei Zeilen sowie die letzte Zeile muss
geloescht werden. Danach muessen alle Zeilen in eine Zeile zusammengefasst werden. Achtung! Es duerfen keine Leerzeichen auftauchen. Zum Schluss muss noch ssh-rsa am Anfang der Keyzeile eingefuegt werden. Achtung: Ein Leerzeichen am Ende von rsa! Die Zeile muss dann mit ssh-rsa AAAAB3 beginnen. 
c) Oeffnen eines Befehlsfensters und C:\Program Files\putty>pscp id_rsa_linux framp@obelix:id_rsa aufrufen. Damit wird
der linux public key in das home Verzeichnis des users framp kopiert. 
d) C:\Program Files\putty>putty framp@obelix:id_rsa aufrufen. Damit wird ein Befehlsfenster auf dem Server geoeffnet. 
e) mkdir .ssh legt das .ssh Verzeichnis an wenn es nicht schon existiert 
f) cat id_rsa >> .ssh/authorized_keys WICHTIG ! >> benutzen !!! Ansonsten werden schon existierende Authorisierungen geloescht. 

3) Aenderung der sshd Konfiguration so dass keys akzeptiert benutzt werden

a) Im putty Fenster mit C:\Program Files\putty>pscp root@obelix:/etc/ssh/sshd_config sshd_config die sshd Konfigurationsdatei downloaden. 
b) Editieren der Datei mit einem Windows Editor so dass die folgenden Parameter wie folgt gesetzt sind: 
PubkeyAuthentication yes 
RSAAuthentication no 

c) Im putty Fenster mit C:\Program Files\putty>pscp sshd_config root@obelix:/etc/ssh/sshd_config die sshd Konfigurationsdatei uploaden. 
d) Im Server Befehlsfenster welches in 2.a geoffnet wurde rcsshd restart eingeben. 

4) Einrichten des putty um mit dem key auf den Server zugreifen zu koennen und Test des Zugriffs mit key

a) Starten des Programms putty auf dem WindowsClient. 
b) Beim hostname framp@obelix eintragen (userid und Server name oder IP) 
c) Zu Connection->SSH->Auth gehen und das Private key file for authentication fuellen mit C:\Program Files\putty\id_rsa_priv.ppk. 
d) open und erscheint ein Befehlsfenster des Servers. U.U. muss noch die Passphrase eingegeben werden 
e) Sichern des putty Profiles 
f) Damit ist die ssh Verbindung mit key getestet und es kann die Passwortauthentifizierung ausgeschaltet werden. 

5) Aenderung der sshd Konfiguration so dass keine Passwoerter mehr erlaubt sind sondern nur moch mit keys moeglich ist

a) Im putty Fenster mit C:\Program Files\putty>pscp root@obelix:/etc/sshd/sshd_config sshd_config die sshd Konfigurationsdatei downloaden. 
b) Editieren der Datei mit einem Windows Editor so dass die folgenden Parameter wie folgt gesetzt sind: 
PubkeyAuthentication yes 
PasswordAuthentication no 
ChallengeResponseAuthentication no 

c) Im putty Fenster mit C:\Program Files\putty>pscp sshd_config root@obelix:/etc/sshd/sshd_config die sshd Konfigurationsdatei uploaden. 
d) Im Server Befehlsfenster welches in 2.a geoffnet wurde rcsshd restart eingeben. 

6) Hardening des sshd Servers, d.h. Pruefen von wichtigen Parametern auf die richtige sichere Einstellung

Diese Schritte sind eigentlich nicht mehr notwendig da kein Zugriff ohne key mehr moeglich ist. Es kann aber immer sein
dass aus verschiedenen Gruenden doch wieder auf Passwoerter umgestellt wird (PasswordAuthentication yes). root Zugriff per ssh
sollte aus Sicherheitsgruenden immer ausgeschaltet sein. benoetigt man root recht kann man als normaler User per su -
root rechte erhalten oder man setzt sudo ein. Deshalb sollte ein jeder ssh Server auf alle Faelle noch wie folgt gesichert werden: 

a) Im putty Fenster mit C:\Program Files\putty>pscp root@obelix:/etc/sshd/sshd_config sshd_config die sshd Konfigurationsdatei downloaden. 
b) Editieren der Datei mit einem Windows Editor so dass die folgenden Parameter wie folgt gesetzt sind: 
PermitRootLogin no 
AllowGroups users 
AllowUsers xxx yyy zzz (xxx, yyy und zzz sind user die per ssh zugreifen duerfen) 
ClientAliveInterval 15 
LoginGraceTime 10 
PubkeyAuthentication yes 
MaxAuthTries 3 
MaxStartups 1 
PrintLastLog yes 
KeepAlive no 

c) Im putty Fenster mit C:\Program Files\putty>pscp sshd_config root@obelix:/etc/sshd/sshd_config die sshd Konfigurationsdatei uploaden. 
d) Im Server Befehlsfenster welches in 2.a geoffnet wurde rcsshd restart eingeben. 

Als Grundlage fuer dieses HOWTO dienten u.A. folgende Threads:

[Howto] Einrichten von publikkeys unter der ssh
[TIP]ssh einrichten mit public-key Authentifizierung
[TIP]Wie sichere ich meinen ssh Server?
[TIP]Den eigenen Server absichern

Weitere Informtionen zu putty und OpenSSH:

putty homepage
Was Wikipedia zu putty sagt
OpenSSH homepage
OpenSSh manuals

Weitere Threads zu ssh spezifischen Fragen und Problemen:

Kontrolliertes Ausfuehren von Befehlen als root
SSH Angriffe
Host bei ssh Connection ablehnen

Des weiteren liefert eine Suche nach ssh im Forum diverse weitere Fragen und Antworten zu ssh die hier im HOWTO nicht behandelt wurden.

Last but not least lieferte http://www.framp.de/linux/?Netzwerk_Services:ssh_server wesentliche Teile zu diesem HOWTO.

Kommentare, Anmerkungen, Ergaenzungen oder Errata bitte der Uebersichtlichkeit halber in http://www.linux-club.de/ftopic65282.html posten.

=== [[Firewall]] ===

=== [[FTP-Server]] ===

=== [[Mail-Server]] ===

=== [[LAMP]] ===

[[Category:root Server]]Achtung: Dieses HOWTO ist noch im entstehen und als vorlaeufig (Draft) zu betrachten!

Dieses ist eine Sammlung von HOWTOs, die die wichtigstens Aktionen beschreiben, die bei einem Aufsetzen und Betreiben eines root Servers wenigstens durchzufuehren sind um einen in Grundzuegen sicheren root Server zu erhalten.

Exclamation Diese HOWTO's entlasten einen root Server Betreiber aber nicht von der Verantwortung für diesen Exclamation .

Wer zu dem Thema etwas beitragen will, der melde sich bitte per PN bei mir, da die Struktur beibehalten werden sollte, wie sie im hier angegegebenen Inhalt vorhanden ist.--[[Benutzer:Yehudi|Yehudi]] 17:38, 16. Aug 2006 (CEST)

=== [[Allgemein]] ===

Warum man ohne Linuxknowhow keinen root server mietet
http://www.linux-club.de/ftopic48323.html

Keine Ahnung aber root Server...
http://www.linux-club.de/ftopic63549.html

http://www.netsecond.net/howto/

http://www.linux-magazin.de/Artikel/ausgabe/2002/11/debserv/debserv.html

weitere Links folgen, und können auch gerne hizugefügt werden.

--[[Benutzer:Yehudi|Yehudi]] 17:37, 16. Aug 2006 (CEST)

=== [[Sicherer Zugriff mit putty und ssh key auf einen Linux Server]] ===
(Dieser Teil stammt von framp)
Dieses HOWTO beschreibt, welche Schritte notwendig sind um sicher von einem Windows Rechner per ssh mit putty und nur mit einem ssh key auf einen Linux Server mit SuSE zuzugreifen.

Saemtliche Schritte auf dem Server werden mittels putty mit Konsolbefehlen und keiner graphischen Oberflaeche beschrieben. Eine graphische Oberflaeche birgt eine Menge Sicherheitsprobleme und aus langer Linuxerfahrung leidgepruefter Serveradministratoren sollte keine graphische Oberflaeche (X, KDE, GNOME) auf einem Server installiert sein. Die konkrete Anleitung geht davon aus, dass keine Passwoerter mehr zur Authentifiziereung benutzt werden sondern asymmetrische keys. Diese kann man durch eine Passphrase sichern oder aber auch auf die Passphrase verzichten.
Der Vorteil bei keiner Passphrase ist, dass ein Zugriff immer ohne Passworteingabe moeglich ist. Der Nachteil ist, dass jeder, der den private key hat oder illegalerweise kopiert unbegrenzten Zugriff hat. Wer also ohne Passwort fahren will muss seine keys absolut sicher verwahren!

Saemtliche Konfigurationsaktionen auf dem Server werden per putty mit einem normalen user und seinem password gemacht. Ein paar Aenderungen benoetigen auch den user root mit seinem passwort. Erst am Ende nach erfolgreichem Test wird die Passwortauthentifizierung ausgeschaltet. Danach ist ein ssh Zugriff nur noch mit keys moeglich und jegliche Anmeldeversuche am Linux Server sind ohne key zum Scheitern verurteilt.

Achtung: Am Ende der Konfiguration kann sich aus Sicherheitsgruenden niemand mehr als root per ssh auf den Server anmelden! Dieses ist nur noch dem einen Benutzer der konfiguriert wurde mit seinem Key moeglich! Wenn root Zugriff benoetigt wird muss sich erst als normaler user anmelden und kann dann mit su - root Rechte bekommen. Sind Zugriffe von weiteren Usern notwendig sind die Steps 1-2 entsprechend zu wiederholen.

Konkret wurde die HOWTO Schritte mit putty 0.58 sowie OpenSSH 4.1p1 mit SuSE 10.0 erstellt. Konkret wird in der StepByStep Anleitung das Einrichten eines eines ssh Zugriffs mit putty fuer den user framp auf dem ssh Server obelix eingerichtet.

Folgende Schritte sind notwendig um sich letzendlich per putty und ssh key auf einen ssh Server anmelden zu koennen:

1) Erzeugen eines privaten und public keys mit putty

2) Anpassen des putty public keys an OpenSSH und kopieren des public OpenSSH Keys auf den Server und Aufnahme des keys in der authorized_keys Datei

3) Aenderung der sshd Konfiguration so dass keys akzeptiert benutzt werden

4) Einrichten des putty um mit dem key auf den Server zugreifen zu koennen und Test des Zugriffs mit key

5) Aenderung der sshd Konfiguration so dass keine passwoerter mehr erlaubt sind sondern nur moch mit keys moeglich ist

6) Hardening des sshd Servers, d.h. Pruefen von wichtigen Parametern auf die richtige sichere Einstellung

1) Erzeugen eines privaten und public keys mit putty

a) Starten des Programms puttygen auf dem WindowsClient. Dann ssh-2 RSA waehlen und number of bits in generated key auf 2048 setzen.
b) Druecken von Generate
c) Save the generated key druecken und sichern des public und private keys in C:\Program Files\putty als id_rsa und id_rsa_priv.ppk.

2) Anpassen des putty public keys an OpenSSH und kopieren des public OpenSSH Keys auf den Server und Aufnahme des keys in der authorized_keys Datei

a) Oeffnen eines Befehlsfensters und kopieren des putty public files id_rsa in id_rsa_linux mit dem befehl copy id_rsa id_rsa_linux[/i]
b) Mit einem Windows Editor muss die Datei id_rsa_linux sorgfaeltig geandert werden: Die ersten zwei Zeilen sowie die letzte Zeile muss
geloescht werden. Danach muessen alle Zeilen in eine Zeile zusammengefasst werden. Achtung! Es duerfen keine Leerzeichen auftauchen. Zum Schluss muss noch ssh-rsa am Anfang der Keyzeile eingefuegt werden. Achtung: Ein Leerzeichen am Ende von rsa! Die Zeile muss dann mit ssh-rsa AAAAB3 beginnen.
c) Oeffnen eines Befehlsfensters und C:\Program Files\putty>pscp id_rsa_linux framp@obelix:id_rsa aufrufen. Damit wird
der linux public key in das home Verzeichnis des users framp kopiert.
d) C:\Program Files\putty>putty framp@obelix:id_rsa aufrufen. Damit wird ein Befehlsfenster auf dem Server geoeffnet.
e) mkdir .ssh legt das .ssh Verzeichnis an wenn es nicht schon existiert
f) cat id_rsa >> .ssh/authorized_keys WICHTIG ! >> benutzen !!! Ansonsten werden schon existierende Authorisierungen geloescht.

3) Aenderung der sshd Konfiguration so dass keys akzeptiert benutzt werden

a) Im putty Fenster mit C:\Program Files\putty>pscp root@obelix:/etc/ssh/sshd_config sshd_config die sshd Konfigurationsdatei downloaden.
b) Editieren der Datei mit einem Windows Editor so dass die folgenden Parameter wie folgt gesetzt sind:
Code:
PubkeyAuthentication yes
RSAAuthentication no

c) Im putty Fenster mit C:\Program Files\putty>pscp sshd_config root@obelix:/etc/ssh/sshd_config die sshd Konfigurationsdatei uploaden.
d) Im Server Befehlsfenster welches in 2.a geoffnet wurde rcsshd restart eingeben.

4) Einrichten des putty um mit dem key auf den Server zugreifen zu koennen und Test des Zugriffs mit key

a) Starten des Programms putty auf dem WindowsClient.
b) Beim hostname framp@obelix eintragen (userid und Server name oder IP)
c) Zu Connection->SSH->Auth gehen und das Private key file for authentication fuellen mit C:\Program Files\putty\id_rsa_priv.ppk.
d) open und erscheint ein Befehlsfenster des Servers. U.U. muss noch die Passphrase eingegeben werden
e) Sichern des putty Profiles
f) Damit ist die ssh Verbindung mit key getestet und es kann die Passwortauthentifizierung ausgeschaltet werden.

5) Aenderung der sshd Konfiguration so dass keine Passwoerter mehr erlaubt sind sondern nur moch mit keys moeglich ist

a) Im putty Fenster mit C:\Program Files\putty>pscp root@obelix:/etc/sshd/sshd_config sshd_config die sshd Konfigurationsdatei downloaden.
b) Editieren der Datei mit einem Windows Editor so dass die folgenden Parameter wie folgt gesetzt sind:
Code:
PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no

c) Im putty Fenster mit C:\Program Files\putty>pscp sshd_config root@obelix:/etc/sshd/sshd_config die sshd Konfigurationsdatei uploaden.
d) Im Server Befehlsfenster welches in 2.a geoffnet wurde rcsshd restart eingeben.

6) Hardening des sshd Servers, d.h. Pruefen von wichtigen Parametern auf die richtige sichere Einstellung

Diese Schritte sind eigentlich nicht mehr notwendig da kein Zugriff ohne key mehr moeglich ist. Es kann aber immer sein
dass aus verschiedenen Gruenden doch wieder auf Passwoerter umgestellt wird (PasswordAuthentication yes). root Zugriff per ssh
sollte aus Sicherheitsgruenden immer ausgeschaltet sein. benoetigt man root recht kann man als normaler User per su -
root rechte erhalten oder man setzt sudo ein. Deshalb sollte ein jeder ssh Server auf alle Faelle noch wie folgt gesichert werden:

a) Im putty Fenster mit C:\Program Files\putty>pscp root@obelix:/etc/sshd/sshd_config sshd_config die sshd Konfigurationsdatei downloaden.
b) Editieren der Datei mit einem Windows Editor so dass die folgenden Parameter wie folgt gesetzt sind:
Code:
PermitRootLogin no
AllowGroups users
AllowUsers xxx yyy zzz (xxx, yyy und zzz sind user die per ssh zugreifen duerfen)
ClientAliveInterval 15
LoginGraceTime 10
PubkeyAuthentication yes
MaxAuthTries 3
MaxStartups 1
PrintLastLog yes
KeepAlive no

c) Im putty Fenster mit C:\Program Files\putty>pscp sshd_config root@obelix:/etc/sshd/sshd_config die sshd Konfigurationsdatei uploaden.
d) Im Server Befehlsfenster welches in 2.a geoffnet wurde rcsshd restart eingeben.

Als Grundlage fuer dieses HOWTO dienten u.A. folgende Threads:

[Howto] Einrichten von publikkeys unter der ssh
[TIP]ssh einrichten mit public-key Authentifizierung
[TIP]Wie sichere ich meinen ssh Server?
[TIP]Den eigenen Server absichern

Weitere Informtionen zu putty und OpenSSH:

putty homepage
Was Wikipedia zu putty sagt
OpenSSH homepage
OpenSSh manuals

Weitere Threads zu ssh spezifischen Fragen und Problemen:

Kontrolliertes Ausfuehren von Befehlen als root
SSH Angriffe
Host bei ssh Connection ablehnen

Des weiteren liefert eine Suche nach ssh im Forum diverse weitere Fragen und Antworten zu ssh die hier im HOWTO nicht behandelt wurden.

Last but not least lieferte http://www.framp.de/linux/?Netzwerk_Services:ssh_server wesentliche Teile zu diesem HOWTO.

Kommentare, Anmerkungen, Ergaenzungen oder Errata bitte der Uebersichtlichkeit halber in http://www.linux-club.de/ftopic65282.html posten.

=== [[Firewall]] ===

=== [[FTP-Server]] ===

=== [[Mail-Server]] ===

=== [[LAMP]] ===

[[Category:root Server]]

Hardware

2006-08-20T08:21:30Z

Carsten: /* Hardwareinfos / ACPI/APIC / Powermanagement / °C */

=== [[Hardwareinfos / ACPI/APIC / Powermanagement / °C]] ===

[http://www.linux-club.de/viewtopic.php?t=48556 Hardwareinfos / ACPI/APIC / Powermanagement / °C]

Dieses Howto behandelt hardwarenahe Probleme, wie: 
- Hardwareinformationen auslesen und interpretieren 
- Taktung eines Prozessors 
- Stromsparfunktionen 
- ACPI/APIC und Powermanagement 
- Temperaturüberwachung

Hardware

2006-08-17T16:50:10Z

Carsten: /* Hardwareinfos / ACPI/APIC / Powermanagement / °C */

=== [[Hardwareinfos / ACPI/APIC / Powermanagement / °C]] ===

[http://www.linux-club.de/viewtopic.php?t=48556 Hardwareinfos / ACPI/APIC / Powermanagement / °C]

Dieses Howto behandelt hardwarenahe Probleme, wie:
- Hardwareinformationen auslesen und interpretieren
- Taktung eines Prozessors
- Stromsparfunktionen
- ACPI/APIC und Powermanagement
- Temperaturüberwachung

Aktuelle Ereignisse

2006-08-17T16:37:34Z

Carsten: /* Die Howto's von folgenden Usern dürfen unter Autorennennung ins Wiki übertragen werden: */

Diesen Bereich können wir ja nutzen, um aktuelle Änderungen festzuhalten. Unter dem Diskussionsreiter können dann aktuelle Diskussionspunkte besprochen werden.

== Roadmap des Linux Club Wiki ==

1. Die nächsten Wochen wird es erst mal darum gehen, sämtliche vorhandenen HOWTO's ins Wiki zu importieren, dabei sind auf jedenfall die Autoren zu berücksichtigen. Das heißt erst per PN nachfragen, und dann übertragen. User die ihre Zustimmung gegeben haben sollten unter dem nächsten Punkt eingetragen werden, damit bei weiteren HOWTO's keine zusätzlichen Fragen entstehen. Es wäre empfehlenswert erst mal keine weiteren leeren Verzeichnisse zu erzeugen, um in der Phase des Transfers die Übersicht zu behalten.

2. Im nächsten Schritt wären dann Überarbeitungen von Inhalten und Strukturen angebracht, soweit sie nicht wärend des Transfers geschehen sind. Das Wiki soll an die Benutzerdatenbank vom Forum angekoppelt werden.

3. Danach wird das Wiki öffentlich zugänglich gemacht.--[[Benutzer:Yehudi|Yehudi]] 12:47, 16. Aug 2006 (CEST)

== Die Howto's von folgenden Usern dürfen unter Autorennennung ins Wiki übertragen werden: ==

*oc2pus
*TomcatMJ
*Rolle
*Griffin (Wegen mir auch ohne Autorennennung. Nach der dritten Änderung/Ergänzung durch andere User (immerhin ist das ein Wiki) macht eine solche Nennung eh keinen Sinn mehr bzw. wird sogar falsch.)
*Grothesk
*id3pr
*Saber_Rider
*pawe
*}-Tux-{
*TranceTip
*taki
*cero
*carsten