il y a 45 minutes, oracle7 a dit :

Edit : Tout cela milite pour l'usage de WinSCP qui te permet de lancer un éditeur de texte tiers de ton choix directement depuis l'arborescence de DSM en SSH.

 

Oui tout à fait ^^ Je l'ai configuré pour utiliser VSCode 😄

Par contre, avec WinSCP, j'ai des caractères accentués qui ne passent pas... Et hormis le réglage UTF8 pour les transferts de fichiers, je trouve pas où changer le réglage pour ça ...
Petite capture pour illustrer :

il y a une heure, oracle7 a dit :

Apt-get n'est pas installé sous DSM

oui désolé j'ai répondu un peu vite.

@MilesTEG1

Bonjour,

il y a 29 minutes, MilesTEG1 a dit :

Par contre, avec WinSCP, j'ai des caractères accentués qui ne passent pas...

A part mettre l'encodage par défaut UTF8 pour l'éditeur interne. Je ne vois pas non plus, désolé.

Cela dit, le système UNIX à la base (et donc DSM même si cela semble passer avec lui), n'aime pas les caractères accentués et certains caractères spéciaux (idem aussi Windows parfois avec netbios).

Si j'étais toi je prendrais l'habitude de ne pas les utiliser dans les noms de fichiers sous UNIX/Linux. Crois-moi cela t'évitera des déconvenues. Maintenant c'est toi qui voit ...

Cordialement

oracle7😉

 

Il y a 1 heure, oracle7 a dit :

Tout cela milite pour l'usage de WinSCP qui te permet de lancer un éditeur de texte tiers de ton choix directement depuis l'arborescence de DSM en SSH.

C'est bon pour les systèmes à fenêtres mais sur Mac ça me semble compliqué de l'utiliser ☹️ Et BBEdit qui fait très bien son boulot d'éditeur de texte dans le terminal sèche en SSH.

@CyberFr

Bonjour,

il y a une heure, CyberFr a dit :

C'est bon pour les systèmes à fenêtres mais sur Mac ça me semble compliqué de l'utiliser

????? pourquoi le Mac n'est pas aussi un système à fenêtres ? 😜

il y a une heure, CyberFr a dit :

dans le terminal sèche en SSH

Qu'as-tu voulu dire ? 😋

Cordialement

oracle7😉

Modifié le 6 septembre 20214 a par oracle7

@bliz

Bonjour,

1. Juste pour ta gouverne, dans tes réponses, il n'est pas nécessaire de re citer le post précédant dans sa totalité, ce serait bien que tu ne cites que la partie à la quelle tu réponds, cela surcharge moins les posts et ils sont plus faciles à lire. Merci.

2. Le MdP root est normalement celui de ton utilisateur "admin" (activé ou pas). Ensuite pour passer sous root en étant connecté avec ton pseudo (qui a des droits d'admin) tu tapes simplement la commande "sudo -i".

Cordialement

oracle7😉

 

@oracle7

Certes le Mac est un système à fenêtres mais il ne s'appelle pas Windows 🙂

BBEdit ne peux rien faire en SSH car ce n'est plus l'environnement Unix du Mac. Je parle des extensions en ligne de commande qui permettent d'ouvrir et d'éditer un fichier.

J'ai tenté de me connecter au NAS en SFTP avec BBEdit mais je n'ai accès qu'aux dossiers partagés ce qui limite considérablement l'intérêt de la manœuvre.

Il y a 2 heures, CyberFr a dit :

C'est bon pour les systèmes à fenêtres mais sur Mac ça me semble compliqué de l'utiliser

C'est-à-dire ?

VScode fonctionne parfaitement sur macOS 😉 

il y a 16 minutes, MilesTEG1 a dit :

VScode fonctionne parfaitement sur macOS

J'avais en effet  oublié cette plateforme de développement aussi légère qu'un mammouth 🙃

Vous déviez du sujet sur les derniers posts quand même...

@bliz : Il n'est pas possible de se connecter directement en root avec un mot de passe. Le seul moyen c'est avec une clé. En suivant ce tutoriel (et ce tutoriel uniquement, on ne parle pas de WinSCP), où bloques-tu ?

Ce n'est pas possible d'installer la clé (ils utilisent bêtement ssh-copy-id en fait) car pour le faire la première fois il faut se connecter avec un mot de passe, et ce n'est pas possible en root.

Donc la bonne manière de faire c'est entre autres en suivant les instructions de ce tutoriel.

Salut,

Je me pose une petite question...

J'ai suivi ce tuto pour assurer un accès au NAS via ssh. Le truc c'est qu'on ne peut plus se connecter avec un utilisateur lambda du syno par ce biais (ni même avec l'utilisateur admin) si je comprends bien ?

