Aller au contenu

[TUTO] Accès SSH et ROOT via DSM 6 et 7


unPixel

Messages recommandés

L'extension .swp c'est ce qui est ajouté à la fin d'un fichier quand il est en cours d'édition dans un éditeur de texte comme nano ou vim, et que la session SSH a été déconnectée sans sortir du fichier.

Déjà tu le renommes, en SSH via la commande mv ou via WinSCP en authorized_keys.

Ensuite, tu n'as qu'à l'éditer (via WinSCP il y a un éditeur, sinon via la commande nano ou vim en SSH), supprimer les lignes (chaque ligne correspond à une clé) que tu veux enlever et ajouter la clé publique du périphérique qui veut se connecter (si tu as généré ta clé par Putty, tu lances PUTTYgen et tu cliques sur "Load" pour sélectionner ta clé privée, dans le premier cadre tu verras la clé publique, c'est ce que tu dois copier dans le fichier authorized_keys).

Dernière remarque par rapport à ta commande mkdir, c'est normal que ça ne marche pas, il faut ajouter -p si tu souhaites créer un fichier dans un répertoire en cascade.

Modifié par .Shad.
Lien vers le commentaire
Partager sur d’autres sites

Hello tout le monde !

 

En voulant me lancer dans le tuto de création du certificat Wildcards LE de @oracle7 je suis passé par ce tuto de @unPixelque j'ai suivi à la lettre mais je suis bloqué sur un problème dont je n'arrive pas à trouver l'origine.

En effet, depuis WinSCP comme depuis PuTTY, le serveur rejette ma clé....vous voyez ce qui peut clocher ?

image.png.07d5407cdc572c6c7ebd9c79c6c7fb16.png

Lien vers le commentaire
Partager sur d’autres sites

Le 21/08/2017 à 02:21, unPixel a dit :

Copiez et collez la commande "vi /root/.ssh/authorized_keys" puis validez en appuyant sur "entré".




vi /root/.ssh/authorized_keys

Arrivé ici, appuyez sur la touche i pour entrer en mode édition puis collez ici la clé publique que vous avez obtenu. Une fois la clé collée, appuyez sur "echap" et taper ":wq" puis faite "entré".




:wq

Tapez exit puis "entré" deux fois afin de quitter PuTTY.

Bonjour @.Shad. j'ai exactement le meme problème que @AlexisG

peut etre la version Putty qui a évolué depuis , meme les commandes ne sont pas pareil mais moi la clé ne s'enregistre pas,

appuyer sur la touche i n' a aucun effet , c'est E pour édition et l' enregistrement ne se fait pas ,et wq affiche bien recording . Après la sortie cession je vérifie et le fichier authorized_keys est vide

 

 

21013111505525080617238104.jpg

 

21013112141725080617238131.jpg

 

Modifié par Pascalou59
Lien vers le commentaire
Partager sur d’autres sites

La suite de caractères qu'on voit dans ta dernière impression d'écran ne correspond pas à du tout à une clé publique, ni même privée.

Voici ce que tu dois copier dans le fichier authorized_keys :

ssh-public-key.png

Mon premier conseil est de reprendre le tutoriel, il y a eu visiblement une grosse confusion quelque part (voir ma première remarque).

Si tu n'y arrives toujours pas, voilà un chemin alternatif : je te conseille de supprimer ton fichier authorized_keys actuel, et de recréer un fichier vide :

touch ~/.ssh/authorized_keys

