SSL et SSH fournissent tous deux les éléments cryptographiques pour construire un tunnel pour le transport de données confidentielles avec une intégrité vérifiée. Pour cette partie, ils utilisent des techniques similaires et peuvent souffrir du même type d'attaques, ils doivent donc fournir une sécurité similaire (c'est-à-dire une bonne sécurité) en supposant qu'ils sont tous deux correctement mis en œuvre. Le fait que les deux existent est une sorte de syndrome du NIH: les développeurs SSH auraient dû réutiliser SSL pour la partie tunnel (le protocole SSL est suffisamment flexible pour accueillir de nombreuses variantes, y compris ne pas utiliser de certificats).

Ils diffèrent sur les choses qui se trouvent autour du tunnel. SSL utilise traditionnellement des certificats X.509 pour annoncer les clés publiques du serveur et du client; SSH a son propre format. De plus, SSH est livré avec un ensemble de protocoles pour ce qui se passe à l'intérieur du tunnel (multiplexage de plusieurs transferts, authentification par mot de passe dans le tunnel, gestion des terminaux ...) alors qu'il n'y en a pas dans SSL , ou, plus précisément, lorsque de telles choses sont utilisées dans SSL, elles ne sont pas considérées comme faisant partie de SSL (par exemple, lorsque vous effectuez une authentification HTTP basée sur un mot de passe dans un tunnel SSL, nous disons que cela fait partie de "HTTPS", mais cela fonctionne vraiment d'une manière similaire à ce qui se passe avec SSH).

Conceptuellement, vous pouvez prendre SSH et remplacer la partie tunnel par celle de SSL. Vous pouvez également prendre HTTPS et remplacer l'élément SSL par SSH-with-data-transport et un hook pour extraire la clé publique du serveur de son certificat. Il n'y a aucune impossibilité scientifique et, si elle est faite correctement, la sécurité resterait la même. Cependant, il n’existe pas d’ensemble répandu de conventions ou d’outils existants pour cela.

Nous n’utilisons donc pas SSL et SSH pour les mêmes choses, mais c’est à cause des outils historiquement fournis avec les implémentations de ces protocoles, pas en raison d'une différence liée à la sécurité. Et quiconque implémente SSL ou SSH serait bien avisé de regarder quels types d'attaques ont été tentés sur les deux protocoles.

Ce n'est pas une comparaison raisonnable à faire. SSL est une méthode générale de protection des données transportées sur un réseau, tandis que SSH est une application réseau permettant de se connecter et de partager des données avec un ordinateur distant.

La protection de la couche de transport en SSH est similaire en capacité à SSL, Donc, ce qui est "le plus sécurisé" dépend de ce que votre modèle de menace spécifique appelle et si les implémentations de chaque solution résolvent les problèmes que vous essayez de résoudre.

