DSM 6 - Log as root - Putty & WinSCP

[tops]

Hello,

Ayant trouvé mon chemin pour me log en root, je vous donne la recette ;-)

Pour commencer, je n'ai rien inventé, j'ai trouvé mon inspiration ici : http://www.mauchle.name/blog/?p=239&cpage=1#comment-29143

Mes modifications sont en "jaune".

 

(1) Download PuTTY and PuTTYgen (or just get the installer, everything is in there).

(2) Generate a keypair with PuTTYgen (Parameters: SSH-2 RSA)

(3) Save the private key as “myprivatekey.ppk”

(4) Copy the public key to the clipboard. Looks somewhat like this :

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIEAzP4MR3lkCD2pa7nwT3NMjjDBMmEuJ4exW4GKBBP+okArZ/IrjbLIpdh8ahpfgjh8kM//OVUGeRa1GigzcCuGzIa2YfS7L4Q9cbUUWFwIu2hGV3ZpJ2xDZExaaLH90Vw+ZBaozD2OI4FZ1Dqh8Bj29SQqIIbmxf/ASyTmXHZCbQk= rsa-key-20130414

(5) Connect to your diskstation with PuTTY

diskstation:22

(6) Login as root admin (obviously the root will not work on DSM 6 ... so use any administrator account like the original "admin")

(7) Elevate your admin user to "root" by typing (then all your command lines will have to be precidered by "sudo " to be executed as "root") :

sudo -l -U root

*** Steps 8 to 10 are probably optional based on CoolRaoul comments .... based on my experience, sudo remains needed otherwise you will not have the rights to open / change files ***

(8) Edit the SSH config with

sudo vi /etc/ssh/sshd_config

(9) Look for the following lines (using the keyboard arrows up & down) :

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile      .ssh/authorized_keys

