SFTP et chiffrement

[chloroplaste]

Bonjour,

Je viens à vous afin d'avoir des lumières sur un point qui m'échappe même après des recherches sur Internet.
J'ai mis en place un serveur SFTP sur mon Syno afin de partager des données avec une personne précise.J'ai donc suivi précisément la base de connaissances Synology et avec un peu d'aide du forum en prime, tout s'est bien mis en place.

Maintenant j'ai ainsi :
- La clé privée stockée sur le client Filezilla de la personne à qui j'ai ouvert ce serveur SFTP
- La clé publique présente sur le serveur dans un dossier .ssh du dossier /home de l'utilisateur (La clé publique est en 2 exemplaire : Un dans un fichier id-rsa.pub et l'autre dans authorized keys.

J'ai bien compris le principe de chiffrement asymétrique. La clé privée permet de déchiffrer un message, chiffrer avec le publique mais aussi de signer un document. La clé publique permet, elle de chiffrer un document, ou de vérifier qu'un document provient bien du possesseur de la clé privée.

Mes questions :
- Avoir un fichier id_rsa.pub en plus du authorized_keys n'est-il pas inutile. Peut-être ai-je mal compris un  point du process ?
- Comment se déroule le chiffrement des données en SFTP ? Si le serveur ne possède que la clé publique, il est donc en mesure de chiffrer les données qui vont vers le client Filezilla. Ce client peut alors les déchiffrer avec sa clé publique. Mais comment cela se passe-t-il dans le sens inverse. Le serveur n'ayant pas de clé privé ni publique, comment fait-il le déchiffrement ?

Cela signifie-t-il que l'échange de données en SFTP (dans mon cas) n'est chiffré que dans le sens Serveur -> Client et pas dans l'autre ?

Merci d'avance pour vos lumières.

[chloroplaste]

Après quelques recherches, je suis tombé là-dessus :

"Mise en place du canal sécurisé

La mise en place d'une couche de transport sécurisée débute par une phase de négociation entre le client et le serveur afin de s'entendre sur les méthodes de chiffrement à utiliser. En effet le protocole SSH est prévu pour fonctionner avec un grand nombre d'algorithmes de chiffrement, c'est pourquoi le client et le serveur doivent dans un premier temps échanger les algorithmes qu'ils supportent. 
Ensuite, afin d'établir une connexion sécurisée, le serveur envoie sa clé publique d'hôte (host key) au client. Le client génère une clé de session de 256 bits qu'il chiffre grâce à la clé publique du serveur, et envoie au serveur la clé de session chiffrée ainsi que l'algorithme utilisé. Le serveur déchiffre la clé de session grâce à sa clé privée et envoie un message de confirmation chiffré à l'aide de la clé de session. A partir de là le reste des communications est chiffré grâce à un algorithme de chiffrement symétrique en utilisant la clé de session partagée par le client et le serveur. "

 

Du coup cela répond à ma question de la façon dont étaient chiffrés les échanges. Mais 2 questions subsistent : 

- Avoir un fichier id_rsa.pub en plus du authorized_keys n'est-il pas inutile. Peut-être ai-je mal compris un  point du process ?
- Où le serveur obtient-il son "host key" ? est-elle générée automatiquement à chaque début de session SSH ?

[CoolRaoul]

il y a une heure, chloroplaste a dit :

- Avoir un fichier id_rsa.pub en plus du authorized_keys n'est-il pas inutile. Peut-être ai-je mal compris un  point du process ?

Tout à fait, ça ne sert à rien.

il y a une heure, chloroplaste a dit :

Où le serveur obtient-il son "host key" ? est-elle générée automatiquement à chaque début de session SSH ?

Elle est générée une fois pour toute lors du premier lancement du démon SSH sur le serveur (à l'installation du NAS donc).

Elle n'a pas vocation à changer par la suite.

[chloroplaste]

Merci d'avoir éclairé ma lanterne.