Kapitel 6. Netzwerkapplikationen

Moderne E-Mail-Dienste unterliegen einigen Einschränkungen, um die Belästigung/Schädigung durch Spam (unerwünschte und unverlangte E-Mails) zu minimieren.

Die Gründe hierfür sind:

Einige Programme im Debian-System erwarten, dass auf den /usr/sbin/sendmail-Befehl zugegriffen werden kann, um in der Standardeinstellung (oder auch in benutzerspezifisch angepassten Konfigurationen) E-Mails verschicken zu können. Der Grund hierfür ist, dass der Mail-Dienst auf UNIX-Systemen historisch gesehen wie folgt funktioniert:

Der OpenSSH-Daemon unterstützt lediglich das SSH-Protokoll 2.

Bitte lesen Sie "/usr/share/doc/openssh-client/README.Debian.gz", ssh(1), sshd(8), ssh-agent(1), ssh-keygen(1), ssh-add(1) und ssh-agent(1).

	Warnung
	Wenn Sie den OpenSSH-Server laufen lassen möchten, darf "/etc/ssh/sshd_not_to_be_run" nicht vorhanden sein. Aktivieren Sie NICHT rhost-basierte Authentifizierung (HostbasedAuthentication in /etc/ssh/sshd_config).

Mit folgenden Befehlen starten Sie eine ssh(1)-Verbindung von einem Client:

Wenn Sie auf dem lokalen und dem fernen Rechner den gleichen Benutzernamen verwenden, können Sie "username@" weglassen.

Man kann es vermeiden, sich Passwörter für ferne Systeme merken zu müssen, indem man "PubkeyAuthentication" (SSH-2-Protokoll) nutzt.

Setzen Sie dazu auf dem fernen System die entsprechenden Einträge: "PubkeyAuthentication yes" in "/etc/ssh/sshd_config".

Erzeugen Sie die Authentifizierungs-Schlüssel lokal und installieren Sie sie wie folgt auf dem fernen System:

$ ssh-keygen -t rsa
$ cat .ssh/id_rsa.pub | ssh user1@remote "cat - >>.ssh/authorized_keys"

Sie können weitere Optionen zu den Einträgen in "~/.ssh/authorized_keys" hinzufügen, um die erlaubten Rechner einzuschränken und spezifische Befehle ausführen. Lesen Sie dazu sshd(8) - "AUTHORIZED_KEYS FILE FORMAT".

Es ist sicherer, Ihren geheimen SSH-Authentifizierungs-Schlüssel mit einer Passphrase zu schützen. Falls Sie noch keine Passphrase vergeben haben, verwenden Sie dazu "ssh-keygen -p".

Legen Sie Ihren öffentlichen SSH-Schlüssel (z.B. "~/.ssh/id_rsa.pub") wie folgt in "~/.ssh/authorized_keys" auf dem fernen Server ab, und zwar über eine passwort-basierte Verbindung zum Server, wie oben beschrieben.

$ ssh-agent bash
$ ssh-add ~/.ssh/id_rsa
Enter passphrase for /home/username/.ssh/id_rsa:
Identity added: /home/username/.ssh/id_rsa (/home/username/.ssh/id_rsa)

Es ist kein Passwort für das ferne System zur Ausführung des nächsten Befehls mehr nötig:

$ scp foo username@remote.host:foo

Drücken Sie Strg-D, um die ssh-agent-Sitzung zu beenden.

Für den X-Server führt das normale Debian-Start-Skript ssh-agent als Eltern-Prozess aus. Sie müssen ssh-add daher nur einmal ausführen. Für weitere Details lesen Sie ssh-agent(1) und ssh-add(1).

Wenn Sie ein SSH-Shell-Konto auf einem Server mit vernünftigen DNS-Einstellungen haben, können Sie eine Mail, die Sie auf Ihrem Arbeitsplatzrechner vorbereitet haben, von dem fernen Rechner aus als E-Mail verschicken:

$ ssh username@example.org /usr/sbin/sendmail -bm -ti -f "username@example.org" < mail_data.txt

Um für eine Verbindung von Port 4025 auf localhost zu Port 25 auf remote-server (einem fernen Server) oder für eine Verbindung von Port 4110 auf localhost zu Port 110 auf remote-server via ssh eine Weiterleitung aufzubauen, führen Sie auf dem lokalen Rechner (localhost) folgendes aus:

# ssh -q -L 4025:remote-server:25 4110:remote-server:110 username@remote-server

Dies ist ein sicherer Weg für Verbindungen zu SMTP-/POP3-Servern über das Internet. Setzen Sie in "/etc/ssh/sshd_config" auf dem fernen Server den Wert für "AllowTcpForwarding" auf "yes".

Falls Sie Probleme haben, kontrollieren Sie die Zugriffsrechte der Konfigurationsdateien und starten Sie ssh mit der Option "-v".

Nutzen Sie die Option "-p", wenn Sie root sind und Probleme mit einer Firewall haben; dadurch wird die Verwendung der Ports 1 - 1023 auf dem Server vermieden.

Wenn ssh-Verbindungen zu einem fernen Rechner plötzlich nicht mehr funktionieren, könnte dies auf Spielereien des Systemadministrators zurückzuführen sein, höchstwahrscheinlich Änderungen am "host_key" im Rahmen von Systemwartungsarbeiten. Nachdem Sie sich versichert haben, dass dies der Fall ist und niemand versucht, den fernen Rechner über einen cleveren Hack zu imitieren, können Sie die Verbindung wiedererlangen, indem Sie den "host_key"-Eintrag in der "~/.ssh/known_hosts"-Datei auf dem lokalen Rechner entfernen.