(10) Change them to this (by hitting “x” when the cursor is over the # and hitting ESC, then typing :wq ENTER).

There is not visible effect after having hitted ESC ... do not search and type :wq ENTER

#RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys

(11) Go to /root and create the .ssh folder

(the .ssh dir was already existing in my DSM ... try to go directly to 12.

IF the step 12 is not working ... then type

sudo -s

Then, type

cd /root
mkdir .ssh

Then, type

Exit

(12) Edit the keyfile

sudo vi /root/.ssh/authorized_keys

(13) Press “i”, paste your public key (right clic) and save the file (Hit Esc, type :wq, hit Enter)

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIEAzP4MR3lkCD2pa7nwT3NMjjDBMmEuJ4exW4GKBBP+okArZ/IrjbLIpdh8ahpfgjh8kM//OVUGeRa1GigzcCuGzIa2YfS7L4Q9cbUUWFwIu2hGV3ZpJ2xDZExaaLH90Vw+ZBaozD2OI4FZ1Dqh8Bj29SQqIIbmxf/ASyTmXHZCbQk= rsa-key-20130414

(14) Set the access-rights to the file

sudo chmod 700 /root/.ssh
sudo chmod 644 /root/.ssh/authorized_keys

(15) Disconnect with

exit

(16) Open Putty again and make the following settings

In session :

• Hostname or IP
• Port: 22
• Connection type: SSH

In Connection

• Data->Auto-login username: root
• SSH->Auth->Private Key: Your Keyfile

In session, save the session as <sessionname>

(17) Open WinSCP

• Add a new site
• Select "SFTP"
• Add the  Hostname (or IP) and SSH port
• Add as username "root"
• In Advanced > SSH > Auth > Auth parameters : select the same SSH key file as in (16) and tic the option "allow the connection agent"
• Save and log

Modifié le 16 mai 2016 par tops

[hacr]

Bonjour

J'ai scrupuleusement suivi le tuto super détaillé. 

J'ai deux résultats étonnants: putty subit un refus de clé, mais winSCP fonctionne! Avec un passphrase demandé régulièrement, ce qui est bon signe. La seule différence, c'est que je navigue en scp, pas en sftp

Merci pour ce super tuto!

[CoolRaoul]

Le 24/3/2016 at 12:12, tops a dit :

(8) Edit the SSH config with

sudo vi /etc/ssh/sshd_config

(9) Look for the following lines (using the keyboard arrows up & down) :

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile      .ssh/authorized_keys

(10) Change them to this (by hitting “x” when the cursor is over the # and hitting ESC, then typing :wq ENTER). There is not visible effect after having hitted ESC ... do not search and type :wq ENTER

#RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys

 

Les étapes 8 à 10 ci dessus sont inutiles: traditionnellement, les options en commentaire dans le sshd_config pré-installé n'ont d'autre rôle que de documenter les options par défaut. Les dé-commenter ne change donc rien

[CoolRaoul]

Le 24/3/2016 at 12:12, tops a dit :

(17) Open WinSCP

• Add a new site
• Select "SFTP"
• Add the  Hostname (or IP) and SSH port
• Add as username "root"

Je ne vois pas comment cela peut marcher: il n'est pas possible de se connecter "root" à DSM (et ça ne date pas de DSM6) en utilisant SFTP (SSH ou SCP ok par contre si on a bien enregistré la clé publique dans ~root/.ssh/authorized_keys)

Citation

• In Advanced > SSH > Auth > Auth parameters : select the same SSH key file as in (16) and tic the option "allow the connection agent"
• Save and log

L'utilisation de cette option "allow the connection agent" présuppose qu'on utilise l'agent (pageant téléchargé avec putty) alors que le tuto n'en parle pas. De plus dans ce cas, il est inutile de spécifier de "private key file" dans Auth parameters.

Le 24/3/2016 at 12:12, tops a dit :

(7) Elevate your admin user to "root" by typing (then all your command lines will have to be precidered by "sudo " to be executed as "root") :

sudo -l -U root

(8) Edit the SSH config with

sudo vi /etc/ssh/sshd_config

 

Inutile de préfixer ce "vi" (ainsi que les suivants) de "sudo" étant donné qu'on est *déjà* root (de part le "sudo -l -U root" précédent)

Il y a 4 heures, hacr a dit :

J'ai deux résultats étonnants: putty subit un refus de clé, mais winSCP fonctionne! Avec un passphrase demandé régulièrement, ce qui est bon signe. La seule différence, c'est que je navigue en scp, pas en sftp

C'est normal que ca ne fonctionne pas en SFTP : DSM ne supporte pas les connexions root dans ce mode.

Si Putty échoue avec un refus de clé c'est que le chemin du fichier de clé privé spécifié dans sa propre configuration de session (Connexion -> SSH -> AUTH -> "authentication parameters") est erroné ou manquant. Mais je te conseille d'utiliser Pageant. Lancé au démarrage de ta session windows, on y charge la clé privée et ensuite plus besoin de retaper sa passphrase jusqu'au prochain login (s'assurer pour cela que dans putty Connexion -> SSH -> AUTH -> "authentication methods", "attempt authentication using pageant" est coché))

Modifié le 7 mai 2016 par CoolRaoul

[hacr]

Du moment que je peux naviguer et modifier les fichiers en root, c’était mon essentiel pour (re)venir sur DSM 6.0. Avec le 5.2 pas besoin de toutes ces manipulations, mais je ne profitais plus des améliorations

Je réitère mes remerciements à Tops (et à FlohEinstein de l'autre forum)

[CoolRaoul]

il y a 38 minutes, hacr a dit :

Du moment que je peux naviguer et modifier les fichiers en root, c’était mon essentiel pour (re)venir sur DSM 6.0. Avec le 5.2 pas besoin de toutes ces manipulations, mais je ne profitais plus des améliorations

L'objet de mon post était essentiellement de corriger les inexactitudes du *tuto* (et c'est d'ailleurs surtout son contenu que j'ai cité), en particulier  l'indication du choix de l'option "SFTP" dans le profil WinSCP au cas ou d'autres auraient voulu l'appliquer tel quel. Au passage j'en ai profité pour en souligner ce qui était inutile et faire quelques suggestions d'amélioration de "confort" (Pageant). Ca peut toujours faire gagner du temps à certains.

J'entend bien que ça ne t'es sans doute pas utile personnellement mais ça peut servir à d'autres, et donc pourquoi s'en priver? (on est dans un forum public après tout)

Au passage j'en ai profité pour donner ce que je pense être l'explication de l'anomalie signalée: "putty subit un refus de clé, mais winSCP fonctionne!". L'ayant qualifié d'"étonnant", ca donnait l'impression que que ça attendait une réponse. Au temps pour moi.

[hacr]

il y a 36 minutes, CoolRaoul a dit :

 L'ayant qualifié d'"étonnant", ca donnait l'impression que que ça attendait une réponse. Au temps pour moi.

Il n'y a pas de mal. Par contre si tu t'y connais, je suis preneur d'une astuce sur un autre problème ici, concernant le mail station.

A bientôt

[CoolRaoul]

Il y a 15 heures, hacr a dit :

je suis preneur d'une astuce sur un autre problème ici, concernant le mail station.

Ah là par contre désolé, non seulement je n'utilise pas Mail Station mais en outre ça touche des protocoles (DKIM, DMARC) que je n'ai jamais eu l'occasion de manipuler. Faut être un peu patient pour les réponses sur des sujets pointus comme celui-la.

Toutefois j'ai comme l'impression que les deux problèmes que tu cites (DKIM/DMARC et reverse DNS) sont liés: il me semble comprendre (ref) que la cohérence du reverse DNS de l'IP source avec le nom de domaine email inclus dans la signature (champ "d") soit nécessaire pour que ça fonctionne. Dans ton cas, un reverse lookup de ton IP va répondre avec IP.rev.sfr.net ce qui ne "matche" pas. Et comme l'IP, même fixe, appartient à SFR, ca ne serait possible que si SFR te permettait de personnaliser ton reverse (comme chez Free par exemple)

Mais je le répète je ne suis pas spécialiste de cette partie.

Modifié le 8 mai 2016 par CoolRaoul

[tops]

Le 07/05/2016 à 16:21, CoolRaoul a dit :

Les étapes 8 à 10 ci dessus sont inutiles: traditionnellement, les options en commentaire dans le sshd_config pré-installé n'ont d'autre rôle que de documenter les options par défaut. Les dé-commenter ne change donc rien

Je précise que c'est optionnel dans le tuto ... par contre, je ne comprends pas bien comment le NAS va accepter la clef que l'on vient lui donner si on ne décommente pas les 2 lignes ...

Le 07/05/2016 à 17:04, CoolRaoul a dit :

Je ne vois pas comment cela peut marcher: il n'est pas possible de se connecter "root" à DSM (et ça ne date pas de DSM6) en utilisant SFTP (SSH ou SCP ok par contre si on a bien enregistré la clé publique dans ~root/.ssh/authorized_keys)

C'est justement tout l'objet de ce tuto que de rajouter une clef publique ... encore heureux que cela marche du coup ;)

