Implementation openssh¶
openssh ist eine Programmsammlung, die den ssh-Standard implementiert. Folgende Programme von openssh gibt es:
ssh
clientsshd
server daemonssh-keygen
Programm zum Erzeugen des private-pubic Schlüsselpaaresssh-add
undssh-agent
Werkzeuge zum Managen der Schlüssel zur Authentifikationssh-keyscan
Herunterladen der öffentlichen Schlüssel von den Servernsftp-server
Server-Prozess für Dateiübertragung via SFTPsftp
undscp
Client-Werkzeuge für die Dateiübertragung
ssh-Client¶
aus der ssh
man-Page:
"ssh (SSH client) is a program for logging into a remote machine and for executing commands on a remote machine.It is intended to provide secure encrypted communications between two untrusted hosts over an insecure network."
Mit ssh
kann man sich auf einem entfernten Rechner einloggen und hat typischerweise so eine Kommandozeile, wie eine bash-Shell, zur Verfügung. Dies leisten auch telnet
und rlogin
. Diese sollten aber aus Sicherheitsgründen in der Praxis nicht mehr verwendet werden (keine Verschlüsselung, unsicher Passwortaustausch).
Der Client verbindet sich mit einem Server indem eine Verbindung (connection) aufgebaut wird, eine Authentifikation stattfindet und dann eine (remote) Shell auf dem Client zur Verfügung steht (Pseudo-Terminal). Dabei gibt es verschiedene Möglichkeiten der Authentifikation (abhängig von der gegenseitigen Unterstützung und den Präferenzen des Client und Server), wie z.B. Passwörter oder Schlüsselaustausch (siehe unten Punkt "Logins ohne Passwort").
Auf dem Rechner, auf dem Sie sich einloggen, muss ein ssh-Server, d.h. ein ssh-Dämonenprozess (sshd
), laufen. Firewalls dürfen den TCP-Port 22 nicht blockieren.
Nutzung:
- falls der lokale
username
der gleiche ist, wie auf dem entfernten Rechner: ssh rechnername
- sonst
ssh username@rechnername
oderssh -l username rechnername
Beispiel: herta@ssh uranus-ai.f4.htw-berlin.de
ssh
öffnet eine TCP-Verbindung auf dem ssh-Standardport 22. Dann sendet der Server seinen
Fingerprint (Hash des Server Public-Key) zur Verifikation. Falls der Server dem Client noch nicht bekannt ist, erhält der/die Nutzer/in eine Warnung bzw. einen Hinweis, ob er den Fingerprint akzeptiert.
The authenticity of host 'uranus-ai.f4.htw-berlin.de (...)' can't be established. ... key fingerprint is ....
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added .... to the list of known hosts.
Die Idee dahinter ist, dass der/die Server-Administrator/in die Fingerprints im Vorfeld verteilt. So kann gewährleistet werden, dass sich der Client nicht mit einem falschen Server (Spoofing) verbindet (durch Prüfung der Identität des Servers). Würde man dann z.B. sein Passwort eingeben, hätte der Angreifer es durch diese Man-in-the-middle attack.
Oft wird allerdings dies nicht so gehandhabt und die Nutzer:innen akzeptieren in der Regel die Verbindung ohne Überprüfung. Die öffentlichen Server-Schlüssel werden (nach dem Akzeptieren) beim Client in der Datei ~/.ssh/known_hosts
eingetragen und beim nächsten Verbinden wird, die Verbindung ohne einen solchen Hinweis akzeptiert.
Die systemweite Konfiguration ist in /etc/ssh
. Im Verzeichnis ~/.ssh
liegen die öffentlichen und privaten Schlüssel der Nutzer/innen.
Verteilen der Schlüssel (optional)¶
Die Schlüssel werden typischerweise bei der Installation des ssh-Servers automatisch generiert. Für eine manuelle Installation/Ersetzen der Schlüssel siehe https://www.cyberciti.biz/faq/howto-regenerate-openssh-host-keys/
- Der öffentliche Schlüssel liegt dann typischerweise in der Datei
/etc/ssh/ssh_host_ecdsa_key.pub
- und der korrespondierende private Schüssel in
/etc/ssh/ssh_host_ecdsa_key
.
Beispieleintrag für ssh_host_ecdsa_key.pub
:
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBAqCgW5Mlx2VpC61acc0G4VMZUAauQDoK5xIzdHzdDLPXt0GqsoIw1fuwTSSzSy8RFmGU5PNHiWn0egoUwlXdc4= root@platon.christianherta.de
Der Fingerprint hiervon kann mittels ssh-keygen -l -f /etc/ssh/ssh_host_ecdsa_key.pub
angezeigt werden. Dies ist derselbe Fingerprint, der in obiger Warnmeldung The authenticity of host ..
dem/der Client-Nutzer:in angezeigt wird, wenn kein Eintrag in der known_hosts
-Datei vorhanden ist.
Mit dem Eintrag in ssh_host_ecdsa_key.pub
kann eine neuen Zeile zu ~/.ssh/known_hosts
auf einem Client-Rechner hinzugefügt werden, von dem man sich auf dem Server anmelden will:
[hostname] ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBAqCgW5Mlx2VpC61acc0G4VMZUAauQDoK5xIzdHzdDLPXt0GqsoIw1fuwTSSzSy8RFmGU5PNHiWn0egoUwlXdc4=
Hinweis: Die eckigen Klammern sind nötig!
Mit ssh-keygen -H -f ~/.ssh/known_hosts
sollte der Hostname auch anschließend durch einen Hash ersetzt werden, damit er nicht mehr im Klartext gelesen werden kann.
Nicht interaktive Nutzung¶
mittels:
ssh username@rechnername kommando optionen
Falls mehrere Kommandos ausgeführt werden sollen, kann man hierzu auch here-Dokumente verwenden:
ssh username@rechnername << EOF
kommando1
kommando2
...
EOF
Secure Copy scp
¶
Mit scp
lässt sich eine Datei zwischen Rechnern kopieren. scp
wird analog
cp
genutzt. Es wird lediglich zusätzlich bei der Quelle bzw. dem Ziel der
der Rechnername mit dem Nutzer:innennamen eingegeben.
Beispiele:
Vom lokalen Rechner auf entferneten Rechner kopieren:
scp mytext.txt herta@uranus-ai.f4.htw-berlin.de:/home/herta/meineTexte/
Vom entfernten Rechner auf lokalen Rechner kopieren:
scp herta@uranus-ai.f4.htw-berlin.de:/home/herta/meineTexte/mytext2.txt ~/meineEntwuerfe/
Secure File Transfer Protocol sftp
¶
Mit sftp
kann man sicher und verschlüsselt Dateien übertragen. Dies wird z.B. von Webhoster als Möglichkeit angeboten, Webseiten auf die Server hochzuladen. Hier ist oft ssh
bzw. scp
nicht aktiviert bzw. die Anfragen auf die entsprechenden Ports werden von einer Firewall geblockt.
Logins ohne Passwort¶
Mittels Public-Key Kryptographie kann man ssh
etc. auch nutzen, ohne dass
man jedes mal ein Passwort eingeben muss.
Dazu erzeugt man zuerst mittels ssh-keygen
ein entsprechenden Schlüsselpaar. Hier mit dem Elliptic Curve Digital Signature Algorithm (ECDSA):
ssh-keygen -t ecdsa
So werden tyischerweise zwei Dateien im versteckten Verzeichnis ~/.ssh/
angelegt:
~/.ssh/id_ecdsa
der private Schlüssel~/.ssh/id_ecdsa.pub
der korresponiderende öffentliche Schlüssel
Hier kann man eine Passphrase angeben, die den privaten Schlüssel mit einem symmetischen Verfahren verschlüsselt. Falls man hier eine Passphrase angibt, muss/müsste man diese jedesmal bei der Nutzung wieder eingeben, um den privaten Schlüssel auf dem lokalen Rechner verwenden zu können.
Hiermit hätte man nicht viel gewonnen, da man nun immer eine Passphrase eingeben muss. Abhilfe schafft hier der SSH-Agent. Dieser speichert die privaten Schlüssel und stellt diese bei den Logins im Hintergrund zur Verfügung. Die Schüssel können dazu mittels ssh-add
dem Agent hinzugefügt werden, mehr siehe z.B. https://wiki.ubuntuusers.de/SSH/#Der-SSH-Agent.
Nachdem man die Schlüsselpaare erzeugt hat, kopiert man mittels scp
den öffentichen Schlüssel auf den entferneten Rechner (login noch mit Passwort):
scp ~/.ssh/id_ecdsa.pub herta@uranus-ai.f4.htw-berlin.de:~/.ssh/id_ecdsa.pub
Anschließend muss man noch auf dem entferneten Rechner den öffentlichen Schlüssel an die Datei ~/.ssh/authorized_keys
anhängen, z.B. mit
ssh
cd ~/.ssh/
cat id_ecdsa.pub >> authorized_keys
EOF```
oder alternativ mit einer Befehlskette:
`cat .ssh/id_ecdsa.pub | ssh herta@uranus-ai.f4.htw-berlin.de 'cat >> ~/.ssh/authorized_keys'`
oder "bequemer" mit
`ssh-copy-id -i .ssh/id_ecdsa.pub ssh herta@uranus-ai.f4.htw-berlin.de`
Danach kann man sich ohne Passwort mit dem entfernten Rechner mit `ssh`, `scp` etc. verbinden.
Konfiguration ~/.ssh/ssh_config
¶
Hinweis: In der Datei ~/.ssh/ssh_config
lassen sich für die einzelnen Serververbindungen
verschiedene Konfigurationsoptionen zu Usernamen, Portforwarding etc. angeben, mehr siehe in der Manpage: man ssh_config
.
SSH-Tunnel: Local Port Forwarding¶
Mittels local port forwarding kann eine TCP-Verbindung verschlüsseln, indem man sie in einem "ssh-Tunnel" führt. D.h. die Verbindung läuft zwischen dem Client und dem Server über den Standard ssh-Port (TCP-IP). Lokal und remote können beliebige Ports angesprochen werden. Auf dem Server natürlich der Port des Anwendungsdienstes. Ein SSH-Tunnel kann auch hilfreich sein, wenn die meisten Ports durch eine Firewall geblockt sind, ssh aber möglich ist.
Einen solchen Tunnel kan man durch folgenden Befehl einrichten:
ssh -f -N -C -L 9999:uranus-ai.f4.htw-berlin:10555 -l herta uranus-ai.f4.htw-berlin
-f
"forkt" den ssh-Prozess in den Hintergrund und die shell wird nicht blockiert, sondern kann genutzt werden.-N
bewirkt, dass auf dem Remote Rechner kein Kommando ausgeführt wird. Wir wollen ja nur den Tunnel aufbauen.-C
komprimiert die Verbindung, sodass die Datenübertragung beschleunigt wird.-L 9999:uranus-ai.f4.htw-berlin:10555
bewirkt, dass bei einer "TCP-Anfrage" auf den lokalen Port 9999 des Client diese in den ssh-Tunnel umgeleitet wird. Die Anfrage wird auf dem entfernten Rechner (hieruranus-ai.f4.htw-berlin
) an Port 10555 wetergeleitet.- hinter
-l
folgt der Nutzername auf dem entfernten Rechner.
So wird eine Anfrage auf dem lokalen Rechner localhost:9999
zu einer Anfrage auf dem Server zu localhost:10555
(localhost
entspricht hier dem Server uranus-ai.f4.htw-berlin
).
Neben dem local port forwarding gibt es noch weitere Möglichkeiten von ssh-Tunneln, siehe z.B.
SSH-Server¶
Damit man sich auf einer entfernten Maschine per ssh
etc. einloggen kann, müssen dort natürlich die entsprechenen Dienste installiert und konfiguriert sein.
openssh-server
: Server-Software/etc/ssh/sshd_config
: Ort der Konfigurationsdatei
mehr siehe z.B. https://wiki.ubuntuusers.de/SSH/#Der-SSH-Server
Übung¶
Benutzen Sie das untenstehende Vagrantfile in dem zwei virtuelle Maschinen (node1 und node2) gestartet werden können (sshd
ist bei vagrant-Boxen immer installiert und gestartet). Sehen Sie sich das Vagrantfile im Detail an.
Sie können sich auf den Maschinen mittels einloggen:
vagrant ssh node1
vagrant ssh node2
- Loggen Sie sich auf einer der Maschinen ein. Können Sie die andere Maschine mit ping erreichen?
- Verbinden sich sich aus einer Maschine mit der anderen Maschine per ssh (Standardeinstellung user: vagrant, passwort: vagrant)
- Erstellen Sie eine Datei in einer virt. Maschine und kopieren Sie diese Datei in die andere Maschine per scp.
- Probieren Sie Logins ohne Passwort aus, d.h. gehen Sie wie oben unter dem Punkt Logins ohne Passwort beschrieben vor.
# -*- mode: ruby -*-
# vi: set ft=ruby :
BOX_IMAGE = "generic/ubuntu2004"
NODE_COUNT = 2
# https://githubmemory.com/repo/hashicorp/vagrant/issues/12553
VM_NETMASK="21"
Vagrant.configure("2") do |config|
(1..NODE_COUNT).each do |i|
config.vm.define "node#{i}" do |subconfig|
subconfig.vm.box = BOX_IMAGE
subconfig.vm.hostname = "node#{i}"
subconfig.vm.network "private_network",
ip:"192.168.56.#{i + 10}",
netmask:VM_NETMASK
end
end
config.vm.provision "shell", inline: <<-SHELL
# add IPs to /etc/hosts
for i in {1..#{NODE_COUNT}}; do
echo "192.168.56.$((i+10))\tnode${i}">>/etc/hosts
done
SHELL
end
Beachten Sie, dass
- hier für die beiden Rechner die IPs $192.168.56.11/21$ und $192.168.56.12/21$ erhalten. Dies können Sie z.B. überprüfen mittels einloggen und
ip addr show
. - In die Datei
/etc/hosts
werden die entsprechenden Einträge durch das inline bash-Skript vorgenommen, sodass sie im privaten Netz mit den Namen "node1" bzw. "node2" erreichbar sind.- bevor das Bash-Skript erzeugt wird, wird die Ruby-Konfigurationsvariable
#{NODE_COUNT}
zu einer Zahl aufgelöst wird (Ruby String Interpolation). - zu
/etc/hosts
siehe http://christianherta.de/lehre/praktischeInformatik/Netzwerke/Netzwerke_2.html
- bevor das Bash-Skript erzeugt wird, wird die Ruby-Konfigurationsvariable