SSH dispose alors d'une couche d'authentification utilisateur dont SSL manque (parce qu'il n'en a pas besoin - SSL a juste besoin d'authentifier les deux interfaces de connexion que SSH peut également faire). Dans l'art UTF-8:

  SSL SSH + ------------- + + ----------------- + | Rien | | RFC4254 | Multiplexage de connexion + ------------- + + ----------------- + | Rien | | RFC4252 | Authentification des utilisateurs + ------------- + + ----------------- + | RFC5246 | | RFC4253 | Transport de données chiffrées + ------------- + + ----------------- +  

Concernant le problème dont il y a plus d'attaques potentielles contre, il semble clair que SSH a une plus grande surface d'attaque. Mais c'est juste parce que SSH a toute une application intégrée: la surface d'attaque de SSL + quelle que soit l'application que vous devez fournir ne peut pas être comparée car nous n'avons pas assez d'informations.

D'un point de vue cryptographique strict, ils fournissent tous deux un cryptage authentifié, mais de deux manières différentes.

SSH utilise ce que l'on appelle Encrypt-and-MAC, c'est-à-dire que le message chiffré est juxtaposé à un code d'authentification de message (MAC) du message clair pour ajouter de l'intégrité. Il n'est pas prouvé que cela est toujours totalement sécurisé (même si dans des cas pratiques cela devrait suffire).

SSL utilise MAC-then-Encrypt: un MAC est juxtaposé au texte clair, puis ils sont tous les deux cryptés . Ce n'est pas non plus le meilleur, car avec certains modes de chiffrement par blocs, certaines parties du MAC peuvent être devinables et révéler quelque chose sur le chiffrement. Cela a conduit à des vulnérabilités dans TLS 1.0 (attaque BEAST).

Ils ont donc deux faiblesses théoriques potentielles. La méthode la plus puissante est Encrypt-then-MAC (ajoutez un MAC du message chiffré), qui est implémentée, par exemple, dans IPsec ESP.

Je pense qu'il y a un aspect de cette comparaison qui a été négligé. user185 s'est approché mais n'y est pas vraiment arrivé. Je suis d'accord pour dire que ce sont des pommes et des oranges et que la comparaison des pommes aux pommes est meilleure que HTTPS et SSH. HTTPS et SSH utilisent différentes couches du modèle OSI et donc chiffrent les données à différents moments de la transmission. Ensuite, les vraies questions à se poser seraient celles de savoir quand ces données sont-elles cryptées et non cryptées pendant la transmission. Cela révélera vos surfaces d'attaque potentielles. Avec HTTPS, une fois que le paquet est reçu par un appareil du réseau de destination (serveur Web, routeur frontalier, équilibreur de charge, etc.), il n'est pas chiffré et passe le reste de son trajet en texte brut. Beaucoup diront que ce n'est pas un gros problème puisque le trafic est interne pour le moment, mais si la charge utile contient des données sensibles, elle est stockée non cryptée dans les fichiers journaux de chaque périphérique réseau qu'elle traverse jusqu'à ce qu'elle atteigne son destination finale. Avec SSH, généralement, le périphérique de destination est spécifié et la transmission est cryptée jusqu'à ce qu'elle atteigne ce périphérique. Il existe des moyens de rechiffrer les données HTTPS, mais ce sont des étapes supplémentaires que la plupart oublient de prendre lors de la mise en œuvre d'une solution HTTPS dans leur environnement.

ssh est comme une clé (privée) et la serrure (publique)

ssl est comme la porte et les briques.

ssl fournit un lien sécurisé entre les deux serveurs informatiques . par exemple, le vôtre et celui auquel vous vous connectez.

ssh est la manière dont l'ordinateur qui se connecte peut se vérifier et accéder.

SSL est une couche de protocole qui est abstraite du contenu en cours de tunnel. SSH est une version sécurisée de shell (SH), il n'a pas été conçu pour contenir une couche abstraite en dessous, il a été conçu spécifiquement pour transporter le trafic shell. Donc, bien que les opérations cryptographiques soient utilisées dans les deux, et que ces opérations cryptographiques puissent même être les mêmes, le but, et donc la conception générale, est assez différent.

Gardez à l'esprit qu'il existe des différences spécifiques (comme cela a été cité ci-dessus ), mais la plupart sinon la totalité de ces différences sont enracinées dans le but des différents protocoles.

Le problème est double, ce n'est pas seulement la force et la faiblesse du cryptage. Mais c'est la facilité et la commodité de la livraison. Donc, du point de vue commercial, SSL / TLS est plus pratique et plus simple car il ne nécessite qu'un navigateur et un certificat public ou privé.

Et SSH nécessite soit l'application soit le client léger installé pour l'utiliser. C'est davantage un problème du point de vue et de l'assistance d'un client Internet.

Si vous recherchez vraiment SSH vs SSL (TLS), la réponse est SSH.

L'une des raisons pour lesquelles SSH l'emporte sur SSL est la façon dont il effectue l'authentification. Pour cette raison, lorsque vous utilisez FTP, utilisez le protocole SSH (SFTP) plutôt que FTPS (FTP sur SSL).

SSH est utilisé dans les réseaux d'entreprise pour:

• fournir un accès sécurisé aux utilisateurs et des processus automatisés
• transferts de fichiers interactifs et automatisés
• émission de commandes à distance

source: https://www.ssh.com/ssh/protocol/#sec-Typical-uses-of-the-SSH-protocol