On sécurise les accès :

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Quand c'est fait, tu peux effectivement passer par vi, beaucoup d'utilisateurs ont suivi le tutoriel avant vous sans rencontrer de problème, donc c'est dans l'application des consignes que ça coince. Pour utiliser un éditeur de texte plus facile, tu peux télécharger le paquet SynoCLI File Tools de Synocommunity (voir ici pour ajouter ce dépôt si tu ne l'as pas déjà fait), il comprend nano qui est beaucoup plus simple d'utilisation que vi.

nano ~/.ssh/authorized_keys

Tu copies ta clé publique dans PUTTYgen (voir impression d'écran ci-dessus), et tu cliques droit dans la fenêtre SSH, ça va ajouter la clé, tu fais CTRL+O, Entrée puis CTRL+X pour sortir. Tu quittes la session SSH et tu tentes de te connecter via la clé comme le décrit le tutoriel.

Modifié par .Shad.
Lien vers le commentaire
Partager sur d’autres sites

Il y a 4 heures, .Shad. a dit :

Voici ce que tu dois copier dans le fichier authorized_keys :

Merci @.Shad. ! Mon problème venait bien de là.

A la base j'avais ouvert dans un éditeur de texte ma clé publique et j'avais bêtement fais un copier / coller de tout le contenu du fichier.

Avec ta méthode ça marche tout de suite mieux et je n'ai plus de problème à présent.

Merci !

@Pascalou59 peut-être ton problème se situe à ce niveau également.

Lien vers le commentaire
Partager sur d’autres sites

Je viens de procéder à l’installation de ces deux fameuses clés qui facilitent bien l’usage de PuTTY  et de WinSCP en « mode root ».

Tout fonctionne parfaitement bien mais il est vrai que la mise en œuvre du copier/coller avec Vi, c’est une horreur pour les « non linuxiens ».

Personnellement, je suis passé par la constitution du fichier « authorized_key » sous Windows puis l’ai copié avec les commandes de PuTTY en mode root.

Toujours est-il, un grand merci à unPixel et aux autres intervenants pour ce super Tuto

Modifié par marmottin
compléments
Lien vers le commentaire
Partager sur d’autres sites

  • 1 mois après...

J'ai lu le tuto avec beaucoup d'intérêt mais je me pose des questions.

Je suis sur Mac.

Les règles que j'ai créés dans le pare-feu interdisent l'utilisation de SSH en dehors du réseau local et je suis le seul administrateur du NAS. Le port utilisé par SSH (qui n'est pas celui d'origine) n'est pas redirigé par la box. Reste-t-il alors un danger concernant SSH ?

J'ai changé de NAS récemment et lorsque je me suis connecté pour la première fois, il y a eu un message d'avertissement me disant que la clé n'était pas valide. Mais le message pointait un fichier known_hosts qui se trouve sur le Mac à l'adresse /users/moi/.ssh.

J'ai donc fait une copie de ce fichier puis détruit l'original. Lorsque je me suis connecté par la suite un message m'a indiqué que je devais me montrer responsable, bla, bla, bla. Mais le fichier known_hosts a été recréé sur le Mac avec une clé sans que je fasse quoique ce soit. Après, j'ai supprimé la copie du fichier faite précédemment et depuis tout roule.

Y a-t-il une menace que je n'ai pas vue ?

Modifié par CyberFr
Port SSH non redirigé
Lien vers le commentaire
Partager sur d’autres sites

Dans la mesure où l’accès ssh n’est pas possible de l’extérieur oui, ça sécurisé
Maintenant, si en interne réseau filaire ou piratage wifi . un accès se réalise puisque l’accès est dispo.

La sécurité c’est toujours une question de niveaux et de risque .
si pas besoin du ssh, alors on le désactive et on l’active à la volée

Sinon on imagine d’autres solutions supplémentaires... a voir la pertinence eu égard aux risques...

Lien vers le commentaire
Partager sur d’autres sites

  • 1 mois après...

Bonsoir, 
Pas de problème pour moi pour suivre ce tuto. Merci
Cependant j'ai un soucis avec la dernière étape : Redémarrer le service SSH.
Je suis sous DSM7 et j'ai en réponse à la commande

synoservicectl --reload sshd

J'ai
-ash: synoservicectl: command not found

Une idée ? Merci

Modifié par GrOoT64
Lien vers le commentaire
Partager sur d’autres sites

je vais refaire on sait jamais mais j'ai fait tout le tuto avant

Edit : 
Alors j'ai testé via Putty et WinSCP qui ont tous les 2 l'identification "root" via passphrase qui fonctionne parfaitement et le service ssh ne veut rien savoir. 

Modifié par GrOoT64
Lien vers le commentaire
Partager sur d’autres sites

bonjour @GrOoT64,

de ce que je viens de regarder, sous DSM7, les packages sont gérés via "systemctl" :

bruno@ds918blam:~$ systemctl status sshd
● sshd.service - OpenBSD Secure Shell server
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: disabled)
  Drop-In: /usr/lib/systemd/system/sshd.service.d
           └─synorelay-service-handler.conf
   Active: active (running) since Wed 2021-05-12 17:14:51 CEST; 2 days ago
 Main PID: 8225 (sshd)
   CGroup: /sshd.slice/sshd.service
           ├─ 4420 sleep 1
           ├─ 4481 systemctl status sshd
           ├─ 8225 sshd: /usr/bin/sshd -D [listener] 0 of 10-100 startups
           ├─13125 sshd: bruno [priv]
           ├─13418 sshd: bruno [priv]
           ├─13419 sshd: bruno@pts/0
           ├─13662 -sh
           ├─13732 sshd: bruno@notty
           ├─13733 sh -c while [ -d /proc/$PPID ]; do sleep 1;head -v -n 8 /proc/meminfo; head -v -n 2 /proc/stat /proc/version /proc/uptime /proc/loadavg /proc/sys/...
           └─13736 sshd: bruno@internal-sftp

Mais si Synology a fait des utilitaires spécifiques, c'est qu'ils doivent bien faire quelque chose de plus ?

Donc sous DSM7 il y a la commande Syno "synosystemctl" :

bruno@ds918blam:~$ synosystemctl -h
synosystemctl {COMMAND} ...

Commands:
  start [--no-block] NAME...              Start (activate) one or more units
  stop [--no-block] NAME...               Stop (deactivate) one or more units
  enable NAME...                          Enable one or more unit files
  disable NAME...                         Disable one or more unit files
  restart [--no-block] NAME...            Start or restart one or more units
  try-restart [--no-block] NAME...        Restart one or more units if active
  reload [--no-block] NAME...             Reload one or more units
  reload-or-restart [--no-block] NAME...  Reload or restart one or more units
  reenable NAME...                        Reenable one or more unit files
  isolate [--no-block] NAME...            Start one unit and stop all others
  mask [--runtime] NAME...                Mask one or more units
  unmask [--runtime] NAME...              Unmask one or more units
  uninstall NAME                          Remove units from system, as well as relating symlinks and flags
  daemon-reload                           Reload unit config
  get-default                             Get the name of the default target
  set-default NAME                        Set the default target
  get-enable-status NAME                  Get the enable status of given unit
  get-active-status NAME                  Get the active status of given unit
  get-load-status NAME                    Get the load status of given unit
  stop-service-by-reason REASON NAME...   Stop one or more services by a reason
  start-service-by-reason REASON NAME...  Start one or more services by a reason
  remove-service-reason REASON NAME...    Remove reason for one or more services
  list-service-reason NAME                List service reason
  get-unit-by-pid PID                     Get unit name that the pid belongs to
  list-service-by-mnt-path PATH           List services using given mount path
  register-volume NAME VOLUME             Register a volume for a unit
  package-register-volume NAME VOLUME     Register a volume for a package
  unregister-volume NAME VOLUME           Unregister a volume for a unit
  package-unregister-volume NAME VOLUME   Unregister a volume for a package

Donc dans ton cas 2 options a priori :

  • via la commande native systemctl : systemctl restart sshd
  • via la commande syno : synosystemctl restart sshd

Cdt, bruno78

PS : et oui, le login root c'est toujours avec la clé ssh !

Modifié par bruno78
Lien vers le commentaire
Partager sur d’autres sites

@GrOoT64 parfait !

Pour l'accès root, je vérifie cela dans la journée. Je l'ai fait, je suis sûr que ça marche, mais .... là il faut que je régénère un jeu de clé .... je ne suis pas dispo ce matin .... . J'ai fait un peu trop de ménage depuis .....

Lien vers le commentaire
Partager sur d’autres sites

@bruno78 : Merci mais tout est bon pour moi 🙂 
J'ai mes clefs publiques dans Putty et/ou WinSCP et ces derniers me demandent ma passphrase pour me connecter. C'est exactement le but de ce tuto donc RAS 😉

Maintenant je suis emmerdé par le serveur FTPS.... C'est une autre histoire ^^
Dès que le NAS est connecté en VPN, je perds le FTPS.
Ma config :

 image.png.b018ad6387fb6e59cb9fbc86b63db92e.png
 

Je précise que je n'ai pas d'IP fixe et j'ai activé les passerelles multiples

Lien vers le commentaire
Partager sur d’autres sites

@GrOoT64 content que cela fonctionne chez toi.

Du coup j'ai tenté de régénérer une nouvelle paire de clés pour l'accès root au NAS, et j'ai invariablement un refus :

image.png.5b084f1ac531a3c5cf671bbc405be880.png

Il me semble pourtant avoir suivi le Tuto correctement .... . je referai à tête reposée.

Pour le FTPS, je ne sais pas trop a priori ... .

Lien vers le commentaire
Partager sur d’autres sites

@GrOoT64 j'ai ça dans la clé publique (j'ai tronqué le milieu):

