Un environnement SSH de développeur pensé pour macOS

L'organisation SSH d'un développeur dérive avec le temps : des hôtes dans l'historique du shell, la mauvaise clé essayée sur le mauvais serveur, un ssh user@host copié depuis une page de wiki, et iTerm2, Cyberduck et TablePlus qui détiennent chacun un morceau du tableau. SSHive réunit les serveurs au même endroit et rattache le reste à chaque profil : les tunnels dont un projet a besoin, la commande exécutée à l'ouverture d'une session, les commandes que vous répétez. Si vous vivez déjà dans iTerm2, la comparaison avec iTerm2 montre où les deux se recoupent et où ils diffèrent.

Créez un dossier par projet dans la barre latérale, avec prod, staging et dev à l'intérieur ; les sous-dossiers fonctionnent aussi. Donnez un point rouge à la prod, orange au staging et vert au dev : la barre latérale vous dit d'un coup d'œil quel serveur vous allez ouvrir. Une commande au démarrage par profil, comme cd /var/www/app && git log --oneline -5, vous place là où vous travaillez dès l'ouverture de la session. Les commandes rapides peuvent remplir {host} ou {user} d'elles-mêmes, ou demander une valeur à saisir, comme dans git checkout {{branch}}.

Sur le profil de dev, ajoutez des tunnels locaux vers les services distants : 5432 vers localhost:5432 pour Postgres, 6379 vers localhost:6379 pour Redis. Une fois connecté, TablePlus ou Postico parlent à localhost:5432 et atteignent la base distante ; à la déconnexion, les tunnels se ferment avec la session. La version gratuite ouvre un tunnel par profil : Postgres et Redis ensemble relèvent donc de la version Pro.

Sur Mac, la version Pro comprend un serveur MCP qui permet à un client IA de travailler dans vos sessions SSHive : ssh_execute pour lancer une commande, sftp_read_file pour lire une configuration. Activez-le dans Paramètres > MCP et copiez la configuration affichée dans Claude Code ou Cursor ; la version App Store n'écrit pas la configuration de votre client à votre place. Demandez ensuite « affiche les 200 dernières lignes d'app.log sur staging et trouve les erreurs 500 », et l'assistant le fait dans la session de staging. L'onglet Portée décide des serveurs qu'il peut atteindre : retirez un dossier de production, et les serveurs que vous y rangerez plus tard restent eux aussi hors de portée. Ce que lit l'assistant est envoyé par son client au fournisseur du modèle.