gniki

Diese Seite ist nicht editierbar. Sie können den Quelltext sehen, jedoch nicht verändern. Kontaktieren Sie den Administrator, wenn Sie glauben, dass hier ein Fehler vorliegt.
====== SSH-Verbindungen ======
Secure Shell oder SSH bezeichnet ein kryptographisches Netzwerkprotokoll für den sicheren Betrieb von Netzwerkdiensten über ungesicherte Netzwerke. \\

Hinweise: https://wiki.ubuntuusers.de/SSH/ \\

<WRAP important>
Empfehlenswerte Einstellungen für einen Server, der über das Internet erreichbar ist (z.B. ein Webserver):
  * Den direkten Zugang für "root" von Außen ausschließen.
  * Den Zugang mit Passwort von Außen generell ausschließen.
  * Zugang nur mit Schlüssel.
  * Optional z.B. für Webserver: Beschränkter Zugriff über SFTP auf definierte Bereiche (HTML-Files …)
</WRAP>

===== SSH-Schlüssel =====
Für den Zugriff mit einem Schlüssel muss zunächst einer generiert werden. Dabei wird i.d.R. ein Schlüsselpaar generiert, das aus einem privaten und einem öffentlichen Schlüssel besteht und das miteinander agiert. Der private Schlüssel bleibt lokal und geheim, der öffentliche wird an externe Systeme verteilt.

==== SSH-Key unter Linux generieren ====
Auf einem (lokalen) Linux-System das Programm open-ssh-client installieren und Schlüssel generieren.

  sudo apt install openssh-client

  ssh-keygen -t rsa -b 4096

t = Typ (hier rsa) \\
b = Schlüssellänge (hier 4096 Bit) \\

Schlüssel liegt automatisch im (versteckten) Verzeichnis ~/.ssh/ \\
Den Schlüssel ohne Passwort zu generieren, vereinfacht das Login, da dann später kein Passwort mehr angegeben werden muss. Wird der private Schlüssel zu einem anderen System transferiert, z.B. per E-Mail – **keine gute Idee!** — birgt das Abhör-Gefahren. 

<WRAP important>
**Der private Schlüssel muss unbedingt vor fremdem Zugriff geschützt bleiben!**
</WRAP>
Es werden 2 Dateien angelegt:
  * id_rsa (privater Schlüssel)
  * id_rsa.pub (öffentlicher Schlüssel)

Der öffentliche Schlüssel wird auf das entfernte System übertragen, auf das zugegriffen werden soll. \\
Der private Schlüssel bleibt auf dem lokal System, auf dem er generiert wurde. Für jedes weitere (lokale) System sollte jeweils ein eigener Schlüssel generiert werden.\\

Zur Übertragung auf einen Server muss der User bereits dort angelegt sein und der Zugriff ohne Schlüssel (mit Passwort) muss temporär freigegeben werden. \\
Den öffentlichen Schlüssel (id_rsa.pub) wie folgt auf den Server übertragen:

  ssh-copy-id <USER>@<REMOTEHOST>

Ersetzen: <USER> und <REMOTEHOST> \\
Das Passwort vom <REMOTEHOST> wird abgefragt. \\

Im <REMOTEHOST>-Home-Verzeichnis vom <USER> liegt die Datei **~/.ssh/authorized_keys**. In diese Datei werden die gültigen Public-Keys (automatisch) eingetragen. Das Verzeichnis ist versteckt.\\
Parallel wird auf dem lokalen (Linux-)Rechner der (neue) entfernte Host in der Datei **~/.ssh/known_hosts** aufgenommen. Ist der Host dort bereits enthalten, ggf. mit anderem Schlüssel, muss er zunächst aus dieser Datei entfertn werden -> Siehe Fehlermeldung und Hinweise.

