Se connecter à Sophos Firewall via SSH

Pour de nombreuses tâches d’assistance et de dépannage, vous devez accéder au Sophos Firewall via SSH. Il s’agit par exemple des analyses de journaux, des redémarrages de services, des commandes de diagnostic spéciales ou du travail dans le Advanced Shell.

Mais SSH est aussi un accès de gestion à haut risque. L’accès ne doit donc être autorisé qu’à partir de réseaux d’administration dignes de confiance, via une règle d’exception Local Service ACL ciblée ou via un accès au support clairement défini. Pour le renforcement général des services de pare-feu locaux, Configurer correctement Device Access convient également.

Exigences

Pour une connexion du SSH au Sophos Firewall, vous avez besoin de :

• Accès administratif au Sophos Firewall.
• L’adresse IP ou le nom DNS du pare-feu.
• Accès à l’utilisateur admin.
• Un mot de passe de l’administrateur par défaut modifié et documenté de manière sûre ; le mot de passe d’usine ne doit pas rester utilisé en production.
• Une source d’administration fiable, par exemple un réseau de gestion, VPN ou une adresse IP d’administration fixe.
• Sous macOS ou Linux : l’application Terminal préinstallée avec SSH.
• Sous Windows : Terminal Windows avec OpenSSH ou PuTTY.
• Accès autorisé à SSH sous Administration > Device access ou via une règle d’exception ACL de service local.
• Pour les modifications planifiées dans le Advanced Shell : sauvegarde, fenêtre de maintenance et chemin de restauration clair.

⚠️ SSH ne doit être autorisé qu’à partir de réseaux de confiance. Pour les environnements productifs, il est préférable de restreindre l’accès à une adresse IP de gestion ou à un réseau d’administration plutôt que de publier SSH de manière générale.

Définir l’usage prévu de SSH

Toutes les analyses n’ont pas besoin du Advanced Shell. Avant de vous connecter, il convient de préciser quelle console est requise et quelle est la gravité de l’intervention.

• Routage, DNS, Ping, commandes système simples: Device Console. Sophos CLI, moins risqué que le Advanced Shell.
• Lire les fichiers journaux, tail, grep, less: Advanced Shell. Lecture seule, ne pas modifier ni supprimer de fichiers.
• Vérifier l’état du service ou déboguer: Advanced Shell. Activez uniquement le débogage spécifiquement et désactivez-le à nouveau.
• Exécuter des commandes inconnues: Vérifiez d’abord ou ouvrez un dossier d’assistance. N’essayez pas dans le système de production.

La distinction est importante car Device Console et Advanced Shell utilisent une syntaxe différente. De nombreuses erreurs se produisent simplement parce qu’une commande correcte est saisie au mauvais endroit. Une présentation plus large est disponible dans Dépannage Sophos Firewall : Services et journaux.

Autoriser l’accès SSH au pare-feu

Pour qu’une connexion soit possible, le Sophos Firewall doit autoriser SSH sur la zone appropriée ou via une règle d’exception Local Service ACL.

1. Connectez-vous à l’administrateur Web du Sophos Firewall.
2. Ouvrez Administration.
3. Sélectionnez Device access.
4. Vérifiez si SSH est autorisé pour la zone souhaitée.

Pour les réseaux d’administration internes, SSH peut être activé directement pour la zone appropriée, par exemple pour LAN. Si l’accès doit être restreint plus spécifiquement, une règle d’exception ACL de service local est logique.

Device Access contrôle l’accès au pare-feu lui-même. Ce n’est pas la même chose qu’une règle de pare-feu normale qui autorise le trafic à travers le pare-feu. Si SSH dans Device Access est activé de manière trop large, un client peut atteindre le service SSH local du pare-feu même si une règle LAN-to-WAN classique est correctement configurée.

Il faut aussi distinguer SSH de la CLI Console ouverte depuis WebAdmin : un client SSH a besoin de l’accès SSH sur TCP 22. Si la CLI Console est ouverte depuis le menu WebAdmin, HTTPS doit en revanche être autorisé pour la zone concernée.

Dans le cas d’une exception ACL, les valeurs doivent être définies aussi étroitement que possible :

• Rule position : la position de l’exception dans la Local Service ACL
• IP version : IPv4 ou IPv6 selon la source d’administration et l’adresse de destination
• Source zone : la zone à partir de laquelle s’effectue l’administration
• Source Network / Host : l’adresse IP de l’administrateur ou le réseau de gestion
• Destination host : l’adresse IP du pare-feu ou l’interface à administrer, si l’accès peut aussi être limité à une adresse de destination précise
• Services : SSH
• Action : Accept

