Administratorhandbuch:SSHServer: Unterschied zwischen den Versionen

Version vom 4. März 2008, 21:51 Uhr

Seite fertig: Sollten Sie Änderungsvorschläge oder Ergänzungen zu diesem Punkt haben, dann nutzen Sie bitte den Punkt Diskussion (oben).

Konfiguration beim Arktur-Schulserver

Der SSH-Server auf dem Arktur-Schulserver wird standardmäßig bei jedem Systemstart aktiviert. Noch während der Installation werden über einen Zufallsgenerator mit einem bestimmten Primzahlenalgorithmus zwei Schlüssel generiert: Ein öffentlicher Schlüssel (public host key), der im Netzwerk zum Verschlüsseln verteilt wird, und ein privater Schlüssel (private host key), der zum Entschlüsseln der Daten nötig ist. Diese beiden Schlüssel werden schon bei der Erstinstallation generiert und auf dem Arktur-Schulserver im Verzeichnis /etc/ssh zur weiteren Verwendung gespeichert und dienen der Verschlüsselung während des Login-Vorgangs.

Normalerweise ist der SSH-Dienst auf dem Arktur-Schulserver folgerndermaßen konfiguriert

Jeder Benutzer mit einem Vollzugriff kann sich über SSH auf den Server einloggen.
Der SSH-Zugriff ist von allen Clients des Netzwerks möglich.
Die Administrationszugänge root und sysadm sind über SSH im Netzwerk freigegeben.
Die Firewall beschränkt den SSH-Zugriff auf Client-Rechner innerhalb der Schule
Die Freigabe für eine Fernwartung von außen wird über System verwalten > Firewall > SSH-Zugriff erlauben eingeschaltet

Alle Einstellungen für den SSH-Server nehmen Sie in der Datei /etc/ssh/sshd_config vor. Bitte erstellen Sie vor irgendwelchen Änderungen unbedingt eine Sicherheitskopie der laufenden funktionierenden Konfiguration!

cp /etc/ssh/sshd_config /etc/ssh/sshd_config_20050619

Varianten

SSH-Zugang mit Passwort

Der Serverzugang mit Passwort-Authentifizierung ist das beim Arktur-Schulserver voreingestellte Verfahren. Das Passwort wird bei der Eingabe nicht angezeigt, wobei auch keine Ersatzzeichen zu sehen sind. Der Vorgang ist für alle Betriebssysteme gleich. Es wird die Serveradresse 192.168.0.1 und das Protokoll SSH angegeben sowie der Benutzername, mit dem man sich anmelden möchte. Danach wird man vom Server nach seinem Passwort gefragt und erhält nach einer Berechtigungsprüfung seinen Zugang (.... oder eben auch nicht, wenn man nicht berechtigt ist).

client-a100:~ meier$ ssh 192.168.0.1
meier@192.168.0.1's password: 
Last login: Sat Jun 18 16:23:04 2005 from client-a10.schulnetz.xy
Linux 2.4.30 i686 
Viel Spass!
meier@Arktur:~>

Warnung: In der Normalkonfiguration des Arktur-Schulservers ist der Zugang als root oder als sysadm über SSH standardmäßig freigeschaltet. Dies bedeutet eine zusätzliche Gefahr für die Sicherheit, vor allem wenn in der Firewall der SSH-Zugang von außen her freigegeben wurde. SSH sorgt ja lediglich dafür, dass die Kommunikation (inkl. Anmeldung) verschlüsselt wird, es genügt aber die Kenntnis von Benutzernamen und Kennwort, um sich bei Arktur anzumelden.

Wenn nun also ein Schüler (oder sonstwer) das Kennwort eines Lehrers mit SSH-Zugang erspäht, kann er sich direkt anmelden. - Wenn ein Lehrer ein unsicheres Kennwort (wie "Name des Hundes, leicht variiert") gewählt hat, hat ein Schüler durch Erraten des Kennworts nach X Fehlversuchen Zugriff. - Durch Brute-Force-Attacken können evtl. Kennwörter erraten werden.

Als zusätzliche Sicherheitsmaßnahme sollte man den Zugang auf bestimmte User einschränken.

SSH-Zugang mit Schlüsseldatei (PublicKey)

Weitaus sicherer ist es, wenn ein berechtigter Benutzer seine Berechtigung durch das Vorhandensein eines digitalen Schlüssels nachweisen muss. Der Benutzer erzeugt selber ein Schlüsselpaar (private/public key). Der öffentliche Schlüssel wird auf den Server übertragen, der private Schlüssel muss auf dem Client vorhanden sein.