La clef étant enregistrée juste pour le root. J'ai juste?

@Bajoum

Bonjour,

Il y a 1 heure, Bajoum a dit :

La clef étant enregistrée juste pour le root. J'ai juste?

OUI. De toutes façons bon nombre de commandes sont à réaliser sous root alors à mon humble avis il n'y a que peu d'intérêt à rester sous une autre utilisateur sauf si tu ne maîtrises pas tout alors oui il vaut mieux rester prudent.

C'est donc possible de se connecter avec un USER non root. Sous PuTTY par exemple tu indiques juste l'@IP du périphérique auquel tu veux te connecter et dans la fenêtre de terminal qui s'ouvre il te demandera : "login as". Tu saisis alors le pseudo/Id de ton utilisateur puis son mot de passe. Ensuite si tu as besoin de passer sous root tu tapes simplement : "sudo -i", (je ne me souvient plus s'il te demande le MdP root) et tu te retrouves dans une session sous root. Tu tapes "exit" pour en sortir à la fin et là tu reviens sous ton utilisateur originel.

Cordialement

oracle7😉

 

@oracle7, merci une nouvelle fois pour tes explications.

Je suis sous linux, j'ai pas besoin de me casser la tête avec PUTTY ou autre 🙂

De toute manière, je n'ai pas autorisé l’authentification par mot de passe dans le fichier de config (juste la clef). Et après tout, je trouve cela plus secure qu'un seul utilisateur puisse s'y connecter donc je valide à 100% cette façon de faire.

Salut, 

je suis en version DSM 6.2.4-25556 Update 5 et j'ai voulu me connecter après un moment d'inactivité et de mise a jour, et cela ne fonctionne plus.

C'est toujours possible ou il faut faire une manipulation ?

Merci.

Cordialement.

@cyberbob69

Bonjour,

Vérifies que tu utilises la bonne key passphrase pour te connecter.

Cordialement

oracle7😉

 

@oracle7

Salut, 

Pour je ne sais quelle raison, le numéro de port dans winscp était 22 et celui dans le nas synology était à 24 !

J'ai donc fait concorder les n° de port et maintenant tout fonctionne comme avant 🙂

les key et passphrase sont toujours fonctionnelle.

 

Bonjour,

Pour relancer le service ssh, mon syno ne connait pas la commande suivante:

synoservicectl --reload sshd

A la place j'ai dû lancer:

systemctl restart sshd

Voilà, voilà sinon tout le reste c'est ok.

Bonjour,

 

Merci @unPixel pour ce tuto détaillé, et efficace !

En revanche, j'ai eu le même problème que @Bajoum avec la commande suivante: synoservicectl --reload sshd

Ce qui fait que j'ai testé l'alternative proposé justement par @Bajoum, et qui fonctionne parfaitement (merci également, du coup 🙂 ).

Modifié le 18 février 20232 a par KreaNum

@KreaNum, pour votre information, le regretté unPixel nous a malheureusement quitté fin 2022.

Ce tuto a été créé sous DSM6. Certaines commandes syno ont été modifiées avec DSM7, ce qui explique le problème rencontré.

Je ferai à l'occasion une mise à jour du tuto pour indiquer la modification.

@Mic13710

Ah, mince, toutes mes condoléances... 😕

Pas de soucis pour la modification, c'était juste pour confirmer que l'alternative fonctionne bien, afin de mettre les futurs lecteurs sur la bonne piste.

Voilà, c'est fait. Tuto mis à jour pour DSM7

Bonjour, merci pour le tuto tout fonctionne chez moi.

J'ai tout de même une petite question.

Quelle est la différence entre : 

• un accès SSH uniquement avec une clé protégée par un mot de passe de 20 caractères
• un accès SSH via un user qui a les privilèges admin + cmd "sudo -i" et un mot de passe de 20 caractères

Le résultat est le même, c'est l'accessibilité qui change.
L'avantage d'avoir une authentification par clé, c'est que ça exclut d'emblée tous les périphériques dont les clés publiques n'ont pas été ajoutées au fichier authorized_keys.

L'autre intérêt d'une clé (mais sans mot de passe) est de permettre l'exécution de scripts à distance.