==== SSH-Key mit Putty generieren ====
Alternativ ist es möglich, mit dem Programm [[https://www.puttygen.com/download-putty|PuTTYgen]], z.B. unter Windows, einen Schlüssel zu erstellen. Es ist möglich, den angezeigten Block direkt aus PuTTYgen heraus in die entfernte **~/.ssh/authorized_keys** des Servers zu kopieren - ggf. die Datei neu erstellen.

Die Datei hat folgende Struktur (alles hintereinander):

  * ssh-rsa  << dieser Text und 1 Leerzeichen\\ 
  * rsa-pub-key << der eigentliche Schlüssel aus Puttygen \\  
  * Key Kommentar << Im Textblock von puttygen bereits enthalten\\

Liegt bereits ein SSH-Key vor (z.B. erstellt wie oben beschrieben), kann dieser auch für den Zugriff mit Putty oder SFTP umgewandelt werden. \\
Programm PuTTYgen: Private-key importieren und als PuTTY-private-key speichern. \\

Schlüssel von PuTTY können von diversen Systemen (FileZilla, etc.) genutzt werden, sofern der Public-Key im entfernten Server hinterlegt ist. Da dieser Schlüssel kopier- und übertragbar ist, sollte er immer zusätzlich mit einem Passwort geschützt sein. 

Für Konvertierung Programm **PuTTYgen** aufrufen.

  - Load an existing private key file
  - Save private key >> jetzt mit Endung .ppk

===== Server konfigurieren =====
==== SSH-Zugriffe ====
Ggf. vorher Installieren
  sudo apt-get install openssh-server

  sudo nano /etc/ssh/sshd_config

  ClientAliveInterval 1200
  ClientAliveCountMax 3
  
  PermitRootLogin no
  PasswordAuthentication no
  Subsystem sftp internal-sftp

<WRAP important>
Um sich nicht selber auszusperren: \\
PermitRootLogin nur deaktivieren, sofern ein anderer User Zugriff hat und PasswordAuthentication nur abschalten, sofern der Zugriff mit dem Key-File auch klappt! \\

Möglicherweise gibt es Parameter in einem Unterordner, die die Regeln überschreiben. Möglich, dass dort in einer *.conf-Datei, \\
z.B. /etc/ssh/sshd_config.d/50-cloud-init.conf, hinterlegt ist: **PasswordAuthentication yes** \\
Das muss dann angepasst werden.
</WRAP>
The **ClientAliveInterval** parameter specifies the time in seconds that the server will wait before sending a null packet to the client system to keep the connection alive. \\
The **ClientAliveCountMax** parameter defines the number of client alive messages which are sent without getting any messages from the client. \\
Timeout value = ClientAliveInterval * ClientAliveCountMax \\
Beispiel: 1200 x 3 = 3600 ~ 1 Stunde. \\
Nach Änderungen muss der SSH-Service neu gestartet werden.
  sudo systemctl reload ssh

==== Schutz vor Angriffen mit fail2ban ====
[[https://schroederdennis.de/tutorial-howto/ssh-login-schuetzen-mit-fail2ban-server-absichern-anleitung-brute-force/|SSH Login schützen mit fail2ban]] \\
[[https://www.digitalocean.com/community/tutorials/how-to-protect-ssh-with-fail2ban-on-debian-11|How To Protect SSH with Fail2Ban on Debian 11]] \\
[[https://www.howtoforge.de/anleitung/installation-und-verwendung-von-fail2ban-unter-debian-12/|Installation und Verwendung von Fail2ban unter Debian 12]] \\
[[https://wiki.ubuntuusers.de/fail2ban/|fail2ban bei Ubuntu-Users]] \\

fail2ban installieren
  sudo apt update

  sudo apt install fail2ban

Conf-Dateien kopieren
  sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

  sudo cp /etc/fail2ban/fail2ban.conf /etc/fail2ban/fail2ban.local

nur die .local-Dateien bearbeiten
  sudo nano /etc/fail2ban/jail.local

Ändern (nach [sshd]) suchen: \\
[sshd]
  backend=systemd
  enabled = true
  port = ssh
  filter = sshd
  logpath = /var/log/auth.log
  maxretry = 3

Über die Zeit-Parameter in der Datei /etc/fail2ban/jail.local lässt es sich steuern: \\
# "bantime" is the number of seconds that a host is banned. \\
# Beispiel: Sperrung(banned) für 1 Stunde, wenn maxrtry innerhalb findtime erreicht wurde \\
**bantime = 3600** \\
# A host is banned if it has generated "maxretry" during the last "findtime" \\
# Beispiel: Zeit (hier 3 Minuten). \\
**findtime = 180** \\
# "maxretry" is the number of failures before a host get banned. \\
**maxretry = 5** \\

Installieren
  sudo apt install python3-systemd

fail2ban neu starten
  sudo systemctl restart fail2ban
Autostart mit System
  sudo systemctl enable fail2ban

Protokoll der (temporär) verbanten IP-Adressen
  sudo zgrep 'Ban' /var/log/fail2ban.log*

==== Verbindungs-Protokolle ====
Quelle: https://www.strongdm.com/blog/view-ssh-logs \\

If you want to view ssh logs from a specific time range, you can use the since and until flags. Some examples:
  sudo journalctl -u ssh --since yesterday

  sudo journalctl -u ssh --since -3d --until -2d # logs from three days ago

  sudo journalctl -u ssh --since -1h # logs from the last hour

  sudo journalctl -u ssh --until "2024-12-20 07:00:00"

To watch the ssh logs in realtime, use the follow flag:
  sudo journalctl -fu ssh

Use Ctrl-C to exit out of the log monitor.

===== Login =====
==== Login über Linux-Shell ====

Login mit Passwort oder wenn der key im <REMOTEHOST> hinterlegt ist:

  ssh <USER>@<REMOTEHOST>

<USER>@ kann weggelassen werden, wenn entfernter <USER> mit dem lokalen Usernamen übereinstimmt.

Beim ersten Login, wenn der public-key noch nicht auf dem Server ist oder dieser sich geändert hat, muss dieser im Remote-Server registriert werden. Entweder wie oben beschrieben mit (ssh-copy-id ...) oder mit folgender Methode:

  ssh -i ~/.ssh/id_rsa <USER>@<REMOTEHOST>

  * ~/.ssh/id_rsa = (relativer) Pfad und Name privater Schlüssel
  * <USER>@<REMOTEHOST> = User und IP# des entfernten Systems

Beim ersten Login erfolgt eine Validierung mit dem Passwort des Systems. Bei Folgeaufrufen nur noch mit dem PW des SSH-Keys bzw. wenn keines vergeben wurde, ohne PW. \\

Beim ersten Login werden die dann bekannten Hosts lokal in **~/.ssh/known_hosts** gespeichert. Gibt es Änderungen an einem Host und ggf. damit verbundene Probleme, dann kann der Host daraus, oder die ganze Datei, gelöscht werden. Wird dann beim nächsten Aufruf neu generiert.

Wurde der Schlüssel am Server geändert, oder der Server neu eingerichtet, muss er aus der lokalen Datei ~/.ssh/known_hosts ausgetragen werden. Händisch oder mit dem Befehl (IP des betroffenen Servers):

  ssh-keygen -f "~/<USER>/.ssh/known_hosts" -R "<REMOTEHOST>"

==== Login mit PuTTY ====

Mit PuTTY die Verbindung wie folgt definieren: \\
  * <REMOTEHOST>
  * Port (weglassen, wenn 22 - Normalfall)
  * SSH
  * Name (Saved Session)
  * /Connection/SSH/Auth/ >> Laden: Private Key File((Mit Puttygen generierte .ppk-Datei)) \\
  * Option: /Connection/Data/ >> Auto-Login username = <USER> \\
  * Option: /Connection/ >> Secons between keepalives = 600 (verhindert das auto-lockout) \\
  * Zurück auf "Session" und **Save**

=== Login mit FileZilla ===
Für den Zugriff kann die mit Puttygen generierte .ppk-Datei genutzt werden. \\
Verbindungsart: **Schlüsseldatei**.


===== Dateien kopieren über SSH =====
Dafür __nicht__ vorab auf dem Remote-Server einloggen, sondern vom lokalen Rechner ausführen.

Kopieren der Datei “foobar.txt” von einem entfernten Rechner auf den lokalen Rechner.
  scp <USER>@<REMOTEHOST>:foobar.txt /some/local/directory
Kopieren der Datei “foobar.txt” vom lokalen Rechner auf einen entfernten Rechner.
  scp foobar.txt <USER>@<REMOTEHOST>:/some/remote/directory
Kopieren der Datei “foobar.txt” vom Remote-Host “<REMOTEHOST_1>" auf den Remote-Host “<REMOTEHOST_2>”.
  scp <USER>@<REMOTEHOST_1>.edu:/some/remote/directory/foobar.txt \ <USER>@<REMOTEHOST_2>:/some/remote/directory/ 
Einzelne Verzeichnisse kopieren. \\
Kopieren des Verzeichnisses “foo” vom lokalen Rechner in das Verzeichnis “bar” eines entfernten Rechners.
  scp -r foo <USER>@<REMOTEHOST>:/some/remote/directory/bar

Quelle: https://www.davidkehr.com/linux-kopieren-von-und-zu-einem-computer-per-scp-ssh/