Ziel dieses Abschnitts in der Anleitung ist es, die Authentifizierung auf das PublicKey-Verfahren umzustellen. Damit entfällt die Gefahr, dass ein Schüler das Administrator-Passwort ausspäht oder dass ein Hacker die Möglichkeit eines Wörterbuchangriffs auf den Server hat.

Schlüssel generieren (Mac OS X, Linux)

Für das PublicKey-Verfahren muss jeder zugelassene Benutzer ein RSA-Schlüsselpaar generieren. Im folgenden Ablauf sehen Sie die Generierung mit Mac OS X - absolut identisch funktioniert dieser Vorgang bei Linux-Client. Eine Darstellung für Windows-Schlüssel folgt in einem eigenen Abschnitt

iMac-1000:~ meier$ ssh-keygen -t rsa -b 2048
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/meier/.ssh/id_rsa):
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /Users/meier/.ssh/id_rsa.
Your public key has been saved in /Users/meier/.ssh/id_rsa.pub.
The key fingerprint is:
9c:12:15:64:54:1e:ab:73:27:d9:26:22:b3:44:9e:53 meier@iMac-1000
iMac-1000:~ meier$ ls -al ~/.ssh
total 24
drwx------   5 meier  meier   170 19 Jun 12:29 .
drwxr-xr-x  37 meier  meier  1258 19 Jun 12:10 ..
-rw-------   1 meier  meier  1751 19 Jun 12:29 id_rsa
-rw-r--r--   1 meier  meier   409 19 Jun 12:29 id_rsa.pub
-rw-r--r--   1 meier  meier  2714 19 Jun 11:59 known_hosts
iMac-1000:~ meier$

Das mit ssh-keygen erzeugte Schlüsselpaar dient später als einzige Authorisierungsquelle für den Zugang zum Arktur-Schulserver. Sie sollten also unbedingt das erzeugte Schlüsselpaar sicher aufbewahren und niemandem Zugriff darauf gestatten! Der öffentliche Schlüssel (PublicKey) befindet in der Datei id_rsa.pub im Ordner ~/.ssh und muss auf den Server übertragen werden.

Schlüssel generieren (Windows)

Zum Generieren eines Schlüssels mit Windows gibt es auf der PuTTY-Internetseite ein spezielles Programm PuTTYgen, das Sie sich separat herunterladen müssen. Es benötigt keinerlei Installation.

Mit PuTTYgen erzeugen Sie einen Schlüssel im Format SSH2-RSA mit der Länge 2048 Bits. Anschließend speichern Sie den privaten und den öffentlichen Schlüssel auf den lokalen Computer ab, wobei das Schlüsselpaar unbedingt sicher aufzubewahren ist.

Der öffentliche Schlüssel (PublicKey) befindet zum Kopieren im mittleren Programmfenster und muss in einer Textdatei (am besten mit dem Namen id_rsa.pub .... weil alle weiteren Abschitte diesen bei OpenSSH voreingestellten Namen verwenden) auf den Server übertragen werden. Die von PuTTYgen erzeugte öffentliche Schlüsseldatei hat ein für den Arktur-Schulserver nicht verarbeitbares Format.

Abbildung: Windows - Zugangsschlüssel erzeugen mit PuTTYgen

Schlüssel auf den Arktur-Schulserver kopieren

Um den Serverzugriff über das PublicKey-Verfahren abzusichern, muss der öffentliche Schlüssel nun auf den Server übertragen und in die dortige Datei ~/.ssh/authorized_keys eingebunden werden. Dazu kopieren Sie Ihre persönliche Datei id_rsa.pub (oder wie immer auch sie genannt wurde) in Ihr Homeverzeichnis auf den Arktur-Schulserver und schreiben anschießend deren Inhalt zusätzlich in die Datei ~/.ssh/authorized_keys .

Das Kopieren auf den Arktur-Schulserver kann jeder Benutzer mit Vollzugriff selber erledigen, da ein Fernzugriff in der Arktur-Konfiguration per Passwort-Authentifizierung für jeden Benutzer mit Vollzugriff freigegeben ist. Nach dem beschriebenen Kopiervorgang ist die Authentifizierung für genau diesen einen Benutzer umgestellt.

