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.

[Pat94]

Salut,

Un NAS exploité avec Sequoia, cela devient "NASe" dirait-on
Sinon là je n'ai vraiment aucune idée pour expliquer pourquoi la connexion SSH passe ou pas de façon aléatoire sur le M4, utilise ton Hack pour tester.

[hellomorld]

L'ip du nas n'a pas changée ?

[Mac Arthur]

Non, lÌP n'avait pas changé, mais tout était inaccessible, même Telnet et son mot de passe par défaut qui change chaque jour en fonction de la date système.
Sans doute un problème de daemon quelque part.

J'ai fini par trouver un script, à exécuter dans un batch en mode racine via le planificateur de tâche. Tout est rentré dans l'ordre.
Si ça peut vous être utile !

Code

# 1. Restaure le fichier de configuration d’origine
cp /etc.defaults/ssh/sshd_config /etc/ssh/sshd_config

# 2. Fixe les bonnes permissions (lecture/écriture root, lecture tous)
chmod 644 /etc/ssh/sshd_config

# 3. Redémarre le démon SSH de DSM
/usr/syno/bin/synosystemctl restart sshd.service

[Benzebut]

J'ai fini par trouver un script, à exécuter dans un batch en mode racine via le planificateur de tâche. Tout est rentré dans l'ordre.
Si ça peut vous être utile !

Ce que fait le script en question, c'est de nettoyer les fichiers caches du NAS.
Comme c'est la seconde fois que les caches posent problème sur ces accés, il faudrait comprendre où ils se cachent dans la configuration...

[Mac Arthur]

Si tu as des idées, je suis prêt à en finir avec cette partie de cache-cache.

[Mac Arthur]

Je rebondis sur la remarque de Benzebut pour essayer de comprendre, et de continuer mon éducation (Jean Gabin "Je sais").

Si je comprends bien, ces caches sont des données (?), des fichiers (?) stockés quelque part qui permettent d'accélérer un certain nombre de processus sans aller rechercher les données d'origine. Vrai/Faux ?
S'il y a un problème de cache, cela peut donc bloquer le process ? Vrai/Faux ?
En cas de problème sur les caches, plutôt que de retourner aux données d'origine, ça bloque ?

Parce que mon mot de passe de 24 caractères n'a pas changé depuis un bon moment. Il est donc identique quel que soit l'endroit où on aille le chercher, et rafraichir le cache ne mettra rien à jour de ce côté-là.

Merci pour ces compléments d'explication, même si ça n'aidera probablement pas à résoudre le problème au niveau technique.

[Benzebut]

Si je comprends bien, ces caches sont des données (?), des fichiers (?) stockés quelque part qui permettent d'accélérer un certain nombre de processus sans aller rechercher les données d'origine. Vrai/Faux ?
S'il y a un problème de cache, cela peut donc bloquer le process ? Vrai/Faux ?
En cas de problème sur les caches, plutôt que de retourner aux données d'origine, ça bloque ?

Parce que mon mot de passe de 24 caractères n'a pas changé depuis un bon moment. Il est donc identique quel que soit l'endroit où on aille le chercher, et rafraichir le cache ne mettra rien à jour de ce côté-là.

Merci pour ces compléments d'explication, même si ça n'aidera probablement pas à résoudre le problème au niveau technique.

Presque vrai. Sous l'appellation "cache", il s'agit de fichiers contenant des données précédemment utilisées. Vrai ensuite, car ces fichiers permettent effectivement d’accélérer les opérations, puisque les données d'origine sont connues. Pour prendre un exemple, les navigateurs web ont de très gros fichiers de cache, car sont conservés en historique les sites consultés, pour éviter de charger toutes les données de nouveau.
Vrai, un problème de cache peut bloquer une opération, puisqu'il va être consulté en premier, donc s'il contient des informations erronées... Raison pour laquelle macOS purge ses caches de manière régulière ou volontaire par l'utilisation d'applications comme Onyx.
Et effectivement, cela bloque le comportement normal puisque c'est consulté en premier dans la hiérarchie des opérations.

