Synology Accès SSH refusé

[nounours1895]

Bonjour,

J'ai besoin d'accéder à mon NAS via SSH (pour créer un groupe de stockage sur mes NVMe nouvellement installés) mais j'ai un message d'erreur bizarre:


pourtant j'ai bien activé SSH dans la config de DSM sans changer le port puisque c'est une activation temporaire:


Evidemment les identifiants sont bons puisque je peux me connecter à DSM sans problème.

Quelqu'un a une solution ?

Merci

 

[Cram28]

Bonsoir,

Un changement quelconque sur le NAS ? Par exemple un déplacement de la boîte et rebranchement sur une autre prise réseau du NAS ?
Ou bien l'adresse ou le nom réseau du NAS ont changés depuis la dernière connexion depuis ce poste client ?

En fait serveur et client ne semblent plus d'accord sur les secrets qu'ils partagent. Une proposition de manip:

• Éditer le fichier c:\\Users\\Michel\.ssh/known_hosts
• Effacer la seconde ligne
• Un nouvelle commande de connexion ssh va demander une validation: taper 'yes'

P'tête...

@+

 

[nounours1895]

Hello,

Un changement quelconque sur le NAS ? Par exemple un déplacement de la boîte et rebranchement sur une autre prise réseau du NAS ?

Je l'ai arrêté pour y rajouter 2 disques NVMe et je l'ai redémarré, tout va bien depuis DSM.

La prise réseau est forcément la même qu'avant vu là où le NAS est posé.

Donc je ne vois pas ce qui a pu changer ???

• Éditer le fichier c:\\Users\\Michel\.ssh/known_hosts

Comme le fichier n'est pas simple à lire, fais-tu allusion à tout ce qu se trouve après le 2ème rectangle rouge sur la capture ci-dessous ?? (le 2ème rectangle rouge masque l'IP qui correspond en effet à ce NAS):


??
Merci

 

[Cram28]

En effet, c'est généralement des trucs «im...ables»... (c'est çà les secrets) et on plus ton éditeur va à la ligne comme il le sent

Les lignes commencent apparemment avec des adresses IP. Donc la suppression débute avec la seconde 192.168.xxx.xxx et jusqu'à la fin.
Mais attention: il ne faut garder que la 1iere ligne jusqu'au derniers caractères en QI8=. Pas de retour charriot final !

Donc tu mets ton curseur juste derrière le '=' plus haut et tu vires tout ce qui suit.

En fait c'est plus long à - tenter - d'expliquer qu'à faire...
Je suis pas sûr d'être limpide

Au pire tu efface tout: ta première ligne avec la première @IP doit correspondre à une autre machine que tu accèdes en SSH. Si tout est effacé, ben il suffira de refaire un 'yes' la prochaine fois que tu te connecte à une machine, NAS ou autre...

@suivre

 

[bliz]

le signe égal détermine une variable derrière la chaine

en gros, tout ceci appartient à la même ligne

 

[Cram28]

Ce qui pilote les lignes en réalité, c'est le retour chariot. Le caractère '=' n'est pas nécessairement une affectation, surtout dans ce type de fichiers avec des «zorglub» dans tous les sens...

Il faudrait éventuellement un éditeur un peu plus sophistiqué que le notepad de Windows (un SublimeText par exemple, qui affiche les N° de ligne)...

Je continue de penser que le plus simple est d'effacer tout le contenu, voir de supprimer le fichier known_hosts: le client ssh le recréera à la prochaine connexion, avec une confirmation demandée comme pour une première fois...

En tout cas çà marche comme çà avec mon PC client sous Linux/Debian.
Et SSH c'est SSH: il n'y a pas de raison d'avoir un comportement différent (sur ce périmètre-la en tout cas), selon qu'on est sur Windows ou Linux ou Mac...

@+

 

[nounours1895]

Donc votre recommandation serait de supprimer le fichier known_hosts ?

S'il est recréé (ou plus exactement enrichi d'une ligne) lors d'une nouvelle demande de connexion à un host qui n'y figure pas déjà, c'est sans doute plus simple et plus sûr que d'aller bidouiller les lignes incompréhensibles qui s'y trouvent déjà ...

Si vous confirmez que le + simple est de l'effacer, je le fais (en fait je vais le renommer tout simplement) et je retente une connexion en SSH.

Vous confirmez ? (tapez Y or N )

 

[Cram28]

Y
Et je reste en ligne...

Le renommer/déplacer, pour gérer le... «risque».

 

[nounours1895]

Bravo il y a du mieux, je suis arrivé à me connecter, mais la ligne que j'ai mis dans un rectangle rouge m'inquiète un peu !

C'est quoi ce message "could not chdir...":

