7 votes

SSH ne fonctionne pas tant que le compte local n'est pas connecté.

J'ai un Mac mini qui fonctionne Big Sur Monterey auquel je ne peux pas me connecter via ssh à moins que l'utilisateur ait démarré sa session.

Je suppose que cela est dû, comme sur ubuntu, au fait que le fichier authorized_keys n'est pas accessible avant le démarrage de la session, mais je ne semble pas pouvoir appliquer une approche similaire, et cela devient un problème.

Le Mac est utilisé comme serveur et si, pour une raison quelconque, la session est fermée ou si la machine doit être redémarrée, je suis obligé de connecter un écran, une souris et un clavier pour relancer la session. Le problème est que cela s'est déjà produit alors que je travaillais à distance, et que j'ai donc complètement perdu l'accès à la machine.

Y a-t-il un moyen de résoudre ce problème ?

Voici la sortie de ssh lorsque le compte local n'est pas connecté

myhost:~ myusername$ ssh -vvv remoteuser@remoteIP
OpenSSH_8.6p1, LibreSSL 3.3.6
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/* matched no files
debug1: /etc/ssh/ssh_config line 54: Applying options for *
debug1: /etc/ssh/ssh_config line 58: Applying options for *
debug2: resolve_canonicalize: hostname remoteIP is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/Users/myusername/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/Users/myusername/.ssh/known_hosts2'
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug3: ssh_connect_direct: entering
debug1: Connecting to remoteIP [remoteIP] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x48

Reste en place jusqu'à ce que la connexion soit interrompue par le délai d'attente. Si je démarre la session remoteuser localement, alors après la dernière ligne que nous pouvons voir ci-dessus, il ajoute la ligne suivante, et le processus ssh continue.

debug1: Connection established.

7voto

Oskar Points 1242

Comme les détails ont changé, je laisse ceci en place mais l'OP n'a pas FileVault. Cela peut aider d'autres personnes, cependant, d'avoir cet élément à vérifier.


Il s'agit d'une situation courante où les gens ne réalisent pas que FileVault, lorsqu'il est activé, fait apparaître un écran "pré-démarrage" qui fait croire que le système d'exploitation est en cours d'exécution et que le stockage n'est pas crypté.

Une fois que vous vous êtes connecté (ce qui déverrouille le stockage où le système d'exploitation et les données de l'utilisateur sont stockés, démarre le mac et termine la connexion de l'utilisateur), ouvrez une ligne de commande et vérifiez le statut de votre FileVault :

/usr/bin/fdesetup status

Si FileVault est désactivé, vous avez un problème légitime avec sshd qui est dans un état non standard. Si FileVault est activé - alors vous devez définir un justificatif d'identité unique dans le cadre du redémarrage pour que le système d'exploitation démarre sur un écran de connexion correct avec tous les démons d'arrière-plan en cours d'exécution et que ssh fonctionne à distance après ce seul redémarrage.

/usr/bin/fdesetup authrestart

LesApples.com

LesApples est une communauté de Apple où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres utilisateurs d'appareils Apple, poser vos propres questions ou résoudre celles des autres.

Powered by:

X