Gérer ses clés SSH — Documentation ILYGO Hawser

Pourquoi une clé plutôt qu'un mot de passe

Un mot de passe se devine, se réutilise d'un serveur à l'autre et se retape à chaque connexion. Une clé SSH est une paire : la partie publique est déposée sur le serveur, la partie privée ne le quitte jamais. Le serveur envoie un défi, votre poste le signe, personne ne transmet de secret réutilisable.

Vous pouvez désactiver l'authentification par mot de passe côté serveur (PasswordAuthentication no) et fermer la porte aux attaques par force brute.
Une clé par usage : révoquer un accès revient à retirer une ligne de ~/.ssh/authorized_keys sur le serveur concerné.
Dans Hawser, la clé et sa phrase de passe vivent dans le coffre chiffré : rien à retaper à chaque session.

Hawser gère les clés pour les protocoles SSH et SFTP. FTP et Telnet n'ont pas d'authentification par clé : ils n'ont qu'un champ mot de passe.

La vue Clés

Barre latérale gauche, icône 🔑 « Clés ». L'en-tête de la vue affiche « SSH Keys ». Aucun raccourci clavier n'y mène directement ; passez par ⌘K si vous préférez le clavier.

Chaque ligne montre le nom de la clé, un badge vert « ✓ verified » si elle a été validée, puis une ligne de méta-données de la forme ssh-ed25519 · no passphrase · 2 uses. Le compteur d'usages est le nombre de fiches de connexion qui pointent sur cette clé — c'est le seul indicateur avant une suppression. À droite : ✏️ pour éditer, 🗑️ pour supprimer.

Le champ de recherche de la barre du haut filtre la liste à la frappe, sur le nom uniquement. Ni le type, ni le commentaire, ni l'empreinte ne sont pris en compte. Quand le coffre ne contient aucune clé, la vue affiche « No SSH keys — Add a key to start using SSH/SFTP. »

Vue Clés de Hawser, liste de clés SSH avec leur type et leur nombre d'usages — Tout ce que la liste sait dire d'une clé : nom, statut de validation, type, présence d'une phrase de passe et nombre de fiches qui l'utilisent.

Générer une paire de clés

Le bouton « ✨ Générer » se trouve dans la barre du haut, à gauche de « + Clé », et n'apparaît que sur la vue Clés de l'application native. La modale « Générer une clé SSH » propose exactement trois algorithmes.

Choix dans la liste	Quand le prendre
Ed25519 — recommandé	Par défaut. Clé courte, rapide, acceptée par tout serveur OpenSSH 6.5 ou plus récent (2014).
RSA 4096 bits	Serveur ancien ou équipement réseau qui ne connaît pas Ed25519. Plusieurs secondes de calcul.
RSA 2048 bits (legacy)	Uniquement si une contrainte externe l'impose. À éviter sinon.

Les autres champs sont Nom, Commentaire (optionnel), Passphrase (optionnel) et Confirmer la passphrase. Le commentaire est inscrit dans la clé et repris en fin de ligne publique — mettez-y de quoi la reconnaître, par exemple julien@mac-mini. Si les deux champs de phrase de passe diffèrent, la génération ne part pas : « Les passphrases ne correspondent pas. » La génération est entièrement locale, rien ne circule sur le réseau.

Générer une clé utilisable, en attendant

ssh-keygen -t ed25519 -C "julien@mac-mini" -f ~/.ssh/prod_deploy

Dans le Terminal de macOS. La commande écrit ~/.ssh/prod_deploy (partie privée) et ~/.ssh/prod_deploy.pub (partie publique). Importez ensuite la partie privée dans Hawser comme décrit ci-dessous.

Importer une clé existante

Vue Clés → bouton bleu « + Clé » en haut à droite. La modale « New SSH key » s'ouvre, le curseur est placé dans Name.
Nommez la clé. C'est ce nom que vous choisirez plus tard dans les fiches de connexion.
Collez le contenu intégral du fichier de clé privée dans le champ « Clé privée (PEM) », lignes -----BEGIN… et -----END… comprises.
Saisissez la phrase de passe de la clé, si elle en a une.
Cliquez « 🧪 Validate ». Le pied de modale doit afficher en vert « ✓ Clé ssh-ed25519 » (ou le type réel).
Cliquez « Save ». Un toast « Key added » confirme l'enregistrement.