meier@Arktur:~> ll
insgesamt 1176
-rw-------    1 meier   lehrer     373174 2005-06-02 23:34 Bild 1.pdf
-rw-------    1 meier   lehrer     399999 2005-06-02 23:42 Bild 2.pdf
-rw-------    1 meier   lehrer     400025 2005-06-02 23:43 Bild 3.pdf
-rw-------    1 meier   lehrer        409 2005-06-19 12:30 id_rsa.pub
drwxr-xr-x+   2 meier   root         4096 2005-06-03 00:28 www-pub
meier@Arktur:~> md .ssh
meier@Arktur:~> cat id_rsa.pub >> .ssh/authorized_keys
meier@Arktur:~>

Hat man keinen Vollzugriff auf den Arktur-Schulserver, so hat man auch keinen Zugang über SSH ... weder über Passwort- noch über PublicKey-Authentifizierung.

Wenn der Benutzer die private Schlüsseldatei verliert, kommt er selber nicht mehr auf den Server ... die Passwort-Authentifizierung wurde bei dieser Aktion automatisch ausgeschaltet. In einem solchen Fall muss der Administrator die Datei ~/.ssh/authorized_keys löschen. (Wie funktionierte das eigentlich bei Baron Münchhausen, der das sicher selber erledigt hätte??)

Benutzeranmeldung

Nach der Umschaltung auf PublicKey-Authentifizierung sieht die Benutzeranmeldung folgendermaßen aus. Wurde eine Passphrase für die Benutzung der Schlüsseldatei angegeben, wird diese jetzt hier als zusätzliche Sicherheit abgefragt.

client-a100:~ meier$ ssh 192.168.0.1
Enter passphrase for key '/home/meier/.ssh/id_rsa': 
Last login: Sun Jun 19 16:29:04 2005 from client-a100.schulnetz.xy
Linux 2.4.30 i686 
Viel Spass!
meier@Arktur:~>

SSH-Zugriff zusätzlich absichern

Um den SSH-Server zusätzlich abzusichern, loggen Sie sich zur Anpassung der Konfiguration auf dem Server als root ein und öffnen Sie die Datei /etc/ssh/sshd_config mit einem Texteditor zur Bearbeitung:

joe /etc/ssh/sshd_config

Der SSH-Server wird sicherer, indem man ausschließlich das Verbindungsprotokoll SSH2 zulässt .... SSH1 hat entscheidende Sicherheitslücken. Die Angaben hinter dem # sind Voreinstellungen .... die einzige Änderung ist Protocol 2

#Protocol 2,1 
Protocol 2
....
#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys
....
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
....
# Change to no to disable s/key passwords 
#ChallengeResponseAuthentication yes

Speichern Sie die gemachte Änderung in der Datei ab. Nach einem Neustart des SSH-Servers ist das PublicKey-Verfahren aktiviert:

/etc/init.d/sshd restart

Möchte man ausschließlich die PublicKey-Authentifizierung erlauben, dann muss man die Passwort-Authentifizierung ausschalten .... das Kommentarzeichen # muss man löschen und yes in no wechseln ... fertig ... Neustart des SSH-Servers

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

Nun werden Benutzer ohne PublicKey zwar immer noch nach dem Passwort gefragt - aber anmelden kann man sich auch mit dem korrekten Passwort eines Nutzers nicht mehr. Nur noch Nutzer mit einem auf dem System hinterlegten PublicKey haben Zugang zum Server. In diesem Fall muss aber der Administrator die Datei ~/.ssh/authorized_keys für jeden Benutzer bearbeiten.

Freigabe des root-Zugangs über PublicKey

Der besonders sensible root-Zugang zum Server ist auf die bisher beschriebene Art nicht in die PublicKey-Authentifizierung einzubeziehen. Solange die Passwort-Authentifizierung nicht ausdrücklich abgeschaltet wird, haben nämlich alle Benutzer ohne PublicKey-Eintrag automatisch weiterhin Zugang über ihr Passwort. Ein wichtiger Schritt wäre es deswegen, den root-Zugang ohne Passwort konsequent zu verbieten. Dies bringt eine erhebliche Steigerung der Serversicherheit mit sich.

Um den root-Zugang dennoch für einzelne Administratoren freizuschalten, wird deren öffentlicher Schlüssel in die Datei /root/.ssh/authorized_keys kopiert. Die freigeschalteten Administratoren benötigen keine Kenntnis des root-Passwortes für den Arktur-Schulserver.

