Connexions SSH

External SSH relie Opfield à un hôte distant nommé à l’aide d’un identifiant configuré par un administrateur. Ce n’est ni un connecteur de dépôts Git, ni un nœud Bastion géré, ni un substitut à l’enrôlement des démons. Utilisez l’hébergement Git pour l’accès aux dépôts et les nœuds pour les opérations continues gérées par les démons.

Configurer une connexion

1. Ouvrez la section External SSH sous Settings > Integrations.
2. Saisissez un nom d’affichage, l’hôte, le port et le nom d’utilisateur distant. Utilisez un compte doté uniquement des privilèges système nécessaires à l’opération prévue.
3. Choisissez l’authentification par mot de passe ou une clé SSH générée par Opfield. Les nouvelles connexions n’acceptent pas l’import de clés privées arbitraires. Installez la clé publique générée pour le compte distant ; lorsque c’est proposé, une clé existante éligible peut être réutilisée.
4. Si nécessaire, sélectionnez une connexion de rebond existante et vérifiez l’accès par ce chemin.
5. Découvrez l’empreinte de la clé d’hôte et vérifiez-la via un canal de confiance indépendant avant de l’accepter.
6. Enregistrez la connexion et testez l’authentification. Si la clé d’hôte change, examinez ce changement au lieu de contourner la vérification.

Les identifiants sont stockés chiffrés. Un nom d’utilisateur SSH root et le rôle d’administrateur système d’Opfield relèvent de systèmes d’autorisation différents : les permissions distantes ne suivent pas le rôle de l’utilisateur Opfield.

Préparer le compte distant et la clé publique

SSH n’a pas de scopes d’API fournisseur. Sa frontière de permissions est le compte Unix distant, ses permissions sur les fichiers et toute élévation de privilèges explicitement configurée.

1. Assurez-vous que le serveur Opfield peut joindre l’hôte et le port SSH (normalement 22), directement ou via la connexion de rebond configurée.
2. Dans Opfield, générez une clé et copiez la clé publique. Ne générez pas localement une seconde clé sans rapport et ne collez pas de clé privée dans authorized_keys.
3. Dans une console de confiance, connectez-vous avec le compte distant prévu. Préparez son répertoire SSH :

mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

4. Ouvrez ~/.ssh/authorized_keys dans un éditeur et ajoutez la clé publique sur une seule ligne, en conservant les clés existantes. Assurez-vous que le répertoire et le fichier appartiennent à ce compte. Si vous modifiez en tant qu’administrateur, utilisez le répertoire personnel du compte cible, et non celui de l’administrateur.
5. Vérifiez la clé d’hôte du serveur via la console du fournisseur ou un autre canal de confiance indépendant. Pour une clé d’hôte Ed25519 :

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256

6. Comparez cette empreinte SHA-256 avec celle du même algorithme de clé d’hôte proposée par Opfield. Une valeur obtenue uniquement via la connexion non fiable ne constitue pas une vérification indépendante. Enregistrez l’empreinte vérifiée et testez l’authentification.

Usage prévu	Exigence pour le compte distant
Se connecter	Mot de passe valide ou clé publique installée ; connexion SSH autorisée par la politique du serveur
Lire des fichiers ou exécuter des commandes ordinaires	Accès aux fichiers et aux exécutables pour ce compte
Installer ou réparer un démon	Les privilèges d’administration du processus d’installation ; une simple connexion ne suffit pas
Utiliser un hôte de rebond	Connexion à l’hôte de rebond plus un chemin de redirection autorisé vers la cible ; l’authentification sur la cible reste distincte

N’accordez pas de sudo sans mot de passe et sans restriction simplement pour réussir un test de connexion SSH. Un mot de passe est celui du compte distant, et non un mot de passe de connexion à Opfield. Pour l’authentification par clé, ne désactivez ni la vérification de l’hôte ni les accès existants pendant le test de la nouvelle clé.

Référence : authorized_keys d’OpenSSH et authentification du serveur.

Accès et installation via un hébergeur

integrations:ssh:view, integrations:ssh:manage et integrations:ssh:use séparent la visibilité, l’administration et l’utilisation. En 2.11, ces scopes peuvent aussi être délégués à des jetons d’API et à des autorisations OAuth, et Opfield MCP expose un ensemble d’outils SSH externes aux agents qui les détiennent. Le consentement OAuth laisse integrations:ssh:use décoché par défaut ; l’exécution de commandes par un agent doit donc être sélectionnée explicitement. Voir API et MCP.

Pour l’installation via un hébergeur prise en charge, Opfield vérifie que la destination SSH est bien une adresse attribuée à la VM sélectionnée. Une connexion fonctionnelle vers un autre hôte n’est pas un canal d’installation pour cette VM. L’hébergement peut utiliser à la place un canal Guest Agent pris en charge ; n’ajoutez pas SSH simplement parce qu’un compte chez le fournisseur existe.

Diagnostiquer les échecs de connexion

Distinguez la joignabilité DNS ou TCP, l’accès à l’hôte de rebond, une empreinte non correspondante, un refus d’authentification et la permission d’exécuter la commande prévue. Une découverte réussie de la clé d’hôte n’est pas une authentification réussie. Une connexion réussie ne prouve pas les privilèges sudo ou d’installation. Examinez l’erreur précise et corrigez la couche correspondante sans exposer de mots de passe ni de clés privées.