Il n'y a pas de sélecteur de fichier : l'import se fait par copier-coller. Le plus sûr est de passer par le presse-papiers plutôt que par un éditeur de texte, qui peut réencoder les retours à la ligne.

pbcopy < ~/.ssh/prod_deploy

La même modale s'ouvre depuis ⌘K → « New SSH key », ou depuis une fiche de connexion, onglet « Authentication » → bouton « + New ». Dans ce dernier cas, la clé qui vient d'être créée est présélectionnée dans la liste de la fiche.

« Save » relance systématiquement la validation, même si vous avez déjà cliqué sur « 🧪 Validate ». Rien n'est enregistré si elle échoue.

Message	Cause et remède
« ✗ Clé vide »	Le champ PEM est vide.
« ✗ Passphrase incorrecte (la clé refuse de se déchiffrer). »	La clé est chiffrée et la phrase de passe saisie ne l'ouvre pas.
« ✗ parse: … »	Le bloc n'est pas décodable : format non OpenSSH, PEM tronqué, retours à la ligne mangés.
« ✗ Pas une clé OpenSSH (publique ou privée) reconnue. »	Le texte collé n'est pas une clé du tout.
« Name required » / « Key required »	Un des deux champs est vide au moment du Save.
« Invalid key/passphrase »	La revalidation au Save a échoué ; rien n'a été écrit.

Récupérer la clé publique et la déployer

Le serveur a besoin de la partie publique. Hawser ne l'affiche nulle part et n'a aucun bouton pour la copier ; pour une clé importée, l'entrée du coffre ne contient même pas de partie publique. Il faut la dériver depuis le fichier privé, hors de l'application.

ssh-keygen -y -f ~/.ssh/prod_deploy

La commande imprime une ligne unique : ssh-ed25519 AAAA… julien@mac-mini. C'est cette ligne qui doit atterrir dans ~/.ssh/authorized_keys du compte distant.

Cas concret — Déployer une clé sur un serveur où vous n'avez qu'un mot de passe

La fiche du serveur existe déjà dans Hawser, en authentification par mot de passe. Vous voulez basculer sur une clé sans quitter l'application.

Dans le Terminal de macOS : ssh-keygen -y -f ~/.ssh/prod_deploy | pbcopy pour mettre la ligne publique dans le presse-papiers.
Dans Hawser, ouvrez une session sur le serveur avec le mot de passe : vue Connections → ⌨️ Shell sur la carte de l'hôte.
Collez le bloc ci-dessous dans le terminal distant, en remplaçant la ligne ssh-ed25519 AAAA… par ce que vous venez de copier.

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo 'ssh-ed25519 AAAA… julien@mac-mini' >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Importez la clé privée dans Hawser (« + Clé »), puis rattachez-la à la fiche du serveur — voir la section suivante.
Ouvrez une nouvelle session pour vérifier qu'elle passe par la clé, avant de retirer le mot de passe de la fiche.

Rattacher une clé à un hôte

Vue Connections → ✏️ sur la carte de l'hôte (ou « + New » pour une nouvelle fiche).
Onglet « Authentication » de la modale.
Basculez le sélecteur de « Password » vers « Clé SSH ».
Choisissez la clé dans la liste « Saved SSH key ». Les clés validées y apparaissent suivies d'un ✓.
« Save ». Puis ⌨️ Shell ou 📁 SFTP sur la carte pour tester.

Enregistrer une fiche en mode « Clé SSH » sans avoir choisi de clé est refusé : « Select an SSH key ».

Chaque fiche porte sa propre clé, y compris les rebonds : si l'hôte passe par un bastion (onglet « Advanced » → « Jump Host (bastion) »), le bastion s'authentifie avec la clé de sa fiche, et l'hôte cible avec la sienne. La chaîne est limitée à quatre niveaux (« jump host chain too deep (limit 4) »).