Le 07/05/2016 à 17:04, CoolRaoul a dit :

L'utilisation de cette option "allow the connection agent" présuppose qu'on utilise l'agent (pageant téléchargé avec putty) alors que le tuto n'en parle pas. De plus dans ce cas, il est inutile de spécifier de "private key file" dans Auth parameters.

Je n'utilise pas Pageant ... la manip marche parfaitement même sans avoir installé putty (qui lui l'utilise ... nan on me demande pas pourquoi ^^).

Le 07/05/2016 à 17:04, CoolRaoul a dit :

Inutile de préfixer ce "vi" (ainsi que les suivants) de "sudo" étant donné qu'on est *déjà* root (de part le "sudo -l -U root" précédent)

Exact ... sauf que cela ne marche pas chez moi après test (access denied par exemple avec vi /etc/ssh/sshd_config)

Le 07/05/2016 à 17:04, CoolRaoul a dit :

C'est normal que ca ne fonctionne pas en SFTP : DSM ne supporte pas les connexions root dans ce mode.

DSM suppose les connections root en SFTP ... en tout cas, cela marche parfaitement sur les 2 NAS à ma dispo.

Le 07/05/2016 à 17:04, CoolRaoul a dit :

Si Putty échoue avec un refus de clé c'est que le chemin du fichier de clé privé spécifié dans sa propre configuration de session (Connexion -> SSH -> AUTH -> "authentication parameters") est erroné ou manquant. Mais je te conseille d'utiliser Pageant. Lancé au démarrage de ta session windows, on y charge la clé privée et ensuite plus besoin de retaper sa passphrase jusqu'au prochain login (s'assurer pour cela que dans putty Connexion -> SSH -> AUTH -> "authentication methods", "attempt authentication using pageant" est coché))

