2026 Runbook cloud Mac : SSH et partage d’écran concurrents — débloquer les Apple Silicon MacLogin quand l’automation PTY entre en collision avec le GUI distant

Les ingénieurs plateforme qui mélangent des sessions ssh sans tête et le partage d’écran interactif sur le même utilisateur macOS voient souvent des blocages aléatoires qui ne ressemblent ni à une panne réseau ni à une saturation CPU. En avril 2026 la conclusion opérationnelle est la contention de session console : WindowServer, loginwindow et l’automation liée au PTY se disputent le même contexte GUI, ce qui ressemble à du VNC instable mais correspond à des verrous locaux. Ce runbook fournit une matrice de symptômes, neuf étapes ordonnées, un tableau collision ports/démons, des prédicats de logs unifiés prêts à coller dans un ticket et une FAQ calibrée pour les baux MacLogin à Hong Kong, Tokyo, Séoul, Singapour et aux États-Unis.

Lisez-le avec la gouvernance des sessions SSH partagées, la politique presse-papiers et enregistrement VNC et la rotation des clés SSH et le MFA. En fin d’incident avec restitution de bail, suivez la sanitisation d’offboarding entreprise. Liens opérationnels : tarifs, aide, VNC.

Sur MacLogin un bail est souvent rattaché à une seule ligne produit ; lorsque les heures de marché à Tokyo chevauchent les pics CI à Singapour, la configuration humain-écran plus scripts Aqua devient fréquente. Classer d’abord en contention console raccourcit le MTTR comparé à l’hypothèse bande passante. Dans vos runbooks d’astreinte figez l’ordre des neuf étapes pour éviter qu’un nouveau membre tue des processus sans avoir mis la CI en pause, ce qui complique Keychain ou FileVault.

Côté preuves, joignez toujours une fenêtre de 20 minutes WindowServer et screensharingd : sans signal GUI, les audits demandent qui détenait le verrou graphique. Nommez les archives gzip avec l’ID de bail et la région ; conservez-les 35 jours pour aligner les réviseurs JP et US sur le même tarball.

Quand les sessions distantes concurrentes se figent (et pourquoi on accuse la mauvaise couche)

Trois schémas dominent les ponts d’incident d’avril 2026 sur les mini loués :

• La CI via SSH lance osascript ou xcodebuild pendant qu’un humain observe le même bureau en partage d’écran.
• Les produits de sécurité affichent une invite TCC uniquement sur la console physique, invisible au spectateur distant, bloquant l’automation 27 à 40 minutes.
• Plusieurs observateurs s’empilent après un forward SSH vers 5900, multipliant les diffs framebuffer ; WindowServer peut dépasser 85 % de GPU alors que le CPU paraît libre.

Matrice de symptômes de gel (choisissez la colonne avant reboot)

Signal observable	Hypothèse SSH	Hypothèse partage d’écran	Première action	Preuves à collecter
Curseur mobile mais clics inertes	Aide sudo mot de passe bloquée	WindowServer coincé	Pause CI ; retirez le second observateur	sample WindowServer 10 s
SSH accepte la saisie mais GUI figé	PTY sain	Verrou GUI utilisateur console	Test avec compte admin secondaire	Logs heartbeat loginwindow
Les deux canaux gèlent en ~5 s	Blocage noyau I/O ou snapshot APFS	Même cause racine	Vérifier diskutil apfs listSnapshots	Graphe pression stockage
Partage d’écran tombe toutes les ~11 min	Timeout TCP idle amont	Désalignement keepalive ARD	Keepalive tunnel SSH 60 s	Capture TCP côté client

Mécanismes de verrouillage : console, agent ARD et interplay PTY SSH

macOS attache nombre d’automatismes à la session utilisateur console. Le partage d’écran diffuse cette session. SSH peut rester sans GUI ou invoquer des outils exigeant implicitement le contexte GUI. Ensemble ils provoquent une inversion de priorité : loginwindow sert encore l’auth mais WindowServer ne composite plus car un outil retient un verrou CGS.

Sur les hôtes MacLogin, le partage écoute souvent 5900 avec 5901–5903 pour l’observation. Les forwards codés en dur sur 5900 se dupliquent après veille sur portable.

Runbook de remédiation en neuf étapes (ordre strict)

1. Étiquetez le blast radius : ID de bail, métro (HK/JP/KR/SG/US), utilisateur console, nombre de clients partage d’écran, sessions SSH interactives.
2. Pausez la CI UI au moins 6 minutes pour laisser sortir les helpers osascript.
3. Déconnectez tous les observateurs sauf un ; attendez 90 secondes.
4. Validez les écouteurs via netstat -an | grep 590 et supprimez les forwards dupliqués.
5. Basculez vers un second utilisateur macOS si la gouvernance l’autorise, voir le guide compte de build partagé.
6. Capturez les logs unifiés 300 secondes avec les prédicats ci-dessous ; joignez le gzip.
7. Réinitialisez l’affichage à distance via pmset displaysleepnow puis réveil réseau si activé.
8. Reboot seulement si l’étape 7 échoue deux fois ; évitez les heures de bourse JP pour la finance.
9. Post-mortem : notez dans la roster quelles automations ne doivent plus chevaucher le partage d’écran.

Matrice ports et démons

Port TCP	Propriétaire typique	Signature de conflit	Mitigation
22	OpenSSH	MaxStartups limite les rafales	Augmenter prudemment en staging ; préférer bastion
5900	Partage d’écran	Doubles forwards SSH -L	Ports locaux uniques par ingénieur
3283	Agent ARD (héritage)	Politiques ARD mélangées	Désactiver les fonctions ARD inutilisées
dynamique	Outils session USB	Émulation HID de tests	Suites HID sur baux dédiés

Prédicats de logs unifiés et paquet de preuves

• WindowServer : log show --last 20m --predicate 'process == "WindowServer"'
• Auth partage d’écran : log show --last 20m --predicate 'process == "screensharingd"'
• Tuple SSH : exportez SSH_CONNECTION depuis chaque session bloquée.

Conservez les journaux compressés 35 jours sur un compartiment partagé pour les réviseurs JP et US.

FAQ

Peut-on lancer sudo pkill ScreenSharing via SSH ? Seulement après avoir fermé les observateurs inactifs ; sinon vous risquez de laisser un ingénieur bloqué pendant un déverrouillage FileVault.

Faut-il bannir le partage d’écran ? Non — planifiez des créneaux et documentez-les à côté du calendrier CI.

MacLogin limite-t-il la bande passante ? Le shaping par métro est décrit dans les tarifs ; attendez plus de jitter sur les trajets inter-régions saturés.

Pourquoi le Mac mini M4 aide les flux distants concurrents

Le M4 offre un chemin framebuffer GPU plus large et des media engines efficaces, ce qui garde le partage d’écran réactif pendant que de gros journaux Xcode défilent en SSH. La mémoire unifiée limite le swap comparé aux petites VM x86. La flotte HK, JP, KR, SG et US permet de colocaliser les baux GUI avec les équipes tout en laissant la CI sur des profils sans tête.

Louer un second mini via les tarifs coûte moins cher que de dépasser 3 incidents de concurrence par mois malgré ce runbook.