ssh oder secure shell bezeichnet ein kryptographisches netzwerkprotokoll für den sicheren betrieb von netzwerkdiensten über ungesicherte netzwerke.
Inhaltsverzeichnis
Einstellungen des config auf dem server
Für die benutzung von ssh braucht es den ssh-server und ein ssh-client. damit der server sicher ist, muss dieser etwas speziell konfiguiert werden. Dazu verwendet man das /etc/ssh/sshd_config und trägt folgende defintion ein:
Port 22
KexAlgorithms curve25519-sha256@libssh.org
Protocol 2
HostKey /etc/ssh/ssh_host_ed25519_key
Ciphers chacha20-poly1305@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
UsePrivilegeSeparation yes
SyslogFacility AUTHPRIV
LogLevel VERBOSE
LoginGraceTime 120
PermitRootLogin no
StrictModes yes
PubkeyAuthentication yes
AllowGroups ssh-user
HostbasedAuthentication no
IgnoreRhosts yes
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding yes
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
ClientAliveInterval 60
ClientAliveCountMax 10000
Banner /etc/ssh/sshd-banner
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
Entfernen der vorhandenen schlüssel
Damit das ganze aber nun auch mit sicheren schlüssel betrieben wird, sollten alle bisherigen schlüssel auf dem server entfernt werden:
# cd /etc/ssh/
# rm ssh_host_*key*
Komplett ohne rücksicht werden alle schlüssel gelöscht, die brauchen wir nicht mehr - wir wollen ein schlüssel und das ein sicherer, ohne irgendwelche backdoors, ein sauberer ed25519.
Generieren eines neuen schlüssels
Nun wird mit dem nachstehenden befehl ein neuer schlüssel (ed25519) für den server generiert:
# ssh-keygen -t ed25519 -f ssh_host_ed25519_key -N "" < /dev/null
Benutzer vorbereiten für den ssh-zugriff
Erstellen der gruppe ssh-user
Schlussendlich müssen wir noch eine gruppe ssh-user definieren und die richtigen benutzer darauf zuweisen:
# groupadd ssh-user
Benutzer der gruppe ssh-user zuweisen
Damit ssh sicherer wird, müssen alle ssh-benutzer in der gruppe ssh-user angehören. ein benutzer kan wie folgt hinzugefügt werden:
# usermod -a -G ssh-user [username]
Benutzer aus einer gruppe entfernen
Ab und zu kommt es vor, dass man ein benutzer einer gruppe entfernen muss. Dies kann mit folgendem befehl ausgeführt werden:
# gpasswd --delete [username] [group]
Der ssh-client
Die erstellung eines sicheren schlüssels
Für die clients sollten nur sichere schlüssel verwendet werden. derzeit sollte man nur den curve25519 verwenden
ssh-keygen -o -a 100 -t ed25519 -C "$(hostname)-$(date +'%d-%m-%Y')"
Die option “-a 100” besagt, dass der schlüssel 100 umdrehungen berechnen soll. 256 umdrehugnen ist das maximum, ist aber nicht wirklich notwendig, da die differnez zwischen 100 und 256 in der berechnung der umdrehungen nur noch in einem sehr kleinen bereich sich ändert. Wird die option weggelassen, werden 16 umdrehungen berechnet, was für eine normale sicherheit bereits genügt.
Eine erstellung des schlüssels kann wie folgt aussehen:
jc@l32:~/.ssh$ ssh-keygen -o -a 100 -t ed25519 -C "$(hostname)-$(date +'%d-%m-%Y')"
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/jc/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/jc/.ssh/id_ed25519
Your public key has been saved in /home/jc/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:OwmvAL6bqyvoPg2MARIiOgylkP+78GD68qowu3eJqWI l32-12-04-2022
The key's randomart image is:
+--[ED25519 256]--+
|*+. |
|@. |
|*o |
|... |
|o... . S |
|.+ .. o o |
|+ Bo.o = |
|*E+B+. . . |
|^&O+o.. |
+----[SHA256]-----+
In der regel speichert man diese ausgabe als refernz in ein textfile hostkey-gen.txt
Mit der generierung dieses schlüssels werden 2 files generiert:
- id_ed25519
- id_ed25519.pub
Das file id_ed25519 ist der private schlüssel und soll tunlichst immer sicher aufbewahrt werden!
Im file id_ed25519.pub befindet sich der öffentliche schlüssel und kann an andere weitergegeben werden. Der inhalt von id_ed25519.pub muss auf dem ssh-server beim entsprechenden ssh-benutzer in den ordner in das file ~/.ssh/authorized_keys abgelegt werden.
mein persönlicher öffentlicher schlüssel sieht bspw. wie folgt aus:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKkf0OpaGc1UtaiaVTK8+htHDm8JF0419XjwCmnr/nuV l32-12-04-2022
Die ssh config
Für den client kann ein file erstellt werden, in welchem er sich seine verbindungen selbst konfigurieren kann. ein config erleichtert den späteren zugriff auf die unterschiedlichen ssh-server. Das file muss im homeverzeichnis des benutzer im file ~/.ssh/config abgelegt werden. Der inhalt des ~/.ssh/config sieht wie folgt aus:
Host jump
Hostname 10.0.0.253
User pi
Port 22
Mit dieser defintion kann später der server jump mit dem befehl
$ ssh jump
aufgerufen werden. Die ssh-verbdinung wird nach dem passwort des zertifikates und allenfalls nach dem passwort des benutzers (je nachdem wie der sever konfiguriert wurde) selbständig nachfragen. Wurde das passwort des zertifikates in einer sitzung (unter linux) einmal eingegeben, verweilt diese information im linux-system für die dauer der laufenden session! Somit muss für alle anderen ssh-aufrufe das passwort für das zertifikat nicht mehr eingegeben werden. Aus sicht der sicherheit ist dann nur noch der server verantwortlich , indem er bspw. für den benutzer noch speziell nach dem passwort fragen kann (ist aber in seiner konfiguration definiert).
Aufruf mit einem fremdem Schlüssel
Es ist möglich, dass man eine ssh-verbindung mit einem fremdem schlüssel aufruft - diese situation kann auftreten, vor allem wenn man “früher” einmal ein schlüssel für ein server hatte und vergessen hat, sein neuer schlüssel zu registrieren. deshlab muss man nicht alles umstellen an seiner heutigen defintion, sondern kann einfach den alten schlüssel wie folgt einsetzen:
$ ssh -i ~/.ssh/old/id_ecdsa jump
Ebenso kann man das in seinem file ~/.ssh/config wie folgt angeben:
Host srvstation
Hostname 10.0.3.90
Port 10101
User jc
IdentityFile /home/it/.ssh/old/id_ecdsa
x11-forwarding
Manchmal ist es sinnvoll, wenn man das x11-forwarding aktiviert. Dies ist bspw. der fall, wenn man sich zu einem ssh-server verbindet, welcher in wirklichkeit ein client ist, d.h. über eine grafische oberfläche verfügt. Nun will man bspw. dort ein dateimanager (nautilus) grafisch aufrufen. Also braucht es für die ssh-verbdinung optionen die man mitgeben kann um dieses ziel zu erreichen:
$ ssh -X -C jump
Mit der option -x wir der x11 (grafische ansicht) weitergeleitet. Die option -c steht dann für die kompression, damit es «schneller» geht um die grafische information durch den ssh-tunnel zu leiten werden die informationen komprimiert.
Den SSH testen
Wird die konfiguration geändert kann ein test sehr hilfreich sein:
# sshd -t
Solltet ihr den test nicht ausführen wollen, seid aber via ssh verbunden und habt an der konfiguration änderungen vorgenommen. Wenn es schief geht, werde ihr dann anschliessend euch auf eine reise zum server vor ort begegeben, da ihr ansonsten kein zugriff mehr habt. Also macht es sinn, ein test der konfiguration durchzuführen.