SPOILER ALERT : C'est long. Très long en fait !
Je pensais franchement avoir tout testé avec cette commande : la rentrer directe dans l'invite de commande, la tester sur le serveur distant (inutile, j'en conviens…), tenter d'éditer des fichiers ssh config… et j'en passe.
Autrement dit, tu as fait tellement d'essais que tu ne sais plus ce que tu as fait. Pour éviter cela, la méthode de base consiste à noter (dans un cahier, un bloc-notes, ou ce que tu veux) toutes les modifications ou tentatives. Il ne faut pas tenter de les retenir : qui se rappelle de son premier essai après cinquante tentatives ? Au besoin, on créé une sauvegarde du fichier à chaque modification.
C'est un peu extrême pour une utilisation personnelle, et pourtant, je garantis par expérience qu'on arrive bien plus vite à ce qu'on veut lorsqu'on note un maximum de choses et/ou que l'on sait où l'on va. Dit autrement, j'ai plus de chances d'arriver à destination avec une carte routière que sans aucun moyen de repère. 
Maintenant, quelques éléments spécifiques à ton problème :
J'ai pas fais le rapprochement entre la commande ssh en elle-même et le paramètre ssh du service rsync
Pour le coup, moi non plus, je n'ai même pas fait attention à la commande rsync. Ce que je voulais que tu testes, c'était une commande ssh en ligne de commande, sans autre commande autour, pour voir si ton serveur réagissait à l'identique.
Lorsque j'automatise quelque chose, je fais d'abord toute la procédure à la main. Cela permet de vérifier que j'ai bien le résultat que je veux, commande par commande. Je combine le tout ensuite, en vérifiant à chaque fois qu'il n'y a pas de différence. En revanche, ça peut être long.
le problème vient des serveurs 1and1 un peu trop oldschool ?
Il semblerait oui.
On a pas trop la main sur ça sur un mutualisé si ?
Ca dépend de ton offre exacte. Il est possible d'être sur un serveur où tu n'a la main que sur ton serveur sans voir ceux des autres (VPS) ou de partager complètement une machine administrée par 1&1.
Mais qu'arrive-t-il si, c'est justement mon cas, je déplace ma clé privée dans un autre répertoire et que dans ma commande ssh, je ne précise pas l'argument '-i PRIVATE_KEY' ?
En toute logique il ne trouve pas la clé. Je pense que la suite dépend de la configuration du client et du serveur :
- il ne se connecte pas
- ou il demande un mot de passe
Dois-je déclarer dans un certain fichier les nouvelles clées générées pour qu'elles soient recherchées ? Ou il cherche par rapport au nom ou quelque chose du genre ? Il parse peut-être toutes les clés privées du répertoire /.ssh ?
Non.
Le serveur ssh se base sur le fichier sshd_config. Il est possible d'en spécifier un sur la ligne de commande, mais par défaut il est dans /etc/ssh/sshd_config.
Ce fichier contient toutes les options du serveur SSH, sa configuration est décrite ici. C'est dans ce fichier que l'on indique où se trouvent les autres fichiers, contenant les clés publiques ou privées, par exemple :
AuthorizedKeysFile
Spécifie le fichier contenant les clefs publiques à utiliser pour l'authentification de l'utilisateur. AuthorizedKeysFile peut contenir des jetons de la forme %T qui sont substitués lors des réglages de la connexion. Les jetons suivant sont définis : %% est remplacé par le caractère « % », %h est remplacé par le répertoire de base (home directory) de l'utilisateur qui s'authentifie et %u est remplacé par le nom de cet utilisateur. Après substitution, AuthorizedKeysFile peut être un chemin absolu ou relatif au répertoire de base de l'utilisateur. Par défaut « .ssh/authorized_keys ».
(j'ai mis l'option à utiliser dans le fichier en gras).
Ensuite :
Je trouve que le sujet est assez floue, on trouve beaucoup de tutos pour savoir générés les clés, les utiliser mais c'est entièrement donner sur un plateau à chaque fois. La théorie de base sur système derrière est souvent bâclé, ou du moins j'ai mal cherché / compris. Vu ma demande initiale, je serais pas trop étonné.
Alors un peu de théorie rapide :
On reprend la base : SSH offre un accès à distance, principalement en ligne de commande à une autre machine. La machine que l'on utilise est appelée client et doit disposer d'un client SSH. La machine à laquelle on souhaite accéder est appelée serveur.
SSH est l'acronyme de "Secure SHell" soit "ligne de commande sécurisée" en bon français. Cela signifie que :
- la communication entre les deux machines en chiffrée
- les machines sont authentifiées
- les utilisateurs sont authentifiés
Pour cela, SSH a mis en place deux mécanismes principaux :
- l'authentification par mot de passe
- l'authentification asymétrique par paires de clés
Je passe sur la première méthode. La seconde fonctionne comme suit :
- On génère une paire de clés, c'est-à-dire des fichiers contenant une série de caractères calculée avec des maths complexes. L'une de ces clés est diffusable (on la dit publique), l'autre doit rester secrète (on la dit privée). Dans la phrase plus haut, "asymétrique" signifie que si j'utilise une clé pour chiffrer, je ne peux pas utiliser la même clé pour déchiffrer.
Du coup, si :
- je chiffre avec la clé publique, seule la clé privée peut déchiffrer. Comme je ne diffuse pas la clé privée, cela garantit que je serai le seul à pouvoir déchiffrer le message.
- je chiffre avec la clé privée : seuls les possesseurs de la clé publique pourront lire le message. Cela ne donne pas de confidentialité puisqu'en général on diffuse la clé publique, par contre, cela garantit que je suis l'émetteur du message puisque je suis le seul à utiliser la clé privée qui correspond à la clé publique. Ce sont ces particularités qu'une connexion SSH va utiliser.
Ca c'est la théorie.
En pratique, on génère une paire de clés. On exporte la publique sur le serveur. Lors d'une connexion SSH, le serveur va chiffrer un message aléatoire et conserver le message en clair de son côté. Le client qui dispose de la clé privée, va déchiffrer le message et présenter son résultat au serveur. Le serveur compare les deux résultats : si ils correspondent le client est bien celui qu'il prétend être.
On peut bien sûr, faire dans l'autre sens pour identifier le serveur. Cette fois c'est le client qui va chiffrer en utilisant la clé privée et demander au serveur de déchiffrer. De même, si ça correspond, le serveur a bien prouvé qu'il était le serveur.
Ensuite, il ne s'agit "que" de configuration. Tu as besoin de détails sur les fichiers ou autre ?
Si tu veux t'entraîner, un tutoriel qui correspond grosso-modo à ce que j'ai expliqué est là.
