Apple : SSH et FileVault

 (keith.github.io)
1 points par GN⁺ 2025-09-19 | 1 commentaires | Partager sur WhatsApp
  • Lorsque FileVault est activé, le volume de données reste verrouillé pendant le démarrage de macOS
  • Les fichiers de configuration OpenSSH sont stockés sur le volume de données, ce qui empêche l’utilisation des méthodes d’authentification existantes ou l’accès au shell tant qu’il est verrouillé
  • Si Remote Login (SSH) est activé, le déverrouillage du volume de données à distance via le réseau est possible avec une authentification par mot de passe
  • Cette méthode n’autorise pas immédiatement la session SSH : après le déverrouillage, la connexion SSH est temporairement interrompue
  • L’accès SSH devient possible une fois le volume de données monté et les services nécessaires démarrés

Présentation de l’intégration entre SSH et FileVault chez Apple

  • Sur un macOS où FileVault est activé, le volume de données est verrouillé, ce qui empêche l’accès à ce volume même après le début du processus de démarrage
  • Comme tous les fichiers de configuration système et par compte de OpenSSH sont stockés sur le volume de données, les méthodes d’authentification habituellement configurées et l’accès au shell sont en général désactivés tant que ce volume reste verrouillé

Déverrouillage à distance via Remote Login (SSH)

  • Même après le démarrage, si le volume de données est verrouillé, les tentatives d’authentification réseau restent autorisées lorsque Remote Login (connexion SSH) est activé
  • L’utilisateur peut utiliser SSH pour déverrouiller à distance le volume protégé par FileVault au moyen d’une authentification par mot de passe

Limites et processus du déverrouillage

  • Cette fonctionnalité permet de déverrouiller le volume de données, mais la session SSH n’est pas établie immédiatement
  • Dès que le volume de données est déverrouillé, macOS interrompt brièvement la connexion SSH pendant qu’il termine le montage du volume et le démarrage des services de support qui en dépendent
  • Une fois cette procédure terminée, SSH et les autres services activés peuvent être utilisés normalement

Introduction dans macOS 26 Tahoe

  • La fonction de déverrouillage à distance du volume de données via SSH a été introduite pour la première fois dans macOS 26 Tahoe

À lire aussi