Ces fichiers de cache (ou mémoire tampon) peuvent contenir les mots de passe, mais également un état (les applications ouvertes), un contenu (les fameux cookies), une configuration (les instantanés TimeMachine) ou un chemin d’accès (disques durs externes). Tout le paradoxe du multitâche sur du multicœur, c'est que cela génère en permanence plein de fichiers caches pour accélérer et/ou anticiper une opération. Mais qu'il faut les nettoyer à un moment donné pour une saine actualisation, ce que tous les algorithmes bien conçus font naturellement...

Dans le problème d'accès au NAS, je suppose que certains caches n'ont pas été correctement actualisés et conservent le statut de l'ancien environnement. Par contre lesquels et où se cachent-ils...

Ce message a été modifié par Benzebut - 3 Aug 2025, 18:47.

[Mac Arthur]

Merci !
Le script je l'ai mis en automatique tous les jours, puisque ce ne sont que des caches le risque est limité...
Je vais aller fouiner voir si il n'y a pas d'autres outils "Onyx" à mettre en place quelque part.
Celà dit c'était la première fois en 3 ans...

[Benzebut]

Le script je l'ai mis en automatique tous les jours, puisque ce ne sont que des caches le risque est limité...
Je vais aller fouiner voir si il n'y a pas d'autres outils "Onyx" à mettre en place quelque part.
Celà dit c'était la première fois en 3 ans...

Il y a toujours une première fois...
Cela peut être une actualisation qui n'a pas été faite, ou un changement dans les protocoles avec une nouvelle version des applications. Cela fait toujours beaucoup de possibilités pour identifier ce petit problème, car cela va se jouer à une broutille de réglage...

[Mac Arthur]

Et il y aura une deuxième…
C'est de nouveau le bazar, impossible de monter les disques de mon NAS depuis ce matin.
Rien fait de spécial pourtant, juste un reboot, et les disques qui montent normalement au démarrage ne montent plus. On me demande le mot de passe et il ne passe pas.

Suis allé voir dans le trousseau d'accès, supprimé l'enregistrement sur 192.168.1.228 (vous savez où trouver mon NAS si vous y arrivez !). Impossible de supprimer cette clef.
Dans la nouvelle application "Mot de passe", pas de trace de cette connexion.
Vide les caches, rien y fait.

J'ai cet après-midi passé mon MBP sous Tahoe beta 5. Au redémarrage, le mot de passe de connexion au NAS m'a été redemandé. Validé en moins de temps qu'il m'a fallu pour écrire cette bafouille.
Je ne sais plus que faire…

[Benzebut]

J'ai cet après-midi passé mon MBP sous Tahoe beta 5. Au redémarrage, le mot de passe de connexion au NAS m'a été redemandé. Validé en moins de temps qu'il m'a fallu pour écrire cette bafouille.
Je ne sais plus que faire…

Ce qui pourrait être une option pour tester. Revenir à une version antérieure de macOS pour tester les liens vers ce NAS bien capricieux...

[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...

[ch21]

Peut être complètement à la ramasse, mais tu as regardé du coté de ton routeur ?

[Mac Arthur]

Merci.
Oui le routeur il est innocenté depuis le début.
J'ai mis suffisamment de temps à le configurer pour que ce ne soit pas un gruyère (vu de l'extérieur).
C'est totalement aléatoire et c'est ça qui rend le diagnostic kafkaïen.

Ce message a été modifié par Mac Arthur - 7 Aug 2025, 14:40.

