Sicherheit

Kuonen.Remote bringt seine Kryptografie selbst mit: Schlüsseltausch, Signaturen und Verschlüsselung sind eigener Code ohne fremde Bibliotheken, geprüft gegen die Testvektoren der Normen und gegen OpenSSH. Was davon im Alltag zählt, steht hier.

Hostschlüssel

Jeder SSH-Server weist sich mit seinem Hostschlüssel aus. Beim ersten Kontakt zeigt Kuonen.Remote den Fingerabdruck (SHA256) und fragt:

• Annehmen und speichern – der Schlüssel kommt nach ~/.ssh/known_hosts, dieselbe Datei, die OpenSSH benutzt;
• Nur dieses Mal – verbinden, ohne zu speichern;
• Abbrechen.

Den Fingerabdruck vor dem Annehmen mit dem vergleichen, was der Betreiber des Servers nennt, etwa per Telefon. Auf dem Server selbst zeigt ihn ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub.

Hat sich der Schlüssel eines bekannten Servers geändert, warnt Kuonen.Remote deutlich. Das kommt vor, wenn der Server neu aufgesetzt wurde – oder wenn sich jemand dazwischengeschaltet hat. Im Zweifel nicht verbinden und nachfragen.

Für Skripte und feste Verbindungen lässt sich der erwartete Fingerabdruck vorgeben: in der App unter Erweitert › Verbindung, in kremote mit -hostkey SHA256:…, in Skripten mit open … -hostkey=SHA256:…. Dann fragt Kuonen.Remote nie, sondern verbindet nur mit genau diesem Schlüssel.

Das Fenster Werkzeuge › Bekannte Hosts durchsucht known_hosts und entfernt Einträge, auch gehashte.

TLS-Zertifikate

Bei FTPS und WebDAV über HTTPS prüft Kuonen.Remote das Zertifikat des Servers. Ist es nicht vertrauenswürdig (unbekannter Aussteller, falscher Name, abgelaufen), nennt der Dialog den Mangel und den SHA-256-Fingerabdruck. Angenommene Zertifikate merkt sich Kuonen.Remote in der Datei bekannte_zertifikate im Konfigurationsordner (siehe Daten und Ablage). Fest vorgeben lässt sich ein Zertifikat unter Erweitert › Verbindung bzw. mit open … -certificate=….

Eigene Schlüssel

Ein Schlüsselpaar ist sicherer und bequemer als ein Kennwort. So entsteht eines:

1. Werkzeuge › Schlüsselgenerator öffnen (oder kremote keygen -t ed25519 -o ~/.ssh/id_ed25519).
2. Ed25519 wählen – kurz, schnell und heute die beste Wahl. ECDSA (P-256, P-384, P-521) und RSA (3072 oder 4096 Bit) gibt es für ältere Server.
3. Eine Passphrase vergeben; sie schützt den Schlüssel, falls die Datei in falsche Hände gerät.
4. Den privaten Schlüssel speichern (OpenSSH oder PuTTY PPK v3); unter Linux und macOS bekommt er die Rechte 600.
5. Den öffentlichen Schlüssel kopieren und auf dem Server an ~/.ssh/authorized_keys anhängen.
6. In der Sitzung unter Schlüsseldatei den privaten Schlüssel eintragen.

Vorhandene Schlüssel von PuTTY (.ppk), aus PEM- oder PKCS#8-Dateien liest Kuonen.Remote direkt; der Schlüsselgenerator und kremote keygen wandeln sie auch um.

Agent

Ein Agent hält entschlüsselte Schlüssel im Speicher, damit die Passphrase nur einmal fällt. Kuonen.Remote benutzt einen laufenden Agenten von selbst (SSH_AUTH_SOCK, unter Windows die Pipe des OpenSSH-Agenten) und bringt einen eigenen mit: Werkzeuge › SSH-Agent bzw. kremote agent. Auf Wunsch muss jede Nutzung eines Schlüssels bestätigt werden.

Agent weiterleiten erlaubt dem Server, den Agenten für weitere Anmeldungen zu benutzen – praktisch für Sprünge zu internen Rechnern. Wer Administrator auf dem Server ist, kann den Agenten während der Sitzung ebenfalls benutzen; darum nur auf Servern einschalten, denen man vertraut. Für Sprünge ist ein Sprunghost (-J) die sicherere Wahl: die Schlüssel verlassen dabei den eigenen Rechner nicht.

Kennwortspeicher

Gespeicherte Kennwörter liegen in der Datei kennwoerter.bin, verschlüsselt mit AES-256-GCM. Den Schlüssel dazu verwahrt das Betriebssystem:

• Windows: die Datenschutz-Schnittstelle (DPAPI) des angemeldeten Benutzers;
• macOS: der Schlüsselbund;
• Linux: der Secret Service der Arbeitsumgebung (GNOME-Schlüsselbund, KWallet).

Die Sitzungen selbst (sitzungen.json) enthalten nie Kennwörter. Auch Sitzungsadresse und Code und der Export nach ssh_config lassen sie weg.

Verfahren

Kuonen.Remote bietet die Verfahren in dieser Reihenfolge an; es gilt jeweils das erste, das auch der Server kann. Vorne stehen Verfahren, die auch gegen künftige Quantenrechner bestehen sollen.

Dazu schützt Strict KEX (kex-strict-c-v00@openssh.com) den Verbindungsaufbau gegen den Terrapin-Angriff.

Alte Verfahren – SHA-1, CBC, 3DES, ssh-rsa, diffie-hellman-group1-sha1 und -group14-sha1 – sind ausgeschaltet. Für alte Geräte lassen sie sich je Sitzung unter Erweitert › SSH › Alte Verfahren erlauben einschalten; wird eines davon ausgehandelt, zeigt Kuonen.Remote eine Warnung.

Welche Verfahren eine Verbindung tatsächlich benutzt, zeigt Sitzung › Server- und Protokollinformationen.