Synology Impossibilité d'activer l'option connexion SSH

[Mac Arthur]

Bonjour à tous,

Pour réaliser des transferts de fichiers de configuration de container (cloudflare-tunnel), j'ai besoin de me connecter en SSH via mon compte admin.

Code

ssh compte_admin@IP_NAS

Je l'ai fait toute la matinée sans problème et tout d'un coup la connexion m'est refusée.
Ce n'est pas une question de mot de passe.
En vérifiant l'option connexion SSH, elle est désactivée. Si je recoche, j'obtiens un message d'erreur : "Impossible d'effectuer cette opération car le système est occupé ou la connexion réseau est instable".
Basculer sur un autre compte admin génère le même message d'erreur.
Redémarrer le NAS idem.
Redémarrer le Mac idem.
Créer un nouvel utilisateur admin, idem.
Je sèche…
Y a-t-il une manip à faire ? Rien trouvé sur Stack-Exchange qui est à priori plutôt de "haute volée".

Le verbose disponible avec le maximum d'informations si ça peut aider les experts.

Code

dom@Doms-Mac-Studio-M4-Max ~ % ssh -vvv [email protected]
OpenSSH_9.9p2, 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 *
debug2: resolve_canonicalize: hostname 192.168.1.228 is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/Users/dom/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/Users/dom/.ssh/known_hosts2'
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug3: channel_clear_timeouts: clearing
debug3: ssh_connect_direct: entering
debug1: Connecting to 192.168.1.228 [192.168.1.228] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x48
debug1: connect to address 192.168.1.228 port 22: Connection refused
ssh: connect to host 192.168.1.228 port 22: Connection refused
dom@Doms-Mac-Studio-M4-Max ~ %

[Edit] Un soft reset ne change rien.
Merci !

Ce message a été modifié par Mac Arthur - 9 Aug 2025, 21:34.

[Mac Arthur]

Je dois pouvoir revenir en 15.3. Mais bien évidemment je n'ai pas de sauvegarde aussi ancienne donc ça ne va pas résoudre mon problème.
La question que je me pose est la suivante : ce problème est-il lié à Sequoia ou à mon profil personnel.
Si c'est la deuxième option je vais me trainer ce boulet jusqu'à la nuit des temps.
Mais comme il n'est pas possible d'accéder à l'intérieur du trousseau, si je supprime l'ensemble du trousseau je perds tous mes mots de passe ?
Ça va être ingérable...

[Benzebut]

Je dois pouvoir revenir en 15.3. Mais bien évidemment je n'ai pas de sauvegarde aussi ancienne donc ça ne va pas résoudre mon problème.
La question que je me pose est la suivante : ce problème est-il lié à Sequoia ou à mon profil personnel.
Si c'est la deuxième option je vais me trainer ce boulet jusqu'à la nuit des temps.
Mais comme il n'est pas possible d'accéder à l'intérieur du trousseau, si je supprime l'ensemble du trousseau je perds tous mes mots de passe ?
Ça va être ingérable...

Ou plus simplement sur une version stable antérieure de la configuration par TimeMachine...
Ou encore tenter sur la configuration actuelle par une autre session de test, voire une autre session administrateur pour isoler le problème du "profil personnel". Ou par une autre machine tournant dans une autre version de macOS.
La nouvelle version du trousseau de macOS sauvegarde en divers endroits les éléments, il faudrait regarder où est stocké quoi sous Sequoia.
Le côté aléatoire de la situation est troublant sur une configuration aussi bien gérée au demeurant..