Eine typische Secure Shell-Sitzung

Der Secure Shell-Dämon (sshd) wird normalerweise beim Neustart zusammen mit den Netzwerkdiensten gestartet. Der Dämon wartet auf Verbindungen von Clients. Eine Secure Shell-Sitzung beginnt, sobald ein Benutzer den Befehl ssh, scp oder sftp ausführt. Für jede eingehende Verbindung wird ein neuer sshd-Dämon gestartet. Diese Dämonen übernehmen den Schlüsselaustausch, die Verschlüsselung, Authentifizierung, Befehlsausführung und den Datenaustausch mit dem Client. Die Sitzungsmerkmale werden von clientseitigen und serverseitigen Konfigurationsdateien bestimmt. Befehlszeilenargumente können die Einstellungen in den Konfigurationsdateien überschreiben.

Der Client und der Server müssen sich gegenseitig authentifizieren. Nach einer erfolgreichen Authentifizierung kann der Benutzer Remote-Befehle ausführen und Daten zwischen Hosts kopieren.

Sitzungsmerkmale in Secure Shell

Das serverseitige Verhalten des sshd-Dämons wird durch Schlüsselworteinstellungen in der Datei /etc/ssh/sshd_config gesteuert. Die Datei sshd_config steuert, welche Arten der Authentifizierung für den Zugriff auf den Server zulässig sind. Das serverseitige Verhalten kann auch durch Befehlszeilenoptionen gesteuert werden, wenn der sshd-Dämon gestartet wird.

Das clientseitige Verhalten wird durch Secure Shell-Schlüsselwörter mit folgender Prioritätsreihenfolge gesteuert:

• Befehlszeilenoptionen

• Konfigurationsdatei ~/.ssh/config des Benutzers

• Systemweite Konfigurationsdatei /etc/ssh/ssh_config

Beispielsweise kann ein Benutzer eine systemweite Ciphers-Konfigurationseinstellung überschreiben, die aes128–ctr bevorzugt, indem er -c aes256–ctr,aes128-ctr,arcfour in der Befehlszeile angibt. Die erste Verschlüsselung, aes256–ctr, wird nun bevorzugt.

Authentifizierung und Schlüsselaustausch in Secure Shell

Die Secure Shell-Protokolle v1 und v2 unterstützen Client-Benutzer/Host-Authentifizierung und Server-Host-Authentifizierung. Bei beiden Protokollen werden kryptografische Sitzungsschlüssel zum Schutz von Secure Shell-Sitzungen ausgetauscht. Jedes Protokoll bietet verschiedene Methoden zur Authentifizierung und zum Austausch von Schlüsseln. Einige Methoden sind optional Secure Shell unterstützt eine Reihe von Client-Authentifizierungsmechanismen, die in Tabelle 19-1 aufgeführt werden. Server werden mithilfe von bekannten öffentlichen Hostschlüsseln authentifiziert.

In Version 1 des Protokolls unterstützt Secure Shell Benutzerauthentifizierung mit Passwörtern. Das Protokoll unterstützt außerdem öffentliche Benutzerschlüssel und die Authentifizierung mit öffentlichen Schlüsseln vertrauenswürdiger Hosts. Die Serverauthentifizierung erfolgt mit einem öffentlichen Hostschlüssel. In Version 1 des Protokolls sind alle öffentlichen Schlüssel RSA-Schlüssel. Um Sitzungsschlüssel auszutauschen, wird ein temporärer Serverschlüssel benötigt, der regelmäßig neu generiert wird.

In Version 2 des Protokolls unterstützt Secure Shell die Benutzerauthentifizierung und eine generische interaktive Authentifizierung, die normalerweise Passwörter umfasst. Das Protokoll unterstützt außerdem die Authentifizierung mit öffentlichen Benutzerschlüsseln und öffentlichen Schlüsseln vertrauenswürdiger Hosts. Bei den Schlüsseln kann es sich um RSA- oder DSA-Schlüssel handeln. Der Austausch von Sitzungsschlüsseln besteht darin, dass temporäre Diffie-Hellman-Schlüssel ausgetauscht werden, die bei der Serverauthentifizierung signiert werden. Außerdem kann Secure Shell GSS-Berechtigungsnachweise zur Authentifizierung verwenden.

Erhalt von GSS-Berechtigungsnachweisen in Secure Shell

Um die GSS-API zur Authentifizierung in Secure Shell zu verwenden, muss der Server über GSS-API-Verarbeiter-Berechtigungsnachweise und der Client über GSS-API-Initiator-Berechtigungsnachweise verfügen. Unterstützt werden mech_dh und mech_krb5.

Für mech_dh verfügt der Server über GSS-API-Verarbeiter-Berechtigungsnachweise, wenn root den Befehl keylogin ausgeführt hat.

Für mech_krb5 verfügt der Server über GSS-API-Verarbeiter-Berechtigungsnachweise, wenn das Host-Hauptelement, das dem Server entspricht, über einen gültigen Eintrag in /etc/krb5/krb5.keytab verfügt.

Der Client verfügt über Initiator-Berechtigungsnachweise für mech_dh, wenn eine der folgenden Aktionen ausgeführt wurde:

• Der Befehl keylogin wurde ausgeführt.

• Das Modul pam_dhkeys wird in der Datei pam.conf verwendet.

Der Client verfügt über Initiator-Berechtigungsnachweise für mech_krb5, wenn eine der folgenden Aktionen ausgeführt wurde:

• Der Befehl kinit wurde ausgeführt.

• Das Modul pam_krb5 wird in der Datei pam.conf verwendet.

Informationen zur Verwendung von mech_dh in Secure RPC finden Sie unter Kapitel 16Verwenden von Authentifizierungsservices (Aufgaben). Informationen zur Verwendung von mech_krb5 finden Sie in Kapitel 21Einführung zum Kerberos-Service. Weitere Informationen zu Mechanismen finden Sie auf den Manpages mech(4) und mech_spnego(5).

Befehlsausführung und Datenweiterleitung in Secure Shell

Nachdem die Authentifizierung abgeschlossen ist, kann der Benutzer Secure Shell verwenden, normalerweise durch Anfordern einer Shell oder Ausführen eines Befehls. Mithilfe der ssh-Befehlsoptionen kann der Benutzer Anforderungen stellen. Zu den Anforderungen kann die Zuordnung einer Pseudo-TTY, die Weiterleitung von X11-Verbindungen oder TCP/IP-Verbindungen oder das Aktivieren eines ssh-agent-Authentifizierungsprogramms über eine sichere Verbindung gehören.

Eine Benutzersitzung besteht aus folgenden grundlegenden Komponenten:

1. Der Benutzer fordert eine Shell oder die Ausführung eines Befehls an, wodurch der Sitzungsmodus gestartet wird.

   In diesem Modus sendet oder empfängt das Client-Terminal Daten. Der Server sendet Daten über die Shell oder mithilfe eines Befehls.

2. Wenn die Datenübertragung abgeschlossen ist, wird das Benutzerprogramm geschlossen.

3. Jegliche X11- und TCP/IP-Weiterleitung wird beendet, ausgenommen für die bereits vorhandenen Verbindungen. Vorhandene X11- und TCP/IP-Verbindungen bleiben geöffnet.

4. Der Server sendet eine Statusmeldung an den Client. Wenn alle Verbindungen, wie noch offene weitergeleitete Ports, geschlossen sind, trennt der Client die Verbindung zum Server. Dann wird der Client beendet.