SSH ne doit pas être accessible de manière incontrôlée depuis Internet. Si un accès externe est nécessaire, celui-ci ne doit être autorisé que via une adresse IP source clairement définie, VPN ou un accès au support dédié.

Diagnostics > Support access est un mécanisme séparé. Il n’expose pas simplement SSH depuis internet, mais permet à Sophos Support un accès temporaire via un canal de support établi par le pare-feu. Cet accès doit aussi être limité dans le temps et désactivé après le cas de support.

Lors de l’activation de Support access, on choisit une durée, puis le pare-feu génère une access ID unique pour Sophos Support. Sophos Support peut l’utiliser pour accéder à WebAdmin et au shell sans identifiants administrateur normaux. Le pare-feu établit lui-même la connexion vers Sophos Support via TCP 22; opérationnellement, c’est différent d’une autorisation SSH entrante depuis le WAN.

Enregistrer une clé publique pour admin

Pour l’accès SSH, l’authentification par clé publique est la méthode préférée. Sur le Sophos Firewall, la clé publique de l’utilisateur admin peut être stockée sous Administration > Device access. Une connexion par mot de passe peut être nécessaire en cas d’urgence, mais ne doit pas rester l’accès par défaut le plus pratique.

⚠️ Une connexion SSH au Sophos Firewall n’est possible qu’avec l’utilisateur admin. Les autres utilisateurs du WebAdmin ne peuvent pas se connecter via SSH.

Important : seul l’administrateur par défaut peut modifier l’authentification par clé publique pour SSH, c’est-à-dire ajouter ou supprimer des clés. Pour les opérations, cela signifie : Les modifications clés appartiennent à un processus d’administration documenté et ne doivent pas être traitées comme un raccourci d’assistance spontané.

L’administrateur par défaut n’est pas un compte de rôle normal que l’on peut simplement remplacer. Sophos indique que ce compte ne peut pas être renommé ni supprimé. Le mot de passe de l’administrateur par défaut, les informations MFA ou de récupération pour les connexions administratives interactives et les clés publiques SSH enregistrées doivent donc être gérés ensemble dans le processus d’exploitation administratif. Une clé publique ne remplace pas la gestion rigoureuse de ce compte.

Les administrateurs WebAdmin nominatifs sont gérés séparément et ne peuvent pas se connecter par SSH avec leur propre nom d’utilisateur. Gérer les administrateurs locaux et les profils Device Access selon le principe du moindre privilège explique le cycle de vie et les droits de ces comptes.

La clé publique est ajoutée dans la zone Public key authentication for admin :

1. Ouvrez Administration.
2. Sélectionnez Device access.
3. Faites défiler jusqu’à la zone Public key authentication for admin.
4. Activez Enable authentication.
5. Ajoutez la clé publique sous Authorized keys.
6. Enregistrez avec Apply.

La clé privée reste toujours sur le client administrateur et ne peut pas être partagée. Seule la clé publique est stockée sur le pare-feu.

Si plusieurs administrateurs utilisent SSH, la même clé privée ne doit pas être partagée. Il est préférable d’avoir des clients administrateurs distincts, des clés publiques documentées et un examen des clés encore nécessaires. Après des changements de personnel ou de prestataires, la zone Authorized keys doit être vérifiée.

Types de clés SSH pris en charge

Tous les types de clés SSH modernes ne conviennent pas également au Sophos Firewall. Avant le déploiement, vous devez vérifier si le type de clé est pris en charge.

• RSA: Utilisez au moins 2048 bits.
• DSA: Au moins 2048 bits, si nécessaire pour des raisons de compatibilité.
• ECDSA: Prise en charge ; ED25519 n’est pas accepté à cette fin.
• ED25519: Pour SSH Public Key Authentication, ne pas utiliser sur Sophos Firewall.

Pour un nouvel accès administrateur, une clé RSA correctement gérée ou une clé ECDSA prise en charge est généralement plus pragmatique qu’un type de clé moderne que le pare-feu ou un ancien outil SSH n’accepte pas.

Se connecter depuis macOS ou Linux

Un client SSH est généralement déjà présent sur macOS et Linux. La connexion est établie dans le terminal.

