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

[.Shad.]

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é le 28 janvier 2021 par .Shad.

[AlexisG]

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 ?

[.Shad.]

Si le serveur refuse ta clé c'est qu'elle n'est pas correctement encodée dans le fichier authorized_keys.

Reconnecte-toi sans la clé, et vérifie que la clé publique est identiquement présente dans le fichier authorized_keys.

[Pascalou59]

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

 

 

 

 

Modifié le 31 janvier 2021 par Pascalou59

[.Shad.]

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 :

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é le 31 janvier 2021 par .Shad.

[AlexisG]

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.

[marmottin]

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é le 31 janvier 2021 par marmottin
compléments

[Diplo95]

Merci infiniment pour ce tuto.

J'ai eu des difficultés pour comprendre comment copier/coller avec vi, mais quelques recherches rapides ont résolus mes interrogations.

[CyberFr]

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é le 26 mars 2021 par CyberFr
Port SSH non redirigé

[DaffY]

Bonjour,

Par défaut lors d’un 1 en échange signé, une clée est générée sur le périphérique ( c’est le cas avec Terminal).

[CyberFr]

Merci @DaffY pour la réponse. La question que je me pose est de savoir si , dans le contexte que je décris, l'accès SSL est suffisamment sécurisé sur le NAS.

[DaffY]

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

[CyberFr]

Dans la mesure où je n'utilise pas SSH tous les jours, je crois que je vais fermer l'accès en dehors de mes périodes d'interventions.

[_DR64_]

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é le 15 mai 2021 par GrOoT64

[.Shad.]

Tu as ajouté sudo devant ? Tu es bien connecté en root ?

[_DR64_]

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é le 15 mai 2021 par GrOoT64

[.Shad.]

Je ne crois pas qu'on puisse se loguer directement en root avec une passphrase, seulement avec une clé SSH.

[bruno78]

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é le 15 mai 2021 par bruno78

[_DR64_]

Bonjour @bruno78 :
Merci pour tes recherches ! 


Sauvé ! 

Parfait 🙂

Modifié le 15 mai 2021 par GrOoT64

[bruno78]

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

[_DR64_]

@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 :

 
 

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

[bruno78]

@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 :

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

[_DR64_]

@bruno78 : Ta clé publique commence bien par ça : 

Clé publique : 
ssh-rsa AAAAaAaaaAaAAaAA parce que les 1ere fois j'avais la même erreur et ça venait du petit bout que j'avais oublié ^^

[bruno78]

@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é le 15 mai 2021 par bruno78

[.Shad.]

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