Mon serveur debian ne communique pas avec mon NAS Synology par SSH

Support Debian
Tags: #<Tag:0x00007f4e63bca5d0>
#1

Bonjour à tous et mes meilleurs vœux pour cette nouvelle année.

Bon d’emblée je précise que je suis totalement nouveau sur linux et debian en particulier. Je totalise tout au plus une dizaine d’heures de pratique.

J’ai monté un serveur debian 13 récemment en raid 1 avec un volume partagé sous samba pour en faire un serveur de fichiers. Comme le raid n’est pas une solution de sauvegarde en soi, j’aimerais pouvoir sauvegarder ce répertoire partagé sur mon NAS Syno qui est lui même en raid 1. Après recherche et comme Syno ne propose pas pour l’instant son appli qui soit compatible debian 13, j’ai retenu BorgBackup et un de ses front ends (en l’occurrence Vorta) pour faire cela mais voilà je rencontre des problèmes de connexion en ssh je pense.

J’arrive à me loguer en ligne de commande sans problème au NAS mais quand je passe par Vorta et que je tente de définir mon dépôt de sauvegarde, cela me refuse la connexion (permission denied retourné par le Syno). Ma clé SSH semble pourtant bien être configurée sur mon serveur. Borg est bien installé sur le Syno. Les utilisateurs spécifiques bien déclarés et autorisés.

Une question m’interpelle : A la création de la clé, 2 fichiers sont crées dont un public qui renferment la clé. Je pense que ces 2 fichiers doivent aussi être présents dans le répertoire partagé du Syno pour que la vérification de la clé puisse s’opérer en client-serveur non ? Vous pouvez me confirmer cela ?

Sinon si vous voyez une erreur que j’ai faite, merci de me donner votre avis…

Bien à vous tous

#2

Salut @Marc320, depuis quelque temps maintenant (plusieurs années), Synology refuse de donner accès SSH aux comptes qui ne sont pas dans le groupe admin. Ce sujet fait couler beaucoup d’encre, mais apparemment Syno s’en fout… Une discussion intéressante (parmi d’autres) sur le sujet :

Alors par contre, selon l’utilisation qui est faite de SSH, tu peux avoir un genre de contournement. Si c’est pour utiliser un shell en interactif, je pense que c’est mort, et que tu dois utiliser un compte dans le group admin. Si c’est pour autre chose (par exemple, moi j’utilise SSH pour synchroniser mon git local vers le remote Synology), alors ça peut fonctionner, pour ceci il faut sur ton Syno modifier le shell par défaut de ton utilisateur, dans le fichier /etc/passwd :

Remplace en fin de ligne :

ton_user:x:1045:100::/var/services/homes/ton_user:/sbin/nologin

Par :

ton_user:x:1045:100::/var/services/homes/ton_user:/bin/sh

Est-ce que ce que j’expose ici ressemble bien à ton cas de figure ?

#3

Bonjour,

C’est à dire? quel NAS as tu et quel OS Synology est en place?
j’ai un DS418 sur lequel je synchronise des fichiers avec partir de Synology Drive. L’appli est mises sur le NAS, et j’utilise le client sous Debian 13 pour synchroniser, soit par backup manuel ou programmés, soit par synchronisation en temps réel.

#4

Bonjour, la solution Syno que j’essaye de mettre en œuvre est Active Backup For Business, mais s’il y en a une autre qui fait le taf pourquoi pas ? Merci (NAS 718+ avec DSM 7.3.1-86003 Update 1)

#5

Bonjour Thierz,
Effectivement c’est assez édifiant comme attitude chez Synology et que l’on doive bidouiller pour trouver une solution de contournement… Mais tout cela me semble bien délicat pour le néophyte que je suis.
J’ai vérifié sur le Syno et l’utilisateur que j’ai crée spécifiquement pour les sauvegardes est dans le groupe administrateur avec les bonnes autorisations. Quand cet utilisateur se connecte en shell ssh au dossier de sauvegarde distant il n’y a pas de problème (et je peux faire du rsync) mais impossible quand même de se connecter en lançant borg par vorta. Je pense que j’ai un problème avec les autorisations et la configuration dans borg et je vais refaire tout cela.
Si cela ne fonctionne pas, je vais essayer de faire une config rsync qui lui a l’air de fonctionner.

Dans tous les cas merci de vous être penché sur mon problème.

#6

Ton serveur n’a pas beosin par définition de communiquer en SSH avec ton NAS.
D’autant que bord est dispo sur synology. donc une fois correctement fait le paramétrage coté NAS tu ne devrais pas avoir de problème.

Attention Vorta a des décalage avec les différentes versions de Borg.
Attention a avoir les mêmes versions au deux bout c’est plus sur.

Non sur une appliance de ce type, un user normal n’a pas besoin d’un accès SSH.
Sinon à quoi bon avoir une distinction. C’est une question de granularité de la sécurité.
C’est comme permettre à tout le monde d’avoir accès aux commandes root avec sudo. C’est aussi débile que ça en a l’air. Si on doit avoir accès à toutes les commande, alors on est admin avec l’accès idoine. Sinon on ne doit avoir accès en sudo qu’à des commandes précises et calibrées (c’est à dire avec une gestion des options accessibles).
Sujet qui a longtemps fait débat et qui ne fait plus aucun débat dans le milieu de la sécurité.

Si tu dois faire un contournement, c’est soit que tu veux faire quelque chose avec ton SYno qui n’est aps prévu de base, soit que tu es sur un problème XY (ce qui est majoritairement le cas dans ce type de problématique).

Pour borg, je pense qu’il y a un défaut de configuration quelque part. et pour y revenir attention, il y a un décalage de version de Borg entre Syno et Debian, qui fait que Vorta peut ne pas fonctionner correctement.

Et en passant, parle-t-on d’un usage professionnel ou personnel?

#7

Ca se discute. Pour un accès au shell, je peux comprendre. Pour une utilisation « autre » utilisant juste le SSH comme canal d’accès, je suis plus mitigé. Prends mon cas d’usage, utilisant SSH pour faire git push de mon dossier git vers le remote Synology : quel besoin ai-je de donner les droits d’admin au compte utilisateur de git ?

#8

tu utilise l’application Synologie de Git?

#9

Oui c’est ça, le paquet Git Server version 2.33.0-0126 édité par Synology Inc.

#10

ben apparemment si tu veux faire du SSH avec des clef faut être admin. Sinon c’est login mot de passe.

Après le paquet Git c’est un paquet de la communauté, donc moins fiable qu’un paquet Synology normalement. beaucoup de ces paquets ont des trous dans la raquette.

En tout cas on peut configurer coté serveur un compte qui n’est pas admin pour accéder à Git.

Mais coté config, c’est le plus minimum qui puisse se concevoir. Perso ce n’est pas un paquet que j’utiliserais.