Erreur à la connexion	Ce qu'elle signifie
« [Erreur] Clé SSH introuvable (vérifie l'host : authType=key sans keyId valide) »	La fiche est en mode clé mais la clé référencée n'existe plus — typiquement, elle a été supprimée.
« [Erreur] decode private key: … »	Le contenu enregistré n'est pas une clé privée décodable : clé publique collée par erreur, ou PEM tronqué.
« [Erreur] authentication failed »	La clé est valide, le serveur la refuse : partie publique absente de `authorized_keys`, permissions du fichier, ou mauvais nom d'utilisateur dans la fiche.

Ces messages s'affichent en rouge dans le terminal et en notification. Voir aussi Ouvrir une session SSH.

L'agent SSH de macOS

Le moteur de Hawser sait s'authentifier auprès de l'agent SSH du système : il se connecte à la socket SSH_AUTH_SOCK, demande la liste des identités chargées et délègue la signature. Cela permet de garder les clés hors du coffre.

Le seul contournement passe par l'import JSON : ⌘K → « Importer config OpenSSH (~/.ssh/config) » → onglet « Full JSON ».

{
  "configs": [
    {
      "id": "prod-01-agent",
      "protocol": "ssh",
      "name": "prod-01 (agent)",
      "host": "10.0.0.12",
      "port": 22,
      "username": "julien",
      "authType": "agent",
      "keyId": "",
      "initialPath": "."
    }
  ]
}

Les objets sont poussés tels quels dans le coffre, sans validation de forme. Vérifiez votre JSON avant de coller : le moteur retombe sur le mode agent quand authType porte une valeur qu'il ne connaît pas, ce qui produit une tentative silencieuse et un « authentication failed » incompréhensible. Les erreurs propres à l'agent sont « SSH_AUTH_SOCK unavailable: … » (aucun agent ne répond) et « agent identities: … » (l'agent refuse de lister ses identités). Vérifiez d'abord ssh-add -l dans le Terminal.

Où vivent vos clés, et Touch ID

Hawser n'écrit jamais dans ~/.ssh. Le PEM et sa phrase de passe sont rangés dans votre fichier .ivault chiffré, et chaque enregistrement de clé déclenche une écriture disque immédiate — un échec remonte tout de suite en notification. Si le coffre s'est verrouillé entre-temps, l'enregistrement échoue avec « no vault open » : déverrouillez et recommencez. Voir Ce qui est chiffré.

Avant chaque écriture, une copie chiffrée du coffre est déposée sous ~/Library/Application Support/ch.ilygo.hawser/vault-backups/. Vos clés existent donc en plusieurs exemplaires sur le disque, toujours sous forme chiffrée, jamais en clair.

Touch ID ne protège pas les clés une par une : il déverrouille le coffre. La clé maîtresse est enveloppée dans le trousseau et libérée après authentification biométrique ; une fois le coffre ouvert, toutes vos clés SSH sont utilisables sans nouvelle demande. Il n'y a pas de signature SSH par le Secure Enclave, ni de clé adossée au matériel.

Vue Sécurité de Hawser avec le réglage de verrouillage automatique — Une fois le coffre ouvert, le verrouillage automatique (15 minutes par défaut) est le seul réglage qui remet vos clés à l'abri.

Si le coffre est appairé au cloud, l'ajout d'une nouvelle clé vérifie d'abord le quota du plan et peut être bloqué : « ⚠ Quota cloud atteint ». Seul un compteur est envoyé au serveur, jamais le contenu. Voir Synchroniser ses coffres.

Renommer, remplacer, supprimer

Le bouton ✏️ d'une ligne ouvre la modale « Edit key », pré-remplie avec le nom et le contenu de la clé.

Pour une clé sans phrase de passe, tout est modifiable : vous pouvez changer le nom et remplacer le PEM. La clé est entièrement revalidée au Save, et un toast « Key updated » confirme.

Remplacer une clé (rotation)

Aucune fonction de rotation n'existe. L'opération est manuelle et son ordre compte : rattachez la nouvelle clé partout avant de supprimer l'ancienne.

Générez la nouvelle paire hors de Hawser et déposez sa partie publique dans ~/.ssh/authorized_keys sur chaque serveur concerné, à côté de l'ancienne.
Importez la nouvelle clé privée dans Hawser sous un nom distinct (« + Clé »).
Dans chaque fiche qui utilisait l'ancienne clé : ✏️ → onglet « Authentication » → sélectionnez la nouvelle dans « Saved SSH key » → Save. Le compteur d'usages de la vue Clés vous dit combien de fiches il reste à traiter.
Ouvrez une session sur chaque serveur pour confirmer.
Supprimez l'ancienne clé dans Hawser, puis retirez sa ligne de authorized_keys sur les serveurs.

Supprimer

Le bouton 🗑️ rouge demande confirmation — « Delete key », « Delete "<nom>" ? » — puis retire la clé et réécrit le coffre. Un toast « Deleted "<nom>" » confirme ; en cas d'échec d'écriture (« Delete failed »), la clé est restaurée dans la liste.