[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..

[Mac Arthur]

Je peux également gérer ce NAS depuis mon MacBook M1 Pro qui est actuellement sous Tahoe dernière version.
Je n'ai aucun problème tout monte avec le même compte admin et le même mot de passe sur la même IP interne.
Pourvu que ça dure, ça me permet au pire de monter les volumes sur le MBP puis envoyer les fichiers sur l'autre Mac. C'est d'un pratique !

[Mac Arthur]

À vos avis d'expert
Une possibilité me vient à l'esprit :
Mes 2 machines (Studio et MBP 14") ont le même identifiant de connexion, le même mot de passe, le même compte Apple, bref de parfaits jumeaux.
Mon MBP ne me pose aucun problème pour monter mes disques réseau.
Que penseriez-vous de copier l'application Keychain Access d'une machine sur l'autre ?
Je ferai bien évidemment un Super Duper avant.
Je ne connais pas la structure de Keychain Access qui a l'air d'être une véritable boite noire.
Des impossibilités évidentes vous viennent à l'esprit ou ça se tente ?
Si ça a une chance de marcher, j'aurai peut-être quelques mots de passe pour des applications que je n'utilise pas depuis le MBP à actualiser, mais ce serait déjà un grand pas en avant (alors que je suis déjà au bord du précipice )

[ch21]

Il est loin le temps où une application se suffisait à elle même.
Tu crois pouvoir trouver toutes les dépendances ?

De toutes façons, tu ne risque rien avec un clone.

[Polo35230]

Mes 2 machines (Studio et MBP 14") ont le même identifiant de connexion, le même mot de passe, le même compte Apple, bref de parfaits jumeaux.

Jumeaux, jumeaux, oui et non...
Faux jumeaux, certainement: Ils n'ont pas la même adresse IP...
Dans la partie sécurité du NAS, toutes les connexions sont permises?

As-tu regardé dans un log du NAS s'il n'y a pas un message d'erreur quand tu te connectes à partir du Mac?

Autrement, si c'est le PW qui ne passe pas, ce n'est pas un pb SSL/TLS, car la demande de PW intervient après le Handshake SSL.

[Mac Arthur]

Je pense oui.
On avait validé la partie SMB ensemble.
Je vais essayer de chercher les logs.
Pas trop mon rayon pour être franc mais si ça peut permettre d'avancer !
Encore merci...

[Mac Arthur]

Bon j'essaie d'avancer par ce que ça me pourrit la vie.
J'ai horreur de ne pas maîtriser. La machine doit rester sous dépendance de l'homme, pas l'inverse.

Le trousseau et la nouvelle application mot de passe sont inbriqués de façon étrange ou du moins difficile à comprendre.
J'ai découvert qu'on pouvait réinitialiser le trousseau avec un backup de l'ancien.
On perd tout ses mots de passe mais à choisir...

Sur un nouveau trousseau donc vierge j'ai le même problème. Refus de connexion.
Ça vous inspire des pistes d'investigation ?
Merci encore...

[Benzebut]

Sur un nouveau trousseau donc vierge j'ai le même problème. Refus de connexion.
Ça vous inspire des pistes d'investigation ?

Refus de connexion, car mot de passe refusé ou refus de connexion car session non reconnue sur le NAS ? En mettant pour les tests justement le fameux "dodo", est-ce que cela fait une différence ?...

La remarque de Polo35230 est une piste à suivre. Que disent les historiques du NAS, voire de la console sous macOS si un retour est fait sur les connexions ?...

[DOMY]

J'ai horreur de ne pas maîtriser.

Enlever " résolu " dans le titre du post .... en attendant les beaux jours !

Ce message a été modifié par DOMY - 9 Aug 2025, 19:32.

[Mac Arthur]

J'ai horreur de ne pas maîtriser.

Enlever " résolu " dans le titre du post .... en attendant les beaux jours !

Bonne remarque !
Je viens de voir que ça ne fait que 15 jours que ce problème existe. J'ai l'impression que c'est une éternité et que la date limite de péremption à un mois était largement dépassée.
Merci.
PS Tu as reçu les nouilles ? Pas trop de problèmes avec le facteur ?

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

[Mac Arthur]

J'avoue, j'en ai bavé, pas vous… vous connaissez la chanson.
Pour l'instant on ne touche à rien et on croise les doigts.
Évidemment, dès que je lui ai dit que j'allais collecter les logs via l'interface Synology et la console macOS, aussitôt dit, aussitôt fait, les disques sont montés…
Suis également passé sous Tahoe beta 6 sur le MBP et c'est parfaitement stable.

À suivre, vous pouvez reprendre votre abonnement Netflix !

[Benzebut]

Évidemment, dès que je lui ai dit que j'allais collecter les logs via l'interface Synology et la console macOS, aussitôt dit, aussitôt fait, les disques sont montés…
Suis également passé sous Tahoe beta 6 sur le MBP et c'est parfaitement stable.

C'est terrible cela la peur du gendarme...
Même si les disques du NAS sont bien montés actuellement, il serait intéressant de "suivre" le chemin des connexions pour comprendre les précédentes errances.

[Mac Arthur]

Oui c'est prévu, mais là je m'accorde 4 jours de vacances.
On verra au retour si les disques ont disparu... Ou pas