bruno@ds918blam:~$ sudo -i
Password:

root@ds918blam:~# cat /root/.ssh/authorized_keys
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20210515"
AAAAB3NzaC1yc2EAAAABJQAAAf8kQ9Tjubc3LnoB3fehcYe/adZDpuvRJL1pP0XU
h3/GR/pvoCq107QkY85cwQaTNGGih/8Dfs3wfjO2v6r+unlyHoyOLoSoTdJIjaVd
[......]
DQbDEShnudMIRd7qxb/D28f1asNRj5piBqDqGn5IDZFJGd3I+MtzunUBN+boEMVK
ETKt/0Zg2PPV9RvLwXxqfUzbXf+JF6cVn2zSXhKEpyFXEKQkm4z9FQjuTmGxdQ0f
9O4J
---- END SSH2 PUBLIC KEY ----
root@ds918blam:~#

Question bête cependant : comment on sait si on est en "vrai" root ou pas ? J'ai un doute tout d'un coup ....

@GrOoT64 OK c'est bon à présent, merci. Effectivement, il faut bien copier/coller ce qui est donné dans la fenêtre de puttyKey Generator, et rien d'autre.

Donc OK.

Mais, je n'y avais pas trop prêté attention, si je fais "simplement" un sudo -i depuis un compte admin, je semble me retrouver en vrai root sans passer par la clé ssh privée/publique ? est-ce une illusion ? comment le vérifier ?

Synology strongly advises you not to run commands as the root user, who has
the highest privileges on the system. Doing so may cause major damages
to the system. Please note that if you choose to proceed, all consequences are
at your own risk.

bruno@ds918blam:~$
bruno@ds918blam:~$
bruno@ds918blam:~$ sudo -i
Password:
root@ds918blam:~# whoami
root
root@ds918blam:~#

 

Modifié par bruno78
Lien vers le commentaire
Partager sur d’autres sites

La clé SSH c'est pour une connexion distante.

C'est normal de ne pas utiliser la clé pour te connecter en root depuis un autre utilisateur.

Effectivement tu avais mis ta clé privée au lieu de ta clé publique, la clé privée reste uniquement sur le périphérique qui se connecte.

En gros la clé publique c'est ta réservation au restaurant, et la clé privée c'est le fait de prouver ton identité.

Lien vers le commentaire
Partager sur d’autres sites

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.