gniki

OS: Debian 11

Über SSH ist es möglich eine sichere Verbindung zu einem entfernten System aufzubauen, um Befehle abzusetzen oder Daten auszutauschen. Zugriff auf einen entfernten Server (<REMOTEHOST>) ist eingeschränkt auf die dort angelegten User und den root. Über die Datei /etc/ssh/sshd_config läßt sich der Zugang regeln - siehe SSH-Zugriff am Server konfigurieren.

Empfehlenswert:

• Direkter Login von root untersagen
• Zugang nur mit Schlüssel - login ohne Schlüssel (nur Passwort) unterbinden
• Optional: Beschränkter Zugriff über SFTP auf definierte Bereiche

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

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 miteiander agiert. Der private Schlüssel bleibt lokal und geheim, der öffentliche wird an externe Systeme verteilt.

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 aber zu anderen Systemen transferiert, z.B. per E-Mail, dann birgt das Gefahren.

Der private Schlüssel muss unbedingt vor fremdem Zugriff geschützt bleiben!

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 (i.d.R. mit Passwort) sollte temporär freigegeben sein.
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 i.d.R. 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.

Alternativ ist es möglich, mit dem Programm 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.

1. Load an existing private key file
2. Save private key » jetzt mit Endung .ppk

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

$  ssh <USER>@<REMOTEHOST>

<USER>@ kann weggelassen werden, wenn <USER> mit dem lokalen User ü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>"

Mit PuTTY die Verbindung wie folgt definieren:

• <REMOTEHOST>
• Port (weglassen, wenn 22 - Normalfall)
• SSH
• Name (Saved Session)
• /Connection/SSH/Auth/ » Laden: Private Key File¹⁾
  
• Option: /Connection/Data/ » Auto-Login username = <USER>
  
• Option: /Connection/ » Secons between keepalives = 600 (verhindert das auto-lockout)
  
• Zurück auf „Session“ und Save

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

$ sudo nano /etc/ssh/sshd_config
  
  ClientAliveInterval 1200
  ClientAliveCountMax 3
  
  PermitRootLogin no                      #root-login von Außen verbieten
  PasswordAuthentication no               #Login nur mit key-file (außer s.u.)
  Subsystem sftp internal-sftp
  Match group ftpuser                     #Sonderregelung für Gruppe "ftpuser"
      X11Forwarding no
      AllowTcpForwarding no
      ChrootDirectory /var/www/html/      #FTP beschränkt auf dieses Verzeichnis
      ForceCommand internal-sftp
      PasswordAuthentication yes          #Passwort-Login für diese Gruppe ok

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

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/

Auf dem lokalen Rechner aktivieren. Firewall ufw zuvor installieren bzw. aktivieren.

  $ sudo apt install xrdp
  $ sudo systemctl enable --now xrdp

ggf. dieser Befehl

  $ sudo ufw allow from any to any port 3389 proto tcp

Dann Zugriff auch über Window-Remote-Desktop.