Exemple :

ssh admin@192.0.2.1

192.0.2.1 est remplacé par l’adresse IP ou le nom DNS de votre propre Sophos Firewall.

Lorsque la connexion est établie pour la première fois, le client SSH demande si l’empreinte digitale du système cible doit être acceptée. Cette empreinte digitale doit être vérifiée puis confirmée. Si un avertissement concernant une clé d’hôte modifiée apparaît après une réimage, un remplacement de matériel ou un changement d’adresse IP, la nouvelle empreinte digitale ne doit pas être acceptée aveuglément. Vérifiez d’abord si le même pare-feu a effectivement été remplacé, réinstallé ou déplacé vers une nouvelle adresse IP. Ce n’est qu’alors que l’ancienne entrée dans ~/.ssh/known_hosts pourra être nettoyée et la nouvelle empreinte digitale acceptée.

Selon la configuration, le mot de passe de l’utilisateur admin est alors demandé ou la connexion est effectuée à l’aide de la clé SSH stockée.

Si une clé privée spécifique doit être utilisée :

ssh -i ~/.ssh/sophos-admin-key admin@192.0.2.1

Pour un accès récurrent, le chemin d’accès à la clé, l’adresse IP source autorisée et le but doivent être documentés. L’entrée known_hosts ne doit pas être copiée dans les tickets ou les historiques de discussion ; Pour les avertissements relatifs aux clés de l’hôte, l’historique des modifications est plus important qu’une solution de contournement rapide.

Se connecter avec PuTTY

Sous Windows, vous pouvez soit utiliser Windows Terminal avec OpenSSH, soit utiliser PuTTY.

Avec Windows Terminal, l’établissement d’une connexion fonctionne de la même manière que sous macOS ou Linux :

ssh admin@192.0.2.1

Pour PuTTY :

1. Ouvrez PuTTY.
2. Saisissez l’adresse IP ou le nom DNS du Sophos Firewall sous Host Name.
3. Définissez Port sur 22.
4. Définissez Connection type sur SSH.
5. Connectez-vous avec Open.
6. Vérifiez et confirmez l’empreinte digitale SSH.
7. Connectez-vous en tant qu’utilisateur admin et utilisez le mot de passe ou la clé SSH selon la configuration.

Une fois connecté, le menu de la console Sophos Firewall apparaît.

Si PuTTY est utilisé avec une clé privée, la clé doit correspondre à la clé publique stockée sur le pare-feu. Après un changement de personnel ou de prestataire de services, non seulement le mot de passe doit être modifié ; les anciennes clés publiques doivent également être supprimées de Authorized keys.

Ouvrir Device Console ou Advanced Shell

Après une connexion réussie via SSH, le pare-feu affiche un menu de console. L’option que vous choisissez dépend de ce que vous souhaitez faire.

Pour de nombreuses commandes SFOS que vous utilisez :

4. Device Console

Pour des tâches Linux ou système de fichiers plus approfondies, utilisez le Advanced Shell via :

5. Device Management
3. Advanced Shell

Le Advanced Shell offre un accès très étendu au système. Les commandes ne doivent y être exécutées que si leur rôle est clair.

• Device Console: ping, dnslookup, traceroute, show, options de routage ou système.
• Advanced Shell: Lire les journaux de débogage /log, tail -f, grep, less, service -S.

Pour l’analyse des journaux, les noms de services et les modèles d’erreur typiques, Dépannage Sophos Firewall : Services et journaux est un meilleur point de départ que la mémorisation de commandes individuelles.

Fermer la connexion

Une fois le travail terminé, la session SSH doit se terminer proprement :

exit

Si vous êtes dans un sous-menu, il peut être nécessaire de revenir d’abord au menu principal puis de terminer la session.

Sophos Firewall ferme les sessions SSH inactives après 15 minutes. Cela ne remplace pas une déconnexion propre : les sessions ouvertes, les modes de débogage et les règles d’accès temporaires doivent quand même être fermés ou retirés consciemment.

Si SSH n’a été activé que temporairement pour un cas de support, la version doit alors être supprimée ou désactivée. Cela est particulièrement vrai pour les exceptions ACL provenant d’adresses IP sources externes ou d’un accès à un fournisseur de services.

Après des interventions profondes, il convient également de vérifier :

