SSH#

SSH (Secure Shell) ist ein Protokoll, mit Hife dessen man eine verschlüsselte Verbindung zu entfernten Rechnern aufbauen kann, um sich dort z.B. einzuloggen (ssh), Dateien zu kopieren (scp) oder auch beliebige Netzverbindungen (z.B. eine X11-Session) zu verschlüsseln. Es ist auch möglich, mit festen, auf dem Clientrechner hinterlegten Authentifizierungs-Schlüsseln zu arbeiten, so daß man sich nicht mit einem Passwort anmelden muss (gut z.B. für Skripte).

Die gängig benutzte SSH-Implementation ist OpenSSH (http://www.openssh.com/de). Eine sehr gute SSH-Implementation unter Windows ist PuTTY.

Eine gute deutschsprachige Wiki-Seite zum Thema gibt es auf LinuxWiki:OpenSSH.

Siehe auch SshMitXserver.

Mit ssh kann man auch ein VPN "für Arme" bauen. Ein kurzes Howto steht z.B: unter http://alinux.washcoll.edu/docs/sshtunnel/ssh.txt (siehe auch SecureShellTunnel)

Einloggen per SSH-Schlüssel#

Da ich dieses immer wieder benötige (und auch immer hier suche), hier eine Kurzanleitung, wie man sich per SSH-Key auf einem fremden Rechner einloggen kann. Dazu muss man zuerst einen eigenen RSA-Schlüssel erzeugen. Diesen muss man dann auf dem Rechner, auf dem man sich einloggen will, hinterlegen. Gibt man bei der Erzeugung des Schlüssels keine Passphrase ein, funktioniert das dann ganz ohne Passwort (kann also z.B. auch von Skripten - aber auch von jedem Hacker - benutzt werden). 

  # Zuerst Schlüssel erzeugen
  ssh-keygen -b 2048 -t rsa
  # ... entweder umständlich, aber besser erklärend, was wirklich passiert
  ssh remoteuser@remotehost.example.net "umask 077; mkdir -p .ssh; cat >> .ssh/authorized_keys" <.ssh/id_rsa.pub
  # ... oder automatisch und elegant
  ssh-copy-id -i .ssh/id_rsa.pub remoteuser@remotehost.example.net

Übrigens kann man beim passwortlosen Einloggen per Schlüssel noch einige Restriktionen setzen und insbesondere einen fest auszuführenden Befehl angeben. Hierzu steht einiges auf der sshd-manpage sowie ein Beispiel auf der Seite zu meinem BackupServer. -- ThomasBayen

X11-Forwarding #

Wenn man openssh richtig konfiguriert, kann man auf dem fernen Rechner ganz normal X11-Programme starten. Dazu muss man auf dem Server in /etc/ssh/sshd_config die Einstellung "ForwardX11 yes" vornehmen. Je nach Distribution muss man seinem Client auch sagen, daß er Forwarding benutzen kann. Das kann man global in /etc/ssh/ssh_config, aber auch in den benutzerspezifischen Einstellungen in .ssh/... bzw. per Kommandozeilenoption "-o".

Will auf dem fernen Rechner einfach kein X11 funktionieren, weil keine DISPLAY-Variable gesetzt ist, könnte das daran liegen, daß man auf dem Server einen minimalen Satz an X11-Bibliotheken (z.B. das xauth-Programm) benötigt. Das kann man übrigens mit "ssh -v ..." feststellen. Unter Debian muss man dazu das Paket xbase-clients auf dem Server installieren (mit allen Abhängigkeiten ca. 6.5MB).

Benutzername setzen #

Wenn man sich regelmaessig auf einem anderen Rechner einloggt, auf dem man einen anderen Benutzernamen hat, kann es lästig sein, diesen immer angeben zu müssen. Man kann hier einen Default-Namen setzen. Dazu benutzt man die Möglichkeit, Einstellungen vom Servernamen abhängig zu machen. Das geht auch in der Datei ~/.ssh/config und sieht in etwa so aus: 

  Host terminalserver
       User thomasbayen

  Host ssh.sourceforge.net
       User myaccount

  Host meinserver
       User root

  Host *.intranet
       User thomas

Socks Proxy #

Wer von unterwegs auf einem vertrauenswürdigen Weg Internetseiten abrufen will, braucht nur einen ssh-Zugang zu einem vertrauenswürdigen ssh-Host. Darüber kann mit 

  ssh -D8090 -N meinhost.example.com

ein Socks-Tunnel aufgebaut werden.

In der Proxy-Konfiguration des Internet-Browsers trägt man dazu localhost:8090 ein (Port aus der Beispielzeile oben).

VPN mit SSH #

Auch ein richtiges VPN kann man per SSH einrichten. Hierzu kann ein voll einsatzfähiges Netzwerkdevice getunnelt werden (nicht nur ein einzelner Port geforwarded). Das ssh-Kommando erzeugt allerdings nur zwei tun-DEvices und konfiguriert diese nicht. Mit etwas Liebe kann man das aber alles in einem kurzen Skript (oder sogar in einem langen Einzeiler) kombinieren. Außerdem gibt es ein Programm namens "autossh", das den Tunnel immer wieder neu startet (wenn er mal zusammenbricht). Als Anregung kann man dieses Skript nehmen: 

#!/bin/bash

COMMAND=$1
GATEWAY=entry.dyndns.mydomain.org
GATEWAY_PORT=22
IP_LOCAL=192.168.2.2
IP_SERVER=192.168.2.1
NETMASK=255.255.255.0
TUN_LOCAL=0
TUN_SERVER=1

#########################################################################################
function startvpn() {
  autossh -f -M 0 -w $TUN_LOCAL:$TUN_SERVER -p $GATEWAY_PORT $GATEWAY \
  -o ExitOnForwardFailure=yes -o ServerAliveInterval=60 -o PermitLocalCommand=yes \
  -o LocalCommand="ifconfig tun$TUN_LOCAL $IP_LOCAL netmask $NETMASK; route add -net 192.168.223.0/24 gw $IP_SERVER dev tun$TUN_LOCAL" \
    "ifconfig tun$TUN_SERVER $IP_SERVER netmask $NETMASK; sleep 99999999"
}

function stopvpn() {
  killall autossh
}

function checkvpn() {
  ifconfig tun$TUN_LOCAL
  ping -c 1 -W 3 $IP_SERVER
}

#########################################################################################

if [ "start" == $COMMAND ]; then
  startvpn
elif [ "stop" == $COMMAND ]; then
  stopvpn
elif [ "check" == $COMMAND ]; then
  checkvpn
else
  echo "usage:"
  echo "startvpn.sh [start|stop|check]"
fi

SSH Agent Forwarding #

Wenn man sich per SChlüssel passwortlos einloggt, erhöht das den Komfort und die Sicherheit. Allerdings möchte man dann manchmal von dem Rechner, auf den man sich eingeloggt hat, weiter auf einen anderen Rechner gelangen. Und dann fangen alle Authentifizierungs-Probleme wieder von vorne an.

Ein Beispiel ist, das man sich aus dem Internet mit der IP-ADresse des heimischen Netzwerks verbindet. Der Router (wenn man ihn entsprechend konfiguriert hat) leitet einen an eine Firewall oder einen DMS-Rechner weiter, der sozzusagen den Eingang ins lokale Netz darstellt. Von da aus möchte man dann aber z.B. auf seinen persönlichen Arbeitsplatz kommen. Also braucht man da schon wieder ein PAsswort bzw. einen Schlüssel. Nicht so schlau ist es natürlich, dafür einen Schlüssel auf dem DMZ-Rechner zu generieren - weil der ja potentiell angreifbar sein kann.

Für dieses Problem benutzt man Agent Forwarding. Im groben funktioniert das so, das auf dem lokalen System ein kleiner Server namens ssh-agent gestartet wird, der die privaten und öffentlichen Schlüssel (die normalerweise in ~/.ssh/ liegen) einliest und verwaltet. Über einige Umgebungsdvariablen veröffentlciht man, wie dieser zu erreichen ist (über einen Dateinamen eines Unix-Sockets, aber das braucht man im Grunde nicht zu wissen, um ihn zu benutzen). Jetzt kann man das ssh-Programm mit einer Option starten (-A), so das es bei der Suche nach Schlüsseln nicht nur in der normalen Datei sucht, sondern auch den ssh-agent befragt. So weit so gut. Der besondere Trick ist nun aber, das ssh nach dem Verbindungsaufbau mit dem fremden Rechner dort ebenfalls einen Socket einrichtet und die Umgebungsvariablen entsprechend setzt. Dort läuft allerdings kein eigener ssh-agent, sondern Anfragen an diesen Socket werden weitergeleitet an den lokalen Rechner und von dessen ssh-agent bearbeitet. Auf diese Art kann ein ssh-Befehl auf dem entfernten Rechner (sagen wir: dem DMZ-Eingang in unser heimisches Netzwerk), der ebenfalls mit der -A Option gestartet wird, den Socket benutzen und die Schlüssel prüfen lassen. Dabei verlässt der private Schlüssel allerdings niemals den eigenen PC, den man vor sich stehen hat.

Auf jeder normalen Linux-Distribution wird eine X-Session (also der graphische Desktop, auf dem man normalerweise arbeitet, in der Form gestartet, das als Mutterprozeß eine Instanz von ssh-agent läuft. Falls nicht (das ist z.B. so, wenn man in Debian Linux auf einer Textkonsole arbeitet), muss man den Agent manuell starten und die Variablen übernehmen. Das geht - für eine einmalige Anwendung - recht elegant mit

Tags:  Ssh, VPN
This particular version was published on 11-Jan-2020 10:59 by ThomasBayen.  Top