Um die Eintragungen durchführen zu dürfen, muss man unbedingt als root angemeldet sein. Im Beispiel wird davon ausgegangen, dass der Lehrer meier seinen öffentlichen Schlüssel in seinem Verzeichnis unter .ssh abgelegt hat.

cat /home/Lehrer/meier/.ssh/id_rsa.pub >> /root/.ssh/authorized_keys

Danach kann sich der Benutzer meier von außen als Benutzer root auf dem Arktur-Schulserver einloggen. Beim Verbinden wählt man den gewünschten Server-Benutzer über den Zusatz -lroot (-l ist ein kleines -L). Man muss natürlich zur Authentifizierung die Passphrase von meier eingeben, wird aber nach dem Verbindungsaufbau als root angemeldet .... dies erkennt man am Server-Prompt.

client-a100:~ meier$ ssh 192.168.0.1 -lroot
Enter passphrase for key '/home/meier/.ssh/id_rsa': 
Last login: Mon Jun 20 10:17:06 2005 from client-a100.schulnetz.xy
Linux 2.4.30 i686 
Viel Spass!
Arktur:/~ #

Beim root-Zugangs mit Schlüssel-Authentifizierung wird die Sicherheit besonders gewährleistet, weil der berechtigte Benutzer beim Zugang das root-Passwort nicht benutzt und durch den Eintrag seines persönlichen Schlüssels in der Datei /root/.ssh/authorized_keys besonders bekannt gemacht worden sein muss.

Plattformübergreifende Nutzung der Schlüsseldatei

Der auf dem Server laufende SSH-Dämon erfordert die Angabe der Schlüssel im OpenSSH-Format. Der öffentliche Schlüssel kann ausschließlich in diesem Format auf den Server übertragen werden und dort eingebunden werden.

In den Betriebssystemen Mac OS X und Linux wird genau dieses OpenSSH-Format erzeugt, wenn man mit ssh-keygen das Schlüsselpaar generiert. Der öffentliche Schlüssel ist also ohne Änderung bereits fertig. In Windows generiert man mit PuTTYgen in einem eigenen, nicht konformen Format, findet allerdings das OpenSSH-Format in einem Anzeigefenster zum Kopieren vor.

Von entscheidender Wichtigkeit ist auch die Übertragbarkeit des privaten Schlüssels von einem Rechner auf den anderen. Angenommen sei der nicht unwahrscheinliche Fall, dass ein Benutzer mit zwei unterschiedlichen Rechnern über SSH auf den Server zugreifen möchte. Ist nämlich die PublicKey-Authetifizierung aktiviert, so bekommt der Benutzer nicht mehr ohne Schlüsseldatei einen SSH-Zugriff (... auch von einem anderen Rechner aus nicht!!)

Wenn sich die beiden Rechner im gleichen Netzwerk befinden, mit dem gleichen Betriebssystem arbeiten und die private Schlüsseldatei im Heimatverzeichnis des Benutzers liegt, sollte es kein Problem geben. Dies sind aber drei Bedingungen, die alle gleichzeitig erfüllt sein müssen, um sich keine weiteren Gedanken machen zu müssen. (... aber wehe, wenn nicht!!)

Ganz anders wird es, wenn der Benutzer von Rechnern mit unterschiedlichen Betriebssystemen aus über SSH auf den Server zugreifen möchte .... oder wenn er per Fernzugriff von zu Hause aus einen SSH -Zugang zum Server aufbauen möchte. Im ersten Fall könnte es sein, dass kein betriebssystemkompatibler Schlüssel vorhanden ist, und im zweiten Fall, dass der Schlüssel von außen unerreichbar auf dem Server liegt (.... in beiden Fällen ist dann guter Rat teuer!!)

Abbildung: Windows - PuTTYgen importiert Schlüssel von OpenSSH

Bei der Lösung hilft das Programm PuTTYgen, das ja auch die nichtkompatiblen Schlüssel erzeugt. Dieses Programm besitzt die Fähigkeit, die Schlüssel im OpenSSH-Format zu importieren und zu exportieren. Um auf der sicheren Seite zu sein, sollten Sie unbedingt drei Schlüssel besitzen ... den privaten und den öffentlichen im OpenSSH-Format und zusätzlich den privaten im PuTTY-Format. Alle drei Schlüssel sichern Sie am besten so, dass Sie sie sicher aufbewahren können (CD) und immer im direkten Zugriff haben (Memoystick, Diskette, CD).

SSH-Zugang beschränken

AllowUsers - ausgesuchten Benutzern den Zugriff erlauben