Ci-dessous la config ... à noter que mon port SSH n'est évidement pas le 22 (pas fou ^^) mais cela ne change rien au tuto.

A noter aussi que l'on peut décocher "Attempt auth using Pageant", cela marchera quand même (histoire de ne pas penser que Pageant est manquant dans le tuto ;)).

 

Modifié le 5 septembre 2016 par tops

[CoolRaoul]

Il y a 2 heures, tops a dit :

Je précise que c'est optionnel dans le tuto ... par contre, je ne comprends pas bien comment le NAS va accepter la clef que l'on vient lui donner si on ne décommente pas les 2 lignes ..

Précision ajoutée après que j'ai fais la remarque. Et c'est pas optionnel mais inutile vu que ce sont *déja* les options par défaut. Suffit d'essayer (la preuve est que le tuto ne demande pas de redémarrer le démon sshd alors que c'est nécessaire pour que les modifications du fichier de config soient prises en compte)

Il y a 2 heures, tops a dit :

Exact ... sauf que cela ne marche pas chez moi après test (access denied par exemple avec vi /etc/ssh/sshd_config)

C'est parce que tu utilises "sudo -l -U root" (j'avais pas fait gaffe initialement d'ailleurs) qui se contente de *lister* les droits sudo de l'utilisateur root mais ne provoque pas d'élévation de privilege.

La bonne commande est "sudo -i -u root" (u minuscule et "i" et non pas "l") ou, plus simplement, "sudo -i" puisque le compte "root" est le défaut.

Ref: http://linux.die.net/man/8/sudo

-l[l] [command]
If no command is specified, the -l (list) option will list the allowed (and forbidden) commands for the invoking user (or the user specified by the -U option) on the current host.

 

Il y a 2 heures, tops a dit :

DSM suppose les connections root en SFTP ... en tout cas, cela marche parfaitement sur les 2 NAS à ma dispo.

Et bien, je demande à voir. 

En tout cas voici ce que donne pour pour moi: en sftp on peut se connecter en admin (ou tout autre compte) mais pas en root. Pourtant les connexions ssh sont possibles sur le compte root comme on peut le constater par la première commande (connexion par clé publique active par agent ici):

[root@fserv_~]$ ssh root@localhost pwd
/root
[root@fserv_~]$ sftp root@localhost 
Connection closed
[root@fserv_~]$ sftp admin@localhost 
Connected to localhost.
sftp> quit

Par contre en "SCP", ca fonctionne pour root a partir du moment ou ssh fonctionne:

[root@fserv_~]$ touch /tmp/toto
[root@fserv_~]$ scp root@localhost:/tmp/toto /dev/null
toto                                100%    0     0.0KB/s   0.0KB/s   00:00    
 

Il y a 2 heures, tops a dit :

Ci-dessous la config ... à noter que mon port SSH n'est évidement pas le 22 (pas fou ^^) mais cela ne change rien au tuto..

