Quelle est la différence entre SSH et IPsec?
Il semble y avoir un cryptage similaire dans les deux. Ils utilisent tous les deux asymétriques (RSA, courbes elliptiques, etc.) pour l'échange de clés initial, puis passent à un protocole symétrique (AES, Blowfish, etc.). Je me demande si quelqu'un ici pourrait avoir un moment pour expliquer la différence entre les 2 et comment ils apparaîtraient différemment pour l'utilisateur (vitesse, applications dans lesquelles ils sont présents, etc.).
La réponse de @ graham-hill est correcte en général mais courte et pédantiquement incorrecte, je vais donc m'étendre sur elle.
SSH est au niveau de l'application - vous pouvez le considérer comme SSH/TCP/IP ou SSH sur TCP-sur IP. TCP est la couche Transport dans ce mix, IP est la couche Internet. D'autres protocoles "Application" incluent SMTP, Telnet, FTP, HTTP/HTTPS ...
IPSec est implémenté à l'aide de deux transports distincts - ESP ( Encapsulating Security Payload pour le chiffrement) et AH ( Authentication Header pour l'authentification et l'intégrité). Supposons donc qu'une connexion Telnet soit établie via IPSec. Vous pouvez généralement l'envisager comme Telnet/TCP/ESP/AH/IP.
(Juste pour rendre les choses intéressantes, IPSec a deux modes - Transport (décrit ci-dessus) et Tunnel. En mode tunnel, la couche IP est encapsulée dans IPSec puis transmise sur (généralement) une autre couche IP. Vous vous retrouvez donc avec Telnet/TCP/IP/ESP/AH/IP!)
Donc - vous demandez "expliquer la différence entre les deux" -
SSH est une application et IPSec est un transport. SSH transporte donc "un" type de trafic, et IPSec peut transporter "n'importe quel" type de trafic TCP ou UDP. * Cela a des implications décrites ci-dessous:
Vous demandez, "comment ils apparaîtront différemment pour l'utilisateur" -
Comme IPSec est une couche de transport, elle doit être invisible pour l'utilisateur - tout comme la couche TCP/IP est invisible pour l'utilisateur d'un navigateur Web. En fait, si IPSec est utilisé, il est invisible pour le écrivain du navigateur Web et du serveur Web - ils n'ont pas à se soucier de configurer ou ne pas configurer IPSec; c'est le travail de l'administrateur système. Comparez cela à HTTPS, où le serveur a besoin d'une clé privée et d'un certificat correctement activés, de bibliothèques SSL compilées et de code écrit; le navigateur client a des bibliothèques SSL compilées et du code écrit et a soit la clé publique CA appropriée, soit crie fort (empiétant sur l'application) s'il n'y en a pas.
Lorsqu'IPSec est configuré, car il agit au niveau de la couche de transport, il peut prendre en charge plusieurs applications sans aucun problème. Une fois que vous avez configuré IPSec entre deux systèmes, c'est une différence vraiment mineure entre travailler pour 1 application ou 50 applications. De même, IPSec constitue un wrapper facile pour les protocoles qui utilisent plusieurs connexions comme FTP (le contrôle et les données peuvent être des connexions distinctes) ou H.323 (non seulement plusieurs connexions, mais plusieurs transports (TCP et UDP)!).
Du point de vue de l'administrateur, cependant, IPSec est plus lourd que SSH ou SSL. Il nécessite plus de configuration car il opère sa magie au niveau du système plutôt qu'au niveau de l'application. Chaque relation (d'hôte à hôte, d'hôte à réseau ou de réseau à réseau) doit être configurée individuellement. D'un autre côté, SSH et SSL sont généralement opportunistes - en utilisant soit un modèle PKI (CA) ou Web de confiance, ils facilitent raisonnablement la confiance à l'autre extrémité de la connexion sans beaucoup de configuration à l'avance. IPSec peut être opportuniste, mais il n'est généralement pas utilisé de cette façon, en partie parce que la configuration d'une connexion IPSec nécessite souvent des essais et des erreurs. L'interopérabilité entre différents fournisseurs (Linux, Checkpoint, Cisco, Juniper, Etc) n'est pas transparente; la configuration utilisée pour créer Cisco <-> Checkpoint est susceptible d'être différente de la configuration utilisée pour créer Cisco <-> Juniper. Comparez cela avec SSH - le serveur OpenSSH ne se soucie pas vraiment si vous utilisez PuTTY, OpenSSH (* nix ou Cygwin) SSH ou Tectia SSH.
En ce qui concerne la vitesse - je n'ai pas de bons chiffres à vous donner, et une partie de la réponse est "cela dépend" - si IPSec est impliqué, alors le traitement IPSec réel est susceptible d'être déchargé sur un pare-feu ou un concentrateur VPN avec un matériel rapide dédié, ce qui le rend plus rapide que SSH qui est à peu près toujours le cryptage en utilisant le même CPU à usage général qui exécute également le système d'exploitation du serveur et les applications. Ce n'est donc pas vraiment des pommes à pommes; Je parie que vous pourriez trouver des cas d'utilisation où l'une des deux options est plus rapide.
* Ce n'est pas strictement vrai. SSH prend en charge une application de terminal, une application de copie de fichiers/ftp et une application de tunneling TCP. Mais en réalité, il s'agit simplement d'une application vraiment riche , pas d'un transport - son tunnelage n'est pas un remplacement du transport IP.
SSH est au niveau application de TCP/IP tandis qu'IPSEC est au niveau transport.
Il peut y avoir une grande différence lors de l'exécution de connexions TCP via un tunnel basé sur TCP comme SSH par rapport à un système de livraison de paquets non garanti comme IPsec où il y a une perte de paquets significative) Voir http://sites.inka.de/bigred/devel/tcp-tcp.html pour plus de détails et un exemple réel.
Note latérale - J'ai exécuté TCP sur SSH depuis quelques décennies maintenant car c'est pratique et je n'ai pas rencontré le problème, je vais passer à une solution qui gère mieux la perte de paquets mais est plus difficile pour configurer la solution uniquement si j'en ai besoin.