***    Der SSH-Client
( sh-add ~/.ssh/id_rsahttps://wiki.ubuntuusers.de/SSH/ )
( https://wiki.archlinux.de/title/SSH-Authentifizierung_mit_Schl%C3%BCsselpaaren )

Anmeldung: ssh user@sol-1 
Wenn username derselbe dann genügt: ssh server 

Man kann auch einfach einen Befehl anhängen, der anstelle der Terminal-Session 
ausgeführt wird. Nach der Ausführung des Befehls wird die SSH-Session dann 
automatisch beendet:  ssh server cat /etc/issue 

Oder etwas komplizierter - eine Datensicherung machen ("backup"):

user@client:~$ ssh root@server 'cd /etc; tar czvf - network/' | cat > etc_network_backup.tar.gz 
output:
Password:
network/
network/interfaces
network/if-post-down.d/
network/if-pre-up.d/
network/if-up.d/
network/if-down.d/
network/options
network/interfaces.pre-etherconf
network/interfaces.1
network/run

- Host-Schlüssel, der jeden SSH-Server eindeutig identifiziert
Greift man zum ersten Mal auf einen bestimmten Server zu, kennt man diesen 
Schlüssel natürlich noch nicht. (Außer man hat ihn sich auf anderen Wegen im 
Voraus besorgt.) Wird abgefragt, ob man dem server traut  Zeigt den eindeutigen Fingerprint an.

Den Fingerprint für das Schlüsselpaar abfragen:
ssh-add -l

Bei allen weiteren Kontakten stellt das ssh-Programm jedoch von nun an 
über asymmetrische Kryptografie sicher, dass der Server auch über den richtigen 
privaten Schlüssel verfügt, der zum öffentlichen, in der Datei ~/.ssh/known_hosts 
abgelegten passt, und verweigert im Zweifelsfall den Verbindungsaufbau.

falls sich der Schlüssel aus legitimen Gründen einmal geändert haben sollte:
ssh-keygen -f <DATEI> -R <HOST> 
ssh-keygen -f "/home/tux/.ssh/known_hosts" -R 172.217.22.227 
loescht den Schluessel.

Sollte die Verbindung nicht mehr reagieren, z.B. wenn der SSH-Server heruntergefahren 
wurde, lässt sich der SSH-Client mit der Eingabe von "~." (nacheinander) beenden.


- Daemon ssh-agent auf client starten und Schlüssel anmelden
Aufruf kann der /etc/profile hinzugefügt werden, damit es bei jeder Session gestartet wird:
# echo 'eval `ssh-agent`' >> /etc/profile

Um sich ohne Passwort, jedoch mit einem Passwort geschützten Schlüsselpaar, auf seinem 
SSH-Server anzumelden, muss user auf dem client das dem ssh-agent mitteilen:
$ ssh-add ~/.ssh/id_rsa
Enter passphrase for /home/user/.ssh/id_rsa:
Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)

Nun wird das Passwort abgefragt und auch gleich gespeichert und schon kann 
man sich ohne Passwort, jedoch mit einem Passwort geschützten Schlüsselpaar, 
auf seinem SSH-Server anmelden.

Das einzige Problem, das bleibt, ist, dass für jede neue SSH-Verbindung, die 
aufgebaut werden soll, auch eine neue SSH-Agent-Instanz gestartet werden muss. 
Abhilfe dafür kann ein Alias oder das Programm Keychain im nächsten Absatz schaffen.



***   SSH-Agent und X11-SSH-Askpass benutzen
Für diese Methode muss der SSH-Agent direkt beim Starten einer neuen XSession 
mit gestartet werden. Er wird automatisch mit der XSession beendet.


-------------------------

***   SSH-Daemon (sshd) gegen Attacken sichern
https://www.strassenprogrammierer.de/ssh-daemon-sshd-gegen-attacken-sichern_tipp_363.html
sshd_config:  (kein root-login!)
   PermitRootLogin no
   X11Forwarding no
   MaxStartups 3:30:10

***   SSH-Server auf dem Raspberry Pi absichern
https://www.elektronik-kompendium.de/sites/raspberry-pi/2006101.htm
sshd_config:
   Protocol 2
   PermitEmptyPasswords no
   PermitRootLogin no
sudo service ssh restart

- Speziellen Benutzer für den SSH-Zugriff erstellen

- SSH-Zugriff für eine bestimmte Benutzer-Gruppe freigeben

- Berechtigung für "sudo" einschränken
https://www.elektronik-kompendium.de/sites/raspberry-pi/2002231.htm

- Angreifer im lokalen Netzwerk

- IP-Binding
ListenAddress 192.168.1.5
ListenAddress fe80::5

- Benutzer bei mehreren fehlerhaften Authentifizierungen sperren
MaxStartups 10:30:60
MaxStartups  3:30:10


- Secure Secure Shell
Eine gute Quelle, um die Secure Shell weiter abzusichern:
https://stribika.github.io/2015/01/04/secure-secure-shell.html

---------------

***    Public-Key-Verfahren

-  Login-Passwort und SSH-Passphrase
Auf client vorhanden z.B.: /home/gerd/.ssh/authorized_keys + id_rsa + id_rsa.pub.
Auf server muss /home/gerd/.ssh/authorized_keys vorhanden sein, um passphrase abzufragen.
Wenn auf dem server /home/gerd/.ssh/authorized_keys nicht vorhanden ist, wird normales 
login-password abgefragt.


- Sicherheit, Firewall s. extra Datei