,

Et puis-je continuer avec SSH pour passer le fameux script qui permet d'utiliser des NVMe non Synology avec un NAS Synology ??

Mille mercis pour votre temps

 

[Cram28]

(je parie que le nouveau fichier à 2 lignes)

Par contre je ne suis pas compétent sur Syno ...

Lorsqu'on se connecte en ssh, on le fait avec un compte utilisateur défini et connu sur le serveur :
ssh <user>@<@IP ou nom du distant> [-p <port>].

Chaque compte sur le distant a un <home>: un répertoire à lui sur le serveur. Le message indique que le compte utilisé est défini (il l'est puisque connexion ok) mais le dossier propriétaire /var/services/homes/synoboss_admin ne semble pas exister: le client ssh échoue à s'y rendre car il n'existe pas...

Je ne saurais dire pourquoi, ni s'il y a un lien avec les manip. matérielles antérieures (montage NVMe)...

Vos manip. de script semblent devoir être faites en 'root' puisque élévation de privilèges avec sudo -i, et le root se moque bien des dossier utilisateurs... Donc oui pour poursuivre à mon avis...

@+
NB: il est préférable de faire des copies de texte - chaque fois que c'est possible - que des copies d'écran: les infos peuvent être reprises dans les échanges...

 

[nounours1895]

(je parie que le nouveau fichier à 2 lignes)

Ah ça c'est sûr !

Lorsqu'on se connecte en ssh, on le fait avec un compte utilisateur défini et connu sur le serveur :
ssh <user>@<@IP ou nom du distant> [-p <port>].

Exact: c'est ce que j'ai fait.

Le message indique que le compte utilisé est défini (il l'est puisque connexion ok) mais le dossier propriétaire /var/services/homes/synoboss_admin ne semble pas exister: le client ssh échoue à s'y rendre car il n'existe pas...

c'est bien ça qui me paraît bizarre puisque cet utilisateur est le compte admin du NAS ! donc ce répertoire devrait exister non ??

---> est-ce que je contacte le support Synology pour avoir une explication ???

Vos manip. de script semblent devoir être faites en 'root' puisque élévation de privilèges avec sudo -i,

Oui puisque le script fait reconnaitre au Syno des NVMe que Synology lui a volontairement interdit d'utiliser comme groupe de stockage car ils ne sont pas de marque Synology : dit autrement leur prix n'est pas multiplié par 5...

Donc oui pour poursuivre à mon avis...

Donc je continue demain, car là il se fait tard, et je préfère être frais pour ce genre de choses...

Mille mercis pour votre temps et à demain pour la suite !

 

[nounours1895]

Me voici de retour, et avec de bonnes nouvelles jusqu'à présent.

J'ai passé le script miracle "syno_enable_m2_volume.sh" disponible sur Github ici: https://github.com/007revad/Synology_enable_M2_volume
et tout s'est parfaitement passé.

Je pense qu'il faudrait élever une statue en reconnaissance au développeur qui s'appelle "007revad" pour nous sauver des griffes de Synology et de son racket volontaire ! de surcroît les NVMe étiquetés Synology sont de taille ridiculement petite par rapport à ce qui se fait sur le Marché aujourd'hui, Synology ferait donc mieux de supprimer le blocage de DSM et autoriser l'usage de NVMe comme le font toutes les autres marques de NAS...

A la fin du script j'ai voulu tout lire en détail, donc je n'ai pas tapé "yes" assez tôt pour lancer le reboot du NAS depuis le script, donc j'ai lancé le redémarrage depuis DSM après avoir tout lu.

Après le redémarrage, je suis retourné dans DSM, et j'ai pu sans aucun souci créer un nouveau Groupe de Stockage avec les 2 disques NVMe: je l'ai créé en JBOD pour maximiser l'espace disponible, mais je n'aurai pas de données critiques sur les NVMe.

Ensuite, j'ai créé un volume (volume2) dans ce groupe de stockage 2.

Puis j'ai créé les dossiers partagés dans ce volume2.

Bref, ce script permet de faire tout ce que Synology devrait arrêter de bloquer sans aucne raison autre que purement commerciale (la preuve c'est que toute les autres marques ne bloquent pas l'utiisation de NVMe tiers).

J'ai une question sur la possibilité de bloquer les màj de la BDD lors des updates de DSM, mais ça fera l'objet dun fil à part pour ne pas surcharger.

*** J'ai pris des captures écran de toutes les étapes depuis le lancement du script SSH jusqu'à la création du Groupe/Volume/Dossiers partagés dans DSM: pensez-vous que cela serait utile à certains si je postais ces captures ? ***


Merci à tous ceux qui m'ont aidé !