• Le débogage est-il à nouveau désactivé ?
• Une règle d’exception ACL temporaire a-t-elle été supprimée ou désactivée ?
• N’y a-t-il pas de fichiers temporaires, de sauvegardes de support ou d’enregistrements inutilement laissés sur le pare-feu ?
• Les extraits de journaux, l’heure, la commande et le résultat sont-ils documentés dans le ticket ou la modification ?
• La clé SSH a-t-elle été utilisée uniquement pour un accès planifié à l’administrateur ou au support ?

Problèmes courants

La connexion est refusée

Si la connexion est rejetée, SSH n’est généralement pas autorisé sur le pare-feu pour la zone ou la source sélectionnée. Dans ce cas, Administration > Device access doit être coché. Vérifiez également si une règle d’exception ACL autorise la source ou si une version plus large d’accès au périphérique a été délibérément supprimée.

La connexion expire

Un délai d’attente indique souvent que le pare-feu n’est pas accessible via l’adresse IP sélectionnée, qu’une route est manquante ou qu’un pare-feu en amont bloque l’accès.

Si un pare-feu qui n’est pas encore entièrement configuré utilise toujours le mot de passe d’usine, SFOS rejette volontairement et sans message d’erreur les connexions SSH provenant de la zone WAN. Il s’agit d’une mesure de protection. Le mot de passe doit d’abord être modifié par une voie d’administration locale autorisée ; Device Access ou l’ACL ne doivent pas être élargis pour contourner cette protection.

Aucun accès réseau au pare-feu

Si ni WebAdmin ni SSH ne sont accessibles, il ne faut pas ouvrir rapidement des accès WAN ou des accès de zone supplémentaires. Le chemin de secours le plus propre est l’accès local à la console sur l’appliance, par exemple avec un câble console ou, sur les modèles pris en charge, via micro USB. C’est particulièrement important lorsque Device Access, le routage ou les zones d’interface ont été mal définis.

La connexion échoue

Si la connexion échoue, l’utilisateur admin, le mot de passe ou la clé SSH et les réseaux sources autorisés doivent être vérifiés. Des messages typiques tels que Permission denied (publickey,password) indiquent un mot de passe incorrect, une clé privée incorrecte ou une configuration de clé publique manquante.

Si le mot de passe de l’admin par défaut est réellement perdu, Réinitialiser le mot de passe admin de Sophos Firewall explique la récupération série pour les appliances physiques et les limites distinctes des firewalls virtuels et cloud.

Si la connexion par clé publique échoue, vérifiez également le type de clé, la longueur de la clé, la clé privée incorrecte, le format de clé PuTTY et l’entrée sous Authorized keys. Un service SSH correctement autorisé n’aide pas si la clé ne correspond pas à la clé publique stockée.

Un avertissement concernant la clé de l’hôte s’affiche

Un avertissement de clé d’hôte peut être inoffensif si un pare-feu a été réinstallé ou remplacé. L’avertissement peut également indiquer un système cible incorrect ou une confusion d’adresse IP. Par conséquent, vérifiez d’abord le pare-feu, l’adresse IP, le DNS et l’historique des modifications. Ce n’est qu’alors que l’ancienne entrée known_hosts doit être supprimée.

Mauvaise console ouverte

Si une commande n’est pas reconnue, la mauvaise console est souvent ouverte. Les commandes telles que system ... appartiennent souvent au Device Console. Les commandes de système de fichiers et de journal telles que tail, grep, less ou service -S appartiennent au Advanced Shell.

Liste de contrôle opérationnel

• Autorisez uniquement SSH à partir de sources administratives fiables.
• Modifier le mot de passe d’usine avant toute utilisation de SSH en production.
• Si possible, utilisez la règle d’exception Local Service ACL au lieu de la libération de zone étendue.
• Préférez Public Key Authentication pour admin.
• Documenter séparément le mot de passe de l’administrateur par défaut, les informations MFA ou de récupération et les clés SSH.
• Utilisez le type de clé pris en charge et la longueur de la clé du document.
• Ne partagez pas de clés privées.
• Vérifiez l’empreinte digitale SSH lors de la première connexion.
• Gérez consciemment les avertissements de clé hôte après une réimage ou un remplacement de matériel.
• Ne confondez pas Device Console et Advanced Shell.
• N’apportez des modifications au Advanced Shell que dans un but clair.
• Supprimez les versions temporaires SSH après les cas de support.
• Supprimez les anciennes clés publiques après un changement de personnel ou de prestataire de services.

FAQ