Ma remarque sur le refus de clé (contrairement au reste de mon post) concernait le refus de clé constaté par @hacr, c'est donc *sa* config qui est en cause, pas la tienne (et le port 22, tant qu'on est en réseau local c'est pas très important: j'utilise bien le port 22 et je ne me crois pas fou. Par contre j'ai une redirection sur mon routeur qui utilise un numéro plus exotique et à ca j'ajoute des restrictions d'IP dans le firewall)

Citation

A noter aussi que l'on peut décocher "Attempt auth using Pageant", cela marchera quand même (histoire de ne pas penser que Pageant est manquant dans le tuto ;)).

Je me suis sans doute mal fait comprendre sur ce point: je ne disais pas que le mot '"pageant" était absent du tuto, mais que sa configuration n'était pas abordée alors que l'indication explicite de cocher cette option n'avait de sens que *si* il était actif.

Si il ne l'est pas, bien évidement que l'option soit cochée ou pas ne change rien mais alors inutile de le spécifier dans le tuto.

Il y a 2 heures, tops a dit :

C'est justement tout l'objet de ce tuto que de rajouter une clef publique ... encore heureux que cela marche du coup ;)

Comme déjà mentionné un peu plus haut ma remarque ("pas possible de se connecter root") ne portait que sur *SFTP* (bien lire la phrase en entier), clé publique ou pas ne change rien.

 

Et pour être un peu plus constructif, voici comment utiliser pageant et ne plus avoir à saisir la passphrase de sa clé privée à chaque connexion

• Sous Windows, récupérer le chemin de son fichier de clé privé (celui créé au point #3 du tuto, disons "C:\Users\Dudule\local.ppk")
• Ajouter un raccourci vers pageant (pageant.exe, livré avec Putty) dans le dossier démarrage %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup
• dans les paramètres du raccourci, ajouter le chemin du fichier clé dans le champ "cible"
  

La passphrase de la clé privée ne sera demandé *qu'une seule fois* à l'ouverture de la session Windows. Ensuite, pour peu qu'on ait bien activé l'option  "allow the connection agent" dans putty *et* dans Winscp, les connexions SSH  se feront sans avoir à saisir la passphrase à nouveau. C'est bien confortable.

 

Modifié le 16 mai 2016 par CoolRaoul

[symsyno]

Bonjour,

J'ai utilisé cette méthode prise ici sur ce blog.

Installer si vous ne l'avez pas le package Winscp pour avoir aussi Puttygen. A télécharger ici   

 

1°) Avec Putty, ouvrir une session admin

2°) Passer en ROOT avec sudo -i

3°) Envoyer les commandes dans l'ordre pour créer une clé privée (id_rsa). Il vous sera demandé de définir un mot de passe pour cette clé qui servira à se   connecter avec Winscp.
 

mkdir -p /root/.ssh
chmod 0700 /root/.ssh
ssh-keygen -b 4096 -t rsa -f /root/.ssh/id_rsa
cat /root/.ssh/id_rsa.pub >>/root/.ssh/authorized_keys
cp /root/.ssh/id_rsa /volume1/documents  ### ( choisir une destination de sauvegarde) ###
 

4°) Ouvrir Winscp et créer un nom d'hôte au protocole SFTP avec le nom d'utilisateur "root".

      Aller à  > Paramètres avancés > Authentification.

      Sélectionner le fichier (id_rsa) crée.

      Une fenêtre va s'ouvrir et vous demander avec Puttygen de convertir la clé au bon format.

      Ok et rentrer le mot de passe de la clé.

      Puttygen va s'ouvrir et cliquer sur "Save Private Key".
 

5°) Revenir  à > Paramètres avancés > Authentification

      Sélectionner la clé convertie. 

 

      Vous pouvez maintenant vous connecter en ROOT avec le mot de passe de la clé privée. 

 

 

 

 

 

 

Modifié le 3 juin 2016 par symsyno

[Myghalloween]

Merci symsyno pour tes explications simples et claires ! Ta méthode en 5 étapes fonctionne parfaitement !