Möchte man den SSH-Zugriff auf bestimmte Benutzer einschränken, so kann man eine zusätzliche Zeile in die Konfigurationsdatei /etc/ssh/sshd_config einfügen, in der nur die berechtigten Benutzer eingetragen sind.

# Authentication:
AllowUsers mueller meier schulze
#LoginGraceTime 2m
#PermitRootLogin yes

Nach einem Neustart des SSH-Servers dürfen nur noch die Benutzer mueller, meier und schulze über SSH auf den Server zugreifen. Alle übrigen Benutzer sind ausgeschlossen. Dies ist sinnvoll, wenn man die Einwahl als Benutzer root oder sysadm unbedingt verhindern möchte.

Die Benutzerrechte von root und sysadm erhält man durch einen Wechsel des Benutzers

meier@Arktur:~> su
Password: 
Arktur:/home/Lehrer/meier #

bzw.

meier@Arktur:~> su sysadm
Password:

DenyUsers - bestimmten Benutzern den Zugriff verbieten

Es ist auch möglich, einzelne User explizit vom Serverzugriff über SSH auszuschließen. Natürlich ist es auch hier möglich, dass root und sysadm über einen nachträglichen Benutzerwechsel erreichbar sind.

# Authentication:
DenyUsers root sysadm
#LoginGraceTime 2m
#PermitRootLogin yes

PermitRootLogin without-password - Administratorzugriff nur mit PublicKey

Die sicherlich beste Einschränkung für die Administration des Arktur-Schulservers ist die Möglichkeit, die Administrationsbenutzer root und sysadm nicht mehr nur mit der Passwort-Autentifizierung zugreifen zu lassen. Zu groß ist die Gefahr, dass irgendein Schüler das Passwort errät oder klaut und damit unendlich viel Unfug anstellt. Mit der Einstellung PermitRootLogin without-password müssen alle Administrationsbenutzer über ihren Schlüsseleintrag in der Datei /root/.ssh/authorized_keys ausgewiesen sein ... auch der Benutzer internet gehört dazu.

# Authentication:
DenyUsers meier schulze
#LoginGraceTime 2m
#PermitRootLogin yes
PermitRootLogin without-password
#StrictModes yes

Einschränkung auf bestimmte Arbeitsplätze

In einigen Anleitungen zum Arktur-Schulserver findet man folgende Angaben für /etc/hosts.allow

# SSH nur lokal erlauben
sshd:           192.168., 127.:    ALLOW

oder

# SSH-Zugriff nur von einen einzigen Arbeitsplatz erlauben
sshd:           192.168.0.10:      ALLOW

Damit soll man zusätzlich die SSH-Zugriffe auf bestimmte Arbeitsplätze einschränken können. Beim Arktur-Schulserver 4.0 ist dies mit Absicht nicht so. Der Daemon sshd soll als Serverdienst unabhängig vom Wrapper tcpd laufen. Nur damit sind Sicherheitseinstellungen direkt an den sshd zu binden. Auf diese Weise ist eine Fernwartung über SSH auch dann noch möglich, wenn ein Administrator unbedacht die Restriktionen in der /etc/hosts.deny bzw. /etc/hosts.allow zu eng gesetzt hat.

Die Einschränkungen in der Konfigurationsdatei /etc/hosts.allow funktionieren also ausdrücklich nicht! Es lohnt sich deswegen nicht, in dieser Datei im Zusammenhang mit SSH irgendwelche Manipulationen zu versuchen. Der SSH-Server müsste dafür mit einer zusätzlichen Option kompiliert sein. http://www.snailbook.com/faq/libwrap.auto.html

Links

http://www.debianhowto.de/howto-archiv/de/sshconfig - SSH HOWTO - den Secure Shell Dämon sicher einrichten
http://www.chiark.greenend.org.uk/~sgtatham/putty/ - PuTTY - A Free Telnet/SSH Client
http://www.openssh.com - OpenSSH - Keeping Your Communiqués Secret
http://www.snailbook.com - SSH = The Secure Shell - The Definitive Guide -

zurück | Hauptseite

Version vom 10. Oktober 2005, 18:19 Uhr (Quelltext anzeigen) Schoffer (Diskussion \| Beiträge) (fertig gesetzt)	Version vom 4. März 2008, 21:51 Uhr (Quelltext anzeigen) Schoffer (Diskussion \| Beiträge) K (1 Versionen) Zum nächsten Versionsunterschied →
(kein Unterschied)