1 commentaires

 
GN⁺ 2025-09-19
Commentaires sur Hacker News

  • J’ai constaté que lorsque FileVault est activé, le volume de données est verrouillé et reste inaccessible pendant ou après le démarrage tant qu’on ne s’est pas authentifié avec le mot de passe du compte. OpenSSH pour macOS stocke à la fois les fichiers de configuration système et ceux par compte sur le volume de données. Donc tant que FileVault est actif, il est normalement impossible d’utiliser les méthodes d’authentification configurées ou d’accéder au shell. En revanche, si Remote Login est activé, l’authentification SSH par mot de passe fonctionne même dans cette situation. Cela permet de déverrouiller à distance le volume de données via le réseau. En revanche, la session SSH ne reprend pas immédiatement : après le déverrouillage du volume via SSH, la connexion est brièvement coupée pendant que macOS termine le montage du volume et le redémarrage des services, puis SSH (et les autres services) redevient utilisable normalement. C’est vraiment un changement très bienvenu

  • Je me demande si cela signifie qu’après un redémarrage automatique à la suite d’une coupure de courant, on peut désormais exploiter un Mac mini serveur entièrement à distance sans brancher physiquement un clavier. C’est vraiment une excellente évolution

    • Après test, j’ai confirmé que cela fonctionne parfaitement
      1. Activer General > Sharing > Remote Management
      2. Après redémarrage, en se connectant en SSH, on voit le message : « Ce système est verrouillé. Utilisez le nom du compte et le mot de passe pour le déverrouiller. Une fois déverrouillé, la connexion normale sera possible »
      3. Une fois l’authentification SSH réussie, la connexion SSH est coupée et le message « Déverrouillage du système terminé. L’authentification SSH normale est désormais possible » s’affiche
      4. En se reconnectant ensuite en SSH, l’accès fonctionne normalement
    • On peut aussi utiliser la commande suivante 
      sudo fdesetup authrestart -delayminutes -1
      Cette méthode permet une connexion automatique avec le compte choisi pour le prochain redémarrage uniquement. C’est pratique car il n’y a pas besoin de saisir le mot de passe, mais cela comporte un risque de sécurité. Selon le contexte, cela peut rester acceptable
    • Je me demande sincèrement pourquoi choisir macOS comme système d’exploitation serveur. Moi aussi, je trouve le matériel du Mac mini très séduisant et j’y ai déjà réfléchi. Mais je reste hésitant à l’idée de faire tourner Linux à la place de macOS
    • J’ai déjà dû retirer moi-même un serveur de son rack, enlever la poussière, brancher un moniteur et un clavier, puis me connecter et le déverrouiller, à cause d’un collègue qui avait activé FileVault par erreur sur une machine de CI. Maintenant qu’on peut le déverrouiller en SSH, si cela se reproduit, on pourra régler le problème immédiatement à distance
    • Je connais bien l’inconvénient des Mac distants avec FileVault activé qu’il fallait obligatoirement déverrouiller physiquement après une coupure de courant pour les remettre en ligne. Je me demande si, après redémarrage, on peut aussi retrouver un accès GUI complètement à distance. J’envisage d’acheter un Mac mini pour un lab à la maison, et je me demande même s’il faudra un dispositif distant de type KVM si nécessaire

  • Je voudrais souligner à quel point ce changement est énorme pour les environnements Mac non personnels, notamment en entreprise. Le rapport qualité-prix et la qualité du Mac Mini le rendent assez intéressant pour l’automatisation, et dans les entreprises aussi, son adoption augmentait progressivement tant que ce problème ne bloquait pas. La question FileVault était l’une des principales causes de ce frein

    • L’idée d’utiliser un Mac comme serveur généraliste m’intéressait. Je me demande s’il existe des réglages ou méthodes supplémentaires pour le gérer plus facilement dans cet usage, et si vous y déployez des charges de travail spécifiques au Mac ou aussi des workloads Linux en conteneurs

  • Ravi de voir l’ajout du déverrouillage du volume de données via SSH dans macOS 26 Tahoe. Après la récente mise à niveau vers Tahoe, j’avais été surpris de pouvoir me connecter en SSH, et je comprends maintenant que cela vient de ce changement. Je n’éteins généralement pas mon Mac, mais il m’arrive parfois de devoir m’y connecter à distance et d’oublier qu’une grosse mise à jour a été installée la veille, ce qui me prenait au dépourvu. Avec ce changement, cela me rassure

  • J’en déduis que FileVault ne chiffre plus le volume système désormais. Je pense cela parce que le volume système est en lecture seule, à contenu figé, et identique sur tous les macOS. L’idée de démarrer complètement, y compris le réseau, puis de demander le déchiffrement du volume de données paraît logique. Si FileVault ignore effectivement le chiffrement du volume système, cela me semble être une évolution très rationnelle. Je mentionne aussi le fait qu’avec les technologies d’overlay, on donne souvent l’impression d’écrire sur la partition système alors qu’en réalité l’écriture va sur le volume de données

    • Des informations comme les mots de passe WiFi sont elles aussi stockées sur le volume de données, donc le réseau n’est pas forcément toujours disponible

  • Changement intéressant, mais je me demande si les problèmes de « condition de course » observés dans les sessions graphiques, par exemple quand le shell est stocké sur le volume de données, peuvent aussi s’appliquer à SSH. Par exemple, en choisissant de restaurer les apps au redémarrage, il est déjà arrivé que les apps se lancent avant que tous les volumes soient montés, ce qui faisait échouer l’exécution du shell. Cela se produit surtout lorsqu’on installe le shell avec Nix. J’ai l’impression que le même problème pourrait survenir avec SSH. Je me demande si cela a été résolu au niveau système

    • Lors du déverrouillage via SSH, la connexion est fermée juste après le déverrouillage du volume de données. Une fois le volume monté, on peut se reconnecter et le shell se lance alors, donc ce problème ne se pose pas. En utilisant le Nix store, j’ai déjà contourné cela avec un shim basé sur wait4path. Il suffit d’installer le shim à l’avance dans un chemin connu sur le volume de données et de le définir comme shell de connexion
    • Apple élimine ce problème à la racine en arrêtant tous les processus après le déverrouillage de l’appareil (« userspace reboot »)
    • Je pense qu’une reconnexion résoudra la plupart des cas. En particulier avec SSH, il existe généralement des mécanismes de nouvelle tentative réseau, donc ce n’est pas un gros problème
    • Ce cas peut, à mon avis, être résolu avec l’utilitaire wait4path inclus dans l’OS depuis longtemps

  • Je trouve cela vraiment très bienvenu. J’avais justement désactivé FileVault à cause de l’absence de cette fonctionnalité

  • Je teste le chiffrement complet du disque de Omarchy (une configuration Arch très orientée) et je me demande si je pourrais l’utiliser comme VM principale. En travaillant physiquement dessus, j’ai accès à un bureau accéléré par GPU et à tous mes traitements longue durée. Mais si je suis à distance pendant plusieurs semaines et que la machine redémarre, le fait de devoir saisir physiquement le mot de passe du disque me dissuade d’essayer. Je l’exécute sous ProxMox, mais à cause de réglages comme le passthrough USB, il est impossible d’y accéder via un visualiseur VNC standard. Je me demande si Omarchy tentera un déverrouillage à distance comme macOS

    • Sous Linux, on pouvait déjà implémenter le déverrouillage à distance depuis très longtemps en ajoutant dropbear à initramfs

  • Je suis sûr qu’il existe quelque part une surface d’attaque exploitable

    • En dehors des risques de sécurité habituels d’un SSH à mot de passe, je ne vois pas vraiment de risque supplémentaire. Si cela vous inquiète, le placer derrière un pare-feu comme Wireguard devrait déjà beaucoup améliorer la situation. Avant, il fallait désactiver FileVault sur les serveurs Mac, donc en comparaison c’est un changement bien plus appréciable
    • Avec des problèmes de sécurité comme Blastdoor en tête, j’ai toujours tendance à aborder ce genre de changement avec prudence

  • J’avais un Mac mini auquel j’avais renoncé pour mon homelab à cause de l’absence de cette fonctionnalité, mais maintenant j’ai l’impression que tout change