[TUTO] Se connecter à SSH avec une paire de clé sur Mac

[CyberFr]

Ce tutoriel nécessite DSM 6.2.4 ou une version ultérieure.

Son but est de permettre à des clients macOS de se connecter à SSH sans avoir à fournir de mot de passe, que ce soit au niveau d'un compte administrateur ou du compte root.

Ce tutoriel a été rédigé à partir de la contribution de référence du regretté unPixel :

 

Et à partir d'une documentation émanant de Synology :

Comment puis-je me connecter à DSM avec des paires de clés RSA via SSH ?

Le tutoriel de unPixel est plutôt orienté PC et fait appel à des outils comme PuTTY, Pageant ou WinSCP totalement inconnus du monde Mac. Dans ce dernier on n'utilise qu'un seul outil, le Terminal.

Il y a bien une partie consacrée aux environnements Mac et Linux ajoutée par @Fenrir mais toutes mes tentatives pour l'appliquer ont été vaines, du moins sous macOS Ventura. unPixel lui-même disait avec humour qu'il n'appliquait pas ce tutoriel sur son Mac et utilisait la bonne vieille méthode du mot de passe. C'est sans doute qu'il y avait quelque part un problème de mise en œuvre. Il est vrai qu'Apple, dont la dernière chimère est de de vouloir créer un système théoriquement inviolable, ne cesse de durcir de façon drastique les mesures de sécurité concernant macOS ce qui explique à mon avis les problèmes rencontrés qui sont des problèmes de droits.

Bref, vous l'aurez compris, ce tutoriel est né d'une frustration. Pourquoi ça marche sur PC et pas sur Mac ? 😀

J'ai refondu la documentation de Synology et j'ai dû faire appel à leur support technique après avoir constaté qu'on ne pouvait pas l'appliquer en l'état. Le support a accepté d'ouvrir un ticket et a proposé des modifications qui se sont avérées déterminantes. Merci à eux.

Facilité du tutoriel : FACILE si l'on maîtrise un peu l'interface en ligne de commande

Durée : 20 minutes environ

 

INTRODUCTION

L’authentification par clés SSH (Secure Shell) fonctionne en utilisant une clé publique sur le NAS et une clé privée sur l'ordinateur local. La clé publique peut être placée sur n’importe quel serveur distant auquel on souhaite accéder. C'est d'ailleurs ce que nous ferons par la suite. La clé privée reste sur le Mac et n'est jamais communiquée à quiconque : lors du lancement de la session SSH le NAS envoie une requête à l'ordinateur local et c'est lui qui, en confrontant la clé publique transmise par le NAS et la clé privée qu'il détient, accepte ou pas l'ouverture de session. Le NAS ne voit qu'une chose, la réponse de l'ordinateur local et c'est oui ou non. Dans ce dernier cas l'ouverture de session est bien entendu refusée. Comme l'a dit @.Shad. que je me permets de citer  « 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é. ».  SSH utilise des algorithmes de cryptage puissants pour sécuriser la communication entre le client et le serveur. Il garantit que les données transmises sur le réseau ne peuvent pas être interceptées ou modifiées par des entités malveillantes.

Remarque : la mise en œuvre du tutoriel implique de faire des allers-retours constants entre le Mac (via l'application Terminal) et DSM. Suivez bien les instructions qui sont données car elles vous indiquent où vous vous trouvez et ne vous perdez pas ! N'hésitez pas à m'indiquer les difficultés que vous aurez pu rencontrer afin que j'améliore le tutoriel.

De toute façon, si vous rencontrez des problèmes qui vous obligent à tout recommencer, la marche à suivre est décrite en fin de document. N'hésitez pas à m'en faire part là encore.

Il est vivement recommandé pour des raisons de sécurité de changer le port par défaut de SSH dans le panneau "Terminal & SNMP" du Panneau de configuration.
À chaque fois que vous verrez une commande "ssh ... -p XX" par la suite, remplacez XX par le port que vous avez spécifié.

ATTENTION : N'ouvrez pas ce port sur votre box Internet car il doit être utilisé en local pour des raisons de sécurité une fois de plus. Si vous devez absolument vous connecter à SSH sur le NAS hors du réseau local utilisez un VPN.

 

 

LANCEZ L'APPLICATION TERMINAL SUR LE MAC

Inutile de la télécharger, elle est présente sur tous les Mac.

Dans tout ce qui suit vous devrez remplacer "username" par par votre nom d'utilisateur sur le NAS et sur le Mac. Ils peuvent être différents (c'est le cas chez moi). Il faut faire attention au contexte dans ce cas afin d'appliquer la bonne substitution : Terminal Mac --> usernameX, SSH --> usernameY.

GÉNÉRATION DES CLÉS

On génère une paire de clés SSH à partir du Terminal du Mac avec la commande ssh-keygen en spécifiant l’algorithme de chiffrement désiré. J'ai retenu ed25519 qui est le plus sûr à ce jour :

ssh-keygen -t ed25519

Vous êtes invité à saisir le chemin d'accès au dossier qui contiendra la clé publique et la clé privée. Laissez l’emplacement par défaut, à savoir :

/Users/username/.ssh/id_ed25519

en appuyant sur Entrée.

Vous êtes invité à saisir une phrase de passe (passphrase) pour la clé privée CE QUI EST VIVEMENT RECOMMANDÉ VOIRE INDISPENSABLE. Vous pouvez cependant  l'ignorer en appuyant deux fois sur la touche Entrée si vous ne souhaitez pas saisir de passphrase à chaque fois que vous utilisez la clé. @Fenrir recommande, je cite « de protéger la clef avec un super mot de passe » et « de renouveler la clef de temps en temps (1 fois par an c'est largement suffisant) en pensant bien à supprimer la clef publique de l'ancienne ».

La clé publique (id_ed25519.pub) et la clé privée (id_ed25519) ont été crées sur le Mac dans le dossier choisi plus haut.

Il est possible de stocker la passphrase dans le Trousseau d'accès du Mac  en utilisant ssh-agent mais je me méfie de cette solution que je n'ai d'ailleurs pas retenue pour deux raisons au moins :

• La passphrase dans le Trousseau n'est pas identique à la passphrase fournie à l'origine ce qui peut poser problème. De plus la passphrase peut être tronquée par rapport à l'original ce qui n'est pas normal et pose des problèmes de sécurité. C'est bien beau de définir une passphrase de 25 caractères s'il elle est finalement  tronquée à 10 caractères dans le Trousseau...

• Je reproche au Trousseau d'accès d'être dépendant de la session utilisateur puisqu'il est débloqué automatiquement à l'ouverture de la session. Suite à un vol où le cambrioleur a physiquement accès à la machine, il est difficile d'être certain que le mot de passe de session ne sera pas décrypté.

Dans tous les cas de figure il est nécessaire pour se connecter à SSH de connaître la passphrase, il ne faut pas faciliter la tâche des intrus en la stockant quelque part sauf dans des coffres sécurisé comme Vaultwarden ou 1Password qui ont leur propre mot de passe et ne sont pas débloqués automatiquement à l'ouverture de session.

Vous devrez par la suite copier la clé publique (id_ed25519.pub) dans le dossier home de votre compte administrateur sur le NAS  en utilisant File Station. Cette clé se trouve actuellement dans un dossier masqué sur le Mac (.ssh est masqué car précédé d'un point). C'est pourquoi ce dossier n'apparaîtra pas dans la fenêtre de File Station. Pour contourner le problème, le plus simple est d'utiliser le terminal. Il faut se positionner dans le dossier .ssh sur le Mac :

cd ~/.ssh

puis copier la clé à la racine de son home sur le Mac :

cp id_ed25519.pub ~/id_ed25519.pub

ENREGISTREMENT DE LA CLÉ PUBLIQUE DANS VOTRE COMPTE ADMINISTRATEUR SUR LE NAS

Connectez-vous à DSM avec votre compte administrateur. Accédez à File Station. Dans votre dossier home créez un sous-dossier nommé .ssh (n'oubliez pas le point au début de .ssh).

 

Transférez la clé publique id_ed25519.pub (qui est désormais visible) dans le dossier .ssh en utilisant l'onglet "Charger" de File Station comme illustré ci-dessous (lionel est mon dossier home).

 

 

 

 

Il faut ensuite accéder au dossier home sur le Mac avec le Terminal et supprimer la clé qui s'y trouve afin de faire le ménage (on l'avait déplacé là afin qu'elle soit visible).

cd ~/

rm id_ed25519.pub

CONNEXION SSH ADMINISTRATEUR AVEC LA PAIRE DE CLÉS

Connectez-vous à SSH avec votre compte administrateur sur le NAS.
Un message d'avertissement apparaît :

The authenticity of host '[192.168.1.2]:22 ([192.168.1.2]:22)' can't be established. ED25519 key fingerprint is SHA256:4nLwr4EVpCwt/jjH9kIEXDUaILvWhVXCzbDCzJv4z66. This key is not known by any other names Are you sure you want to continue connecting (yes/no/[fingerprint])?

Ce message apparaît lors de la première connexion SSH ce qui est normal. Répondez simplement 'yes'.

Warning: Permanently added '[192.168.1.2]:22' (ED25519) to the list of known hosts.

Après, vous pouvez être déconnecté auquel cas vous aurez le message :
Connection closed by 192.168.1.2 port 22

Il vous faut vous reconnecter dans ce cas.

Si vous avez le message :

username@192.168.1.2's password:

On vous demande simplement votre mot de passe à la suite de quoi vous serez déconnecté de toute façon ! Pour des raisons qui m'échappent, les deux cas se sont produits lors des tests que j'ai réalisés. Pour faire simple dans tous les cas de figure reconnectez-vous !

Accédez au dossier .ssh précédemment créé sur le NAS :

cd ~/.ssh

Ajoutez la clé publique à un fichier, authorized_keys qui sera créé à cette occasion :

cat id_ed25519.pub >> authorized_keys

Le dossier .ssh sur le NAS contient désormais deux fichiers : authorized_keys et la clé publique id_ed25519.pub.

Se positionner dans son home sur le NAS

cd ~/

Puis taper les instructions suivantes où 711 donne les droits en lecture et en écriture au seul propriétaire (vous) et le droit d'exécution à tout le monde :
chmod 711 .ssh

chmod 711 .ssh/authorized_keys

chown -R username .ssh/

Où username est votre nom d'administrateur sur le NAS.

Ceci afin d'être sûr que les droits sur ces dossiers sont conformes aux règles. Ces instructions sont très importantes.

La première partie du tutoriel est terminée. Vous pouvez maintenant vous connecter à SSH à l'aide de votre compte administrateur sans avoir à saisir un mot de passe. Mais la passphrase sera demandée si vous l'avez renseignée lors de la génération des clés (ce qui, je le rappelle, est vivement recommandé).

Par exemple :

ssh username@192.168.1.1 -p XX
Enter passphrase for key '/Users/username/.ssh/id_ed25519':_

 

CONNEXION SSH ROOT AVEC LA PAIRE DE CLÉS

Sur le NAS, se connecter à SSH en tant que root à partir de votre compte administrateur en tapant "sudo -i".

Soyez conscients qu'en tant que root vous avez tous les droits sur le NAS et qu'une erreur sur une commande peut provoquer des dommages irrémédiables. En cas de doute, il est préférable de copier les commandes du tutoriel et de les coller dans la session SSH.

Exécutez la commande

mkdir /root/.ssh

afin de créer le dossier .ssh s'il n'existe pas. Il peut avoir été créé auparavant si des clés d'administrateurs autres que vous ont été consignées. Vous aurez dans ce cas le message d'erreur :

mkdir: cannot create directory ‘/root/.ssh’: File exists

qui est sans gravité.

Accédez à votre propre dossier .ssh sur le NAS qui se trouve dans votre dossier home :

cd /volume1/homes/username/.ssh

où volume1 est le volume dans lequel se trouve le fichier id_ed25519.pub et username votre nom d'utilisateur sur le NAS.

On crée le fichier authorized_keys de root s'il n'existe pas et on ajoute la clé publique id_ed25519.pub.

cat id_ed25519.pub >> /root/.ssh/authorized_keys

Entrez la commande

chmod 700 -R /root/.ssh

afin d'être certain que tout ce qui se trouve dans le dossier .ssh n'est accessible qu'au compte root et ceci est très important (700 donne l'exclusivité de tous les droits à root).

 

ON REDÉMARRE LE SERVICE SSH POUR QUE LES CHANGEMENTS SOIENT PRIS EN COMPTE

DSM6 : synoservicectl --reload sshd
DSM7 : systemctl restart sshd

Vous pouvez maintenant vous connecter en tant que root sans avoir à saisir de mot de passe mais la passphrase sera demandée si vous l'avez renseignée lors de la génération des clés comme indiqué plus haut.

Par exemple :

ssh root@192.168.1.1 -p XX

Le tutoriel est terminé.

 

MODIFIER LA PASSPHRASE

Lancer le Terminal sur le Mac et taper :

ssh-keygen -p -f ~/.ssh/id_ed25519

On demande l'ancienne phrase de passe puis la nouvelle.

Il faut parfois relancer le service SSH pour que le changement soit pris en compte.

Le plus simple est d'essayer de se connecter en tant que root avec la nouvelle passphrase et, si elle est refusée, de saisir l'ancienne. Les changements n'ont pas été pris en compte dans ce cas et il faut utiliser la commande de redémarrage du service SSH indiquée ci-dessus (celle-ci nécessite les droits root).

 

EN CAS D'ERREUR LORS DE LA MISE EN ŒUVRE DU TUTORIEL QUI VOUS OBLIGE A TOUT RECOMMENCER

NB : Ces instructions ne s'appliquent que si vous êtes le seul administrateur du NAS ou si vous avez créé une session SSH avec paire de clés pour la première fois. Si un historique préexiste n'hésitez pas à me contacter.

Connectez-vous à SSH en tant que root sur le NAS et supprimez son dossier .ssh :

rm -R .ssh

Connectez-vous à SSH avec votre compte administrateur sur le NAS et supprimez le dossier .ssh qui se trouve dans votre dossier home :

rm -R .ssh

Lancez l'application Terminal et supprimez le dossier .ssh qui se trouve dans votre dossier home sur le MAC :

rm -R .ssh

VOUS AUREZ COMPRIS QUE CES ACTIONS SONT IRRÉVERSIBLES !

CRÉATION D'UN FICHIER DE CONFIGURATION SUR LE MAC

Un fichier de configuration permet de définir des profils par défaut (hosts) en renseignant l'adresse IP du serveur, le nom d'utilisateur sur le serveur, le port utilisé par SSH et le chemin d'accès à la clé privée.

Ainsi au lieu de taper
ssh username@192.168.1.1 -p XX
pour initier une session SSH, il suffit de taper
ssh username

Il est possible de créer dans le fichier de config plusieurs hosts avec des adresses IP différentes ce qui permet de se connecter à des serveurs distincts.

Ne créez un fichier de config qu'après de la mise en œuvre complète du tutoriel  lorsque vous serez sûr que tout fonctionne.

#    point d'entrée : tapez ssh server_1 pour vous connecter
Host server_1
     HostName 192.168.1.1
#    nom d'utilisateur sur le serveur
     User username
     Port XXX
#    Chemin d'accès à la clé privée
     IdentityFile ~/.ssh/id_ed25519

Host nas
     HostName ndd.fr
     User cyberfr
     Port XXX
     IdentityFile ~/.ssh/id_ed25519

Host root
     HostName 192.168.1.2
     User root
     Port XXX
     IdentityFile ~/.ssh/id_ed25519

Le fichier de configuration doit être placé sous le nom "config" (sans extension) dans le dossier .ssh de votre home où résident déjà les clés publiques et privées id_ed25519 et id_ed25519.pub. Le plus simple est de le rédiger dans un traitement de texte (TextEdit ou BBEdit) puis de le déplacer au bon endroit. Il vaut mieux respecter le canevas des exemples donnés ci-dessus et ne pas utiliser de tabulations (je n'ai pas essayé donc je ne sais pas si elles sont acceptées 😀).

Modifié le 16 avril par CyberFr

[MilesTEG1]

Le 13/04/2024 à 5:50 PM, CyberFr a dit :

l est possible de stocker la passphrase dans le Trousseau d'accès du Mac  en utilisant ssh-agent mais je me méfie de cette solution que je n'ai d'ailleurs pas retenue pour deux raisons au moins :

• La passphrase dans le Trousseau n'est pas identique à la passphrase fournie à l'origine ce qui peut poser problème. De plus la passphrase peut être tronquée par rapport à l'original ce qui n'est pas normal et pose des problèmes de sécurité. C'est bien beau de définir une passphrase de 25 caractères s'il elle est finalement  tronquée à 10 caractères dans le Trousseau...

• Je reproche au Trousseau d'accès d'être dépendant de la session utilisateur puisqu'il est débloqué automatiquement à l'ouverture de la session. Suite à un vol où le cambrioleur a physiquement accès à la machine, il est difficile d'être certain que le mot de passe de session ne sera pas décrypté.

Bonsoir @CyberFr,

Merci pour ce repartage de tuto.

Pour ce que j'ai cité, as-tu testé sur une version récente de macOS comme Sonoma ?

Et comment stockes-tu la clé privée ?

[MilesTEG1]

@CyberFr
J'ai suivi un autre tuto avant d'avoir le tiens, et dans celui que j'ai utilisé, il y a la création d'un fichier config sur le client et l'ajout de la clé sur le serveur avec aussi la création/modification du fichier de configuration sur le serveur.
Mais en faisant cela, je perds l'accès en SFTP au serveur, or moi je veux le conserver.
Est-ce que ta méthode le permet ?

[CyberFr]

Il y a 11 heures, MilesTEG1 a dit :

Pour ce que j'ai cité, as-tu testé sur une version récente de macOS comme Sonoma ?

J'ai testé le tuto sur la version de macOS qui précède Sonoma, à savoir Ventura.

Il y a 11 heures, MilesTEG1 a dit :

Et comment stockes-tu la clé privée ?

Comme indiqué dans le tuto dans la rubrique "GÉNÉRATION DES CLÉS".  Tu peux ne pas choisir l'emplacement qui est proposé par défaut mais pourquoi se compliquer la vie puisque la clé est cryptée ? La clé privée reste sur ton ordinateur quoiqu'il arrive et n'est jamais communiquée au serveur. Lors du lancement de la session SSH c'est le NAS qui envoie une requête à l'ordinateur local et c'est ce dernier qui, en confrontant la clé publique et la clé privée, accepte ou pas l'ouverture de session. Le NAS ne voit qu'une chose, la réponse de l'ordinateur local et c'est oui ou non.

Il y a 9 heures, MilesTEG1 a dit :

J'ai suivi un autre tuto avant d'avoir le tiens, et dans celui que j'ai utilisé, il y a la création d'un fichier config sur le client et l'ajout de la clé sur le serveur avec aussi la création/modification du fichier de configuration sur le serveur.

Comment veux-tu que je te réponde puisque je n'en suis pas l'auteur ? Le plus simple sans doute est de tout reprendre à zéro avec le tuto que j'ai écrit. Un utilisateur lambda devrait faire ça en 20 minutes mais un as de la CLI comme toi devrait expédier cela en 10 minutes 😀

Il y a 10 heures, MilesTEG1 a dit :

Mais en faisant cela, je perds l'accès en SFTP au serveur, or moi je veux le conserver.

Est-ce que ta méthode le permet ?

Moi j'ai conservé les deux, le SSH avec la paire de clés ,et le SFTP.  Ils cohabitent à merveille.

À mon humble avis c'est une raison de plus pour repartir de zéro. Mais attention ,ne crée pas de fichier de config avant d'avoir terminé le tuto où tu risques de tout casser. J'ai créé un tel fichier de config sur mon Mac après m'être assuré que tout fonctionnait. Et donc au moindre problème il me suffisait de supprimer le fichier de config pour repartir du bon pied.

[MilesTEG1]

Il y a 2 heures, CyberFr a dit :

J'ai testé le tuto sur la version de macOS qui précède Sonoma, à savoir Ventura.

Salut 🙂

Tu penses que ça sera pareil avec Sonoma ?

 

Il y a 2 heures, CyberFr a dit :

Comme indiqué dans le tuto dans la rubrique "GÉNÉRATION DES CLÉS".  Tu peux ne pas choisir l'emplacement qui est proposé par défaut mais pourquoi se compliquer la vie puisque la clé est cryptée ? La clé privée reste sur ton ordinateur quoiqu'il arrive et n'est jamais communiquée au serveur. Lors du lancement de la session SSH c'est le NAS qui envoie une requête à l'ordinateur local et c'est ce dernier qui, en confrontant la clé publique et la clé privée, accepte ou pas l'ouverture de session. Le NAS ne voit qu'une chose, la réponse de l'ordinateur local et c'est oui ou non.

Il y a 12 heures, MilesTEG1 a dit :

Ok, je laisserais donc la clé privée sur le mac.
Et préconises-tu d'avoir une clé par serveur ?

Il y a 2 heures, CyberFr a dit :

Comment veux-tu que je te réponde puisque je n'en suis pas l'auteur ? Le plus simple sans doute est de tout reprendre à zéro avec le tuto que j'ai écrit. Un utilisateur lambda devrait faire ça en 20 minutes mais un as de la CLI comme toi devrait expédier cela en 10 minutes 😀

Je me doute bien, et la question ne portait pas sur le tuto dont je parlais, mais plutôt sur ce que j'ai évoqué ensuite 🙂 

Il y a 2 heures, CyberFr a dit :

Moi j'ai conservé les deux, le SSH avec la paire de clés ,et le SFTP.  Ils cohabitent à merveille.

Ok. Et tu n'as rien fait de spécial pour conserver le SFTP sur le serveur ?

PS : mes essais sont fait sur une instance proxmox, base Debian 😉 Il va peut-être y avoir des subtilités 🤣

Il y a 2 heures, CyberFr a dit :

À mon humble avis c'est une raison de plus pour repartir de zéro. Mais attention ,ne crée pas de fichier de config avant d'avoir terminé le tuto où tu risques de tout casser. J'ai créé un tel fichier de config sur mon Mac après m'être assuré que tout fonctionnait. Et donc au moindre problème il me suffisait de supprimer le fichier de config pour repartir du bon pied.

Ok, j'ai déjà tout viré, sauf les clés privées/publiques que j'avais généré pour chaque serveur.
Car j'avais besoin d'accéder en SFTP au proxmox.

Tu as quoi comme fichier de configuration ? Je ne vois pas où est décrit dans ton tuto comment on le paramètre...

En relisant ton tutoriel, je me rends compte que tu conserves l'accès par mot de passe puisque tu ne vas pas toucher au fichier /etc/ssh/sshd_config

C'est voulu ?

[CyberFr]

il y a 2 minutes, MilesTEG1 a dit :

Tu penses que ça sera pareil avec Sonoma ?

Sans doute et je compte sur toi pour le confirmer 😀

il y a 3 minutes, MilesTEG1 a dit :

Et préconises-tu d'avoir une clé par serveur ?

Pas vraiment, ça compliquerait les choses au niveau de la gestion des clés.

il y a 5 minutes, MilesTEG1 a dit :

Ok. Et tu n'as rien fait de spécial pour conserver le SFTP sur le serveur ?

Je n'ai rien fait du tout.

 

il y a 6 minutes, MilesTEG1 a dit :

PS : mes essais sont fait sur une instance proxmox, base Debian 😉 Il va peut-être y avoir des subtilités 🤣

Je décline toute responsabilité dans ce cas ! Mais je connais ta témérité 😀

il y a 9 minutes, MilesTEG1 a dit :

Ok, j'ai déjà tout viré, sauf les clés privées/publiques que j'avais généré pour chaque serveur.
Car j'avais besoin d'accéder en SFTP au proxmox.

Il faut vraiment mieux repartir de zéro mais c'est toi qui voit. Je ne comprends pas le rapport avec le SFTP. De plus c'est quoi le proxmox dont tu parles ?

Chez moi SSL et SFTP sont deux services distincts qui utilisent des ports différents. De mémoire je n'ai activé aucun service sur le NAS pour le SSL, par contre j'ai activé le serveur SFTP.

il y a 19 minutes, MilesTEG1 a dit :

Tu as quoi comme fichier de configuration ? Je ne vois pas où est décrit dans ton tuto comment on le paramètre...

Tu n'en a pas besoin pour l'instant, comme je te l'ai indiqué il faut le créer à la fin lorsque le SSL avec clés fonctionne. Il simplifie la vie, pas plus et l'on peut s'en passer dans un premier temps.

il y a 22 minutes, MilesTEG1 a dit :

En relisant ton tutoriel, je me rends compte que tu conserves l'accès par mot de passe puisque tu ne vas pas toucher au fichier /etc/ssh/sshd_config

On sort un peu du champ du tuto là. J'ai modifié le fichier sshd_config sur mon NAS mais une fois de plus je l'ai fait en dernier. Parce que si tu le modifies avant d'avoir testé que tout se passe bien, tu prends de gros risques. En effet tu modifies le fichier sshd_config et tu interdis donc la connexion SSH par mot de passe. Et si tu constates par la suite que la connexion par clés ne fonctionne pas, tu seras forcé de constater par la même occasion que tu es définitivement banni de SSH ! Il ne te restera plus qu'à réinstaller DSM.

Et même en dehors de ce cas extrême il vaut mieux anticiper tout renouvellement de clés @Fenrir recommande de le faire au moins une fois par an. J'ai un fichier sshd_config_backup que je devrai réinstaller avant tout changement de clés. Si je n'oublies pas bêtement de le faire 😀

[MilesTEG1]

il y a 15 minutes, CyberFr a dit :

Sans doute et je compte sur toi pour le confirmer 😀

Lol
UN jour peut-être quand j'aurais validé tout le tralala pour faire en sorte que la connexion par clé fonctionne nickel.

il y a 17 minutes, CyberFr a dit :

il y a une heure, MilesTEG1 a dit :

Et préconises-tu d'avoir une clé par serveur ?

Pas vraiment, ça compliquerait les choses au niveau de la gestion des clés.

Ok, mais pour corser le tout, je reste sur une clé par serveur ^^
Je trouve ça un chouilla plus sécurisé d'avoir une seule clé pour un seul serveur.
À voir si à l'avenir ça ne va pas être plus chiant qu'autre chose, mais tu verras plus bas, j'ai fini par y arriver 😄

 

il y a 16 minutes, CyberFr a dit :

Je n'ai rien fait du tout.

Ok, moi non plus, même juste après l'installation de proxmox.

Mais chez moi (enfin sur les proxmox/debian), le port de mon SSH et du SFTP sont identiques.

il y a 16 minutes, CyberFr a dit :

Je décline toute responsabilité dans ce cas ! Mais je connais ta témérité 😀

🤣

En fait j'aime bien apprendre par l'exemple, et quoi de mieux que de tester dans un environement "inconnu" ^^

Non la vraie raison pour laquelle je teste sur le NUC avant de tester sur le Syno, c'est justement pour ne pas me retrouver bloquer et ne plus pouvoir accéder à la ligne de commande SSH. (voir la suite de ce § plus bas, avec la dernière citation).

... à. suivre ...

 

il y a 17 minutes, CyberFr a dit :

Il faut vraiment mieux repartir de zéro mais c'est toi qui voit. Je ne comprends pas le rapport avec le SFTP. De plus c'est quoi le proxmox dont tu parles ?

Chez moi SSL et SFTP sont deux services distincts qui utilisent des ports différents. De mémoire je n'ai activé aucun service sur le NAS pour le SSL, par contre j'ai activé le serveur SFTP.

Repartir de 0 complètement ne me ferait que refaire les couples clés privées / clés publiques que j'ai déjà créés avec les passphrases qui vont avec.
Ce ne sont pas ces clés qui posaient problèmes, mais les paramètres dans les fichiers de configuration.

 

il y a 17 minutes, CyberFr a dit :

Tu n'en a pas besoin pour l'instant, comme je te l'ai indiqué il faut le créer à la fin lorsque le SSL avec clés fonctionne. Il simplifie la vie, pas plus et l'on peut s'en passer dans un premier temps.

Avec mes clés dédiées à chaque machine, il me fallait passer par le fichier de configuration config sur mon mac, sinon la connexion demandait toujours un mot de passe....

 

il y a 17 minutes, CyberFr a dit :

On sort un peu du champ du tuto là. J'ai modifié le fichier sshd_config sur mon NAS mais une fois de plus je l'ai fait en dernier. Parce que si tu le modifies avant d'avoir testé que tout se passe bien, tu prends de gros risques. En effet tu modifies le fichier sshd_config et tu interdis donc la connexion SSH par mot de passe. Et si tu constates par la suite que la connexion par clés ne fonctionne pas, tu seras forcé de constater par la même occasion que tu es définitivement banni de SSH ! Il ne te restera plus qu'à réinstaller DSM.

Et même en dehors de ce cas extrême il vaut mieux anticiper tout renouvellement de clés @Fenrir recommande de le faire au moins une fois par an. J'ai un fichier sshd_config_backup que je devrai réinstaller avant tout changement de clés. Si je n'oublies pas bêtement de le faire 😀

Comme je disais un peu plus haut, me retrouver KO à la connexion SSH du Syno, ce n'est pas tolérable d'où mon essai sur le proxmox.
Pour info, Proxmox est basé sur Debian, et c'est un hyperviseur qui fait tourner des machines virtuelles, des conteneurs LXC.
Pourquoi essayé sur le NUC Proxmox, et bien parce que si je me retrouve banni du SSH, je peux toujours corriger le tir en me connectant physiquement au NUC avec clavier, souris, et écran et j'aurais accès à l'invite terminal du NUC directement. Je peux aussi le faire via la WebUI de Proxmox.
Donc c'est mon failsafe ^^
Une fois validée ma technique dessus, (enfin la fusion de plusieurs méthodes, donc la tienne), je pourrais transposer pour le Syno ^^ et potentiellement pour l'Asustor et mon RT.

Sinon pour le Syno, il y a un failsafe aussi, mais faut le savoir 😁 Tu peux toujours lancer des commandes CLI via le planificateur de tâche, en mode root, ce qui te permettrait de restaurer ton fichier de configuration sshd_config à son état d'origine, que tu auras bien entendu sauvegardé avant ^^
Tu te fais alors un script qui : copie la sauvegarde à son emplacement d'origine, puis relance le service SSH.

Et voilà ^^ C'est contraignant mais fonctionnel ^^

 

Sinon, j'ai donc réussi à faire en sorte de me connecter via la clé 😄 à la fois dans iTerm2, mais aussi dans Forklift 4 😄
Précision, j'ai fait en sorte de réussir la connexion avec l'adresse IP ou aussi via le ndd de type nuc1.miles.lan, dont l'adresse est résolue par mon serveur DNS AdGuardHome.

Pour cela j'ai donc une clé privée qui porte le nom : nuc1.miles.lan 
Et la publique le même avec .pub à la fin.

Mon fichier config sur le client contient :

# Bloc pour l'accès via IP, car profil créé depuis longtemps dans iTerm2 avec IP
Host 192.168.2.194
    HostName 192.168.2.194
    User root
    IdentityFile /Users/miles/.ssh/nuc1.miles.lan
    IdentitiesOnly yes
    StrictHostKeyChecking yes

# Bloc pour l'accès via alias court, transformé en ndd uniquement dispo sur le LAN
Host nuc1
    HostName nuc1.miles.lan
    User root
    IdentityFile /Users/miles/.ssh/nuc1.miles.lan
    IdentitiesOnly yes
    StrictHostKeyChecking yes

# Bloc commun à tout, pour éviter les répétitions
# Viendra dedans la partie avev IdentitiesOnly et StrictHostKeyChecking quand tout sera au point
Host *
    Port 1234

Et sur le serveur, j'ai ceci :

# Fichier /etc/ssh/sshd_config.d/ssh_keys.conf
# pour ProxmoxVE/Debian

Port 1234
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 2m
PermitRootLogin yes
AllowGroups ssh root
AllowUsers root@192.168.2.28 root@192.168.2.30 root@192.168.2.80 root@192.168.2.142 root@192.168.2.0/24 root@192.168.10.0/24 root@192.168.12.0/24
PermitEmptyPasswords no
StrictModes yes
MaxAuthTries 6
MaxSessions 10

Match user root
    PubkeyAuthentication yes
    PasswordAuthentication no
    ChallengeResponseAuthentication no
Match all

X11Forwarding no

Et bien sûr, la clé publique placée dans le fichier known_hosts sur le serveur.
D'ailleurs à ce propos, sais-tu que tu peux utiliser la commande suivante pour faire cette manipulation, qui enlève plein d'étapes ?

ssh-copy-id -p 1234 -i ~/.ssh/nuc1.miles.lan.pub root@nuc1.miles.lan

Voilà, je reviendrais vers toi quand j'aurais finalisé mon chmilblik 🙂 

BOnne journée , et merci pour toutes ces infos qui me permettent de finaliser mes connexions.

[CyberFr]

il y a une heure, MilesTEG1 a dit :

Je trouve ça un chouilla plus sécurisé d'avoir une seule clé pour un seul serveur.

Mais quel est l'intérêt de SSH dans ce cas ? Le seul intérêt de ce choix serait de se prémunir d'un vol où la personne malveillante aurait physiquement accès à ton Mac. Si c'est le cas cette personne aura de toute façon accès à toutes les clés qu’héberge ton Mac. Cela ne présente donc aucun intérêt a priori.

il y a une heure, MilesTEG1 a dit :

Sinon pour le Syno, il y a un failsafe aussi, mais faut le savoir 😁 Tu peux toujours lancer des commandes CLI via le planificateur de tâche, en mode root, ce qui te permettrait de restaurer ton fichier de configuration sshd_config à son état d'origine, que tu auras bien entendu sauvegardé avant ^^
Tu te fais alors un script qui : copie la sauvegarde à son emplacement d'origine, puis relance le service SSH.

Je n'y avais pas pensé. Tu mérites bien ta réputation de barbu 😀 Je commence déjà à écrire le script parce qu'il faut que je m'y prenne un peu à l'avance quand même !

il y a une heure, MilesTEG1 a dit :

D'ailleurs à ce propos, sais-tu que tu peux utiliser la commande suivante pour faire cette manipulation, qui enlève plein d'étapes ?

ssh-copy-id -p 1234 -i ~/.ssh/nuc1.miles.lan.pub root@nuc1.miles.lan

Je l'ai lu mais la commande « cat » fait le même boulot.

On est pas sur la même longueur d'ondes, je m'explique.
J'ai écrit ce tuto à destination d'un public disposant d'un Mac et d'un NAS et qui souhaitait pouvoir établir une connexion SSH avec une paire de clés. Étant entendu que le NAS était de marque Synology.
Toi, tu gères plusieurs serveurs de marques différentes dont l'un, si j'ai bien compris, tourne sur une machine virtuelle. De plus tu utilises une clé privée par serveur ce qui n'est pas habituel, y compris chez des utilisateurs avancés.
Tu comprendras facilement que le contexte qui est le tien est sans rapport avec l'objet de ce tuto.
Je te propose de commencer avec un Mac et un NAS et de suivre le tuto pas à pas en respectant sa chronologie, ses étapes et sa logique sinon celui-ci ne te servira à rien.

[MilesTEG1]

il y a 20 minutes, CyberFr a dit :

Mais quel est l'intérêt de SSH dans ce cas ? Le seul intérêt de ce choix serait de se prémunir d'un vol où la personne malveillante aurait physiquement accès à ton Mac. Si c'est le cas cette personne aura de toute façon accès à toutes les clés qu’héberge ton Mac. Cela ne présente donc aucun intérêt a priori.

C'est pas faux. Pour mon usage, je pense que je vais revenir sur ce point, et n'utiliser qu'une seule paire de clé ^^ Celle que j'ai déjà générée 🙂

il y a 21 minutes, CyberFr a dit :

Je n'y avais pas pensé. Tu mérites bien ta réputation de barbu 😀 Je commence déjà à écrire le script parce qu'il faut que je m'y prenne un peu à l'avance quand même !

🧔🏻 

 

il y a 21 minutes, CyberFr a dit :

Je l'ai lu mais la commande « cat » fait le même boulot.

Oui et non.
Toi tu dois d'abord copier la clé publique sur le NAS, en passant par la copie dans le home du mac d'utilisateur de ce mac. 
Ça fait quatres actions, sans compter les suppressions des fichiers.

La commande que j'ai donné ici fait tout ça en une seule action. Tu la lances depuis le mac. Essaye, tu verras 😉

il y a 23 minutes, CyberFr a dit :

On est pas sur la même longueur d'ondes, je m'explique.
J'ai écrit ce tuto à destination d'un public disposant d'un Mac et d'un NAS et qui souhaitait pouvoir établir une connexion SSH avec une paire de clés. Étant entendu que le NAS était de marque Synology.
Toi, tu gères plusieurs serveurs de marques différentes dont l'un, si j'ai bien compris, tourne sur une machine virtuelle. De plus tu utilises une clé privée par serveur ce qui n'est pas habituel, y compris chez des utilisateurs avancés.
Tu comprendras facilement que le contexte qui est le tien est sans rapport avec l'objet de ce tuto.
Je te propose de commencer avec un Mac et un NAS et de suivre le tuto pas à pas en respectant sa chronologie, ses étapes et sa logique sinon celui-ci ne te servira à rien.

Oui et non.
En effet, j'essayais de faire fonctionne une méthode qui n'est pas la tienne, avec diverses solutions, mais ton tuto m'a aidé, et je ne faisais que relater en quoi, et comment je n'en était sorti.

La connexion SSH par clé sur le Syno va venir, après mes essais, c'est mon objectif ^^
Comme je l'ai dit précédemment, je vais revenir sur l'idée d'avoir une clé par serveur, pour n'en avoir qu'une seule. Ce sera plus pratique à gérer comme tu dis.
Et juste pour clarifier, mon proxmox est une entité physique, pas une machine virtuelle ^^ (mais je vais aussi mettre en place la connexion par clé SSH avec quelques machines virtuelles linux).

Bref, tu as raison sur le fait que je devrais suivre ton tuto à la lettre pour poster ici, donc je vais m'abstenir pour la suite.
En tout cas, merci quand même car il m'a aidé.

PS : Et n'efface pas ton tuto un nouvelle fois 🙂  Il sert et servira à d'autres.

PPS : Agrémente ce dernier d'explications sur les fichiers de configuration une fois que la connexion est établie avec la clé, car selon moi c'est un gros manque de ton tuto.

👋🏻

 

[CyberFr]

il y a 8 minutes, MilesTEG1 a dit :

La commande que j'ai donné ici fait tout ça en une seule action. Tu la lances depuis le mac. Essaye, tu verras 😉

Je vais essayer, promis.

il y a 9 minutes, MilesTEG1 a dit :

La connexion SSH par clé sur le Syno va venir, après mes essais, c'est mon objectif ^^

Il sera temps à ce moment là de revenir sur le tuto si tu le souhaites 😀

il y a 10 minutes, MilesTEG1 a dit :

PS : Et n'efface pas ton tuto un nouvelle fois 🙂  Il sert et servira à d'autres.

Errare humanum est, perseverare diabolicum.

il y a 19 minutes, MilesTEG1 a dit :

PPS : Agrémente ce dernier d'explications sur les fichiers de configuration une fois que la connexion est établie avec la clé, car selon moi c'est un gros manque de ton tuto.

Je le ferai en temps voulu. J'ai souhaité parler de l'essentiel car le tuto est déjà assez dense. En ce qui concerne le fichier de config, j'ai bien conscience que je ne t'apprendrai rien alors à quoi bon l'ajouter pour l'instant ?

[MilesTEG1]

il y a 24 minutes, CyberFr a dit :

Je le ferai en temps voulu. J'ai souhaité parler de l'essentiel car le tuto est déjà assez dense. En ce qui concerne le fichier de config, j'ai bien conscience que je ne t'apprendrai rien alors à quoi bon l'ajouter pour l'instant ?

Détrompe toi ! Je n’y connais pas grand-chose. Juste ce que j’ai pu lire et comprendre.

il y a par exemple ces paramètres que je ne comprends pas malgré les exemples vus : 

CanonicalizeHostname

ou lui :

CanonicalDomains

Et donc plein d’autres 😊 

 

[CyberFr]

Il y a 1 heure, MilesTEG1 a dit :

Il y a par exemple ces paramètres que je ne comprends pas malgré les exemples vus : 

Je ne sais pas si, concernant le fichier de config, on parle de la même chose. C'est pourquoi j'ai complété le tutoriel en y ajoutant un exemple de fichier de config avec plusieurs entrées.

[MilesTEG1]

il y a 14 minutes, CyberFr a dit :

Je ne sais pas si, concernant le fichier de config, on parle de la même chose. C'est pourquoi j'ai complété le tutoriel en y ajoutant un exemple de fichier de config avec plusieurs entrées.

Je parlais bien de ce fichier que tu as rajouté dans la configuration 😊

Il faudra ensuite que tu parles du fichier côté serveur , le sshd_conf ou /etc/ssh/sshd_config.d/ssh_keys.conf qui permet de faire que le serveur n’accepte plus que la clé ssh et plus le mot de passe.

À la limite, je me dis qu’avoir un compte secours avec un mot de passe le plus long possible (64 caractères pour dsm) et n’autoriser que celui-ci en accès mot de passe serait une bonne idée 😊 enfin pour un nas 😊

[CyberFr]

Il y a 14 heures, MilesTEG1 a dit :

l faudra ensuite que tu parles du fichier côté serveur , le sshd_conf ou /etc/ssh/sshd_config.d/ssh_keys.conf qui permet de faire que le serveur n’accepte plus que la clé ssh et plus le mot de passe.

Ne pas confondre vitesse et précipitation ! Parce que cela nécessite de modifier le fichier système sshd_config et d'utiliser un éditeur de texte en CLI comme vi. Les Macounets y sont-ils prêts ? J'aborderai ce point lorsqu'il y aura une demande parce que je ne veux pas qu'on puisse me reprocher après que le jouet est cassé.

Il y a 14 heures, MilesTEG1 a dit :

À la limite, je me dis qu’avoir un compte secours avec un mot de passe le plus long possible (64 caractères pour dsm) et n’autoriser que celui-ci en accès mot de passe serait une bonne idée 😊 enfin pour un nas 😊

À part que si tu modifies le fichier sshd_config, la modif s'applique à tous les utilisateurs et que tu ne pourras pas utiliser ton super mot de passe de 64 caractères. Sauf si tu modifies une autre variable que je ne connais pas.