Bonjour,
Je viens juste vous demander ce que vous pensez de la sécurité du protocole SSH. En effet j'ai demandé à un admin réseau qui a de l’expérience et il m'a assuré que le protocole SSH a une sécurité quasi-nulle et que qu'il était très vulnérable aux attaques extérieures (pas eu plus d'infos).

J'aimerais savoir ce que vous en pensez.
Merci.

La sécurité du protocole SSH ce n'est rien de moins que la cryptographie asymétrique (échange de clé publique) suivie d'une cryptographie symétrique (échange d'une clé unique).

Tu peux augmenter la taille des clés publiques et privés si tu veux encore augmenter la sécurité, car l'unique moyen de casser un RSA (l'algorithme de cryptographie asymétrique utilisé) c'est une attaque par force brute.

Une clé standard de 2048 bits c'est-à-dire une clé de 2048 « 0 » ou « 1 » aléatoires c'est donc 2 puissance 2048 possibilité de clé.

3x10^616 possibilités de clés

contre

10^80 atomes dans l'univers

Sinon tu fais du SSH dans un VPN

Kadcom, je pense que ton admin systeme devrait changer de metier parcequ'il ne connait rien a celui la

Il a sûrement voulu te dire que SSH est "vulnérable" aux attaques par bruteforce par exemple.

Ce genre d'attaque n'est absolument pas spécifique à SSH.

Donc il t'as donné une réponse bien trop vague.

ça ou rien, ça t'aurais pas plus avancé.

Mais où vont ils chercher ces admins en mousse ?

Haha le bruteforce SSH... "viens faire du bruteforce, sur un serveur qui n'accepte que l'authentification par clés" .

Bref, n'est pas paranoïaque qui veut (pas intelligemment du moins), laisse ce type dans sa connerie.

OK bon c'est rassurant vu que je l'utilise sur tous les serveurs de prod. Parce quand je lui ai demandé gentiment "y a moyen d'avoir une redirection de port sur le 22" il m'a juste laché un "oula sur le SSH carrément ? C'est pas terrible en terme de sécurité."

Bon c'est rassurant de savoir que le protocole SSH est tout de même un peu secure même si je m'en douteux.
THX a lot.

Disons que le port 22 comme le 443 ou le 80 ça fais partie des trucs qui se font scanner par des bots chinois à coup de nmap automatisé.

Généralement ça se contente de frapper à la porte sans plus.

J'en vois régulièrement dans mon /var/log/auth.log mais c'est rien de bien méchant.

Euh attends, j'ai bien lu ?

Tu fais de l'admin de prod, sans connaître des concepts de base ?

Ce qui est risqué en vrai, c'est d'avoir mis "toto" comme password pour root (et j'en passe, des passwords de merde), d'avoir "PermitRootLogin Yes" dans /etc/ssh/sshd_config , et de permettre les tentatives de login.

Là, tu peux être certain que dans une semaine ton serveur envoie de la pub pour du viagra dans tous les sens, etc.

Du coup les solutions sont multiples:
-PermitRootLogin No (parce que bon, un bruteforcer a déjà moins de chances de connaitre un login existant et passwordé autre que root sur la machine)
-Un système anti-bruteforce (fail2ban fait bien son travail je trouve, pour ça)
-Le must du must, désactiver le login par password, au profit de l'authentification par clés RSA. (et bien évidemment, sécurises ses clés avec un password tout aussi puissant sinon plus, que celui du compte)

Les pare-feus comme PacketFilter savent eux aussi contrer le bruteforce sur ce genre de protocoles.

En fait le ssh est suffisamment sécure qu'il est utilisé même sur certaines infrastructures critiques de la défense américaine régulièrement auditées.

Même remarque que sur l'autre topic.

On n'a pas attendu que la défense américaine utilise SSH pour le décréter sûr.

En vrai les firewalls ne servent qu'a bloquer les couillons. Les botnet qui attaquent ssh font du scan distribue des machines avec fdes frequences d'access par ip suffisament bas pour passer sous les radars des firewalls. Vraiment la seule protection est l'audit des mots de passes. Et plus generalement desactive les access par password.

Je me demande si le couillon qui t'a répondu confond ssh avec telnet...

En général on n'ouvre en effet pas le port SSH sur l'extérieur sur des plateformes de prod. Pas forcement pour un problème avec le protocole en lui même mais plus pour des problèmes de mots de passe foireux. (Ou même par clef dans le cas du presta qui se fait chourrer son portable avec le ~/.ssh/ par exemple)

En plus laisser le service ssh tourner en publique c'est la garantit d'avoir des robots qui te scan avec des mots de passe aléatoires 24/24h 7/7j...

Du coup il y a plusieurs choses à faire pour éviter ça :

- Restreindre l'accès au port 22 à une ou plusieurs IP (netfilter ou tcpwrapper...)
iptables -A INPUT -i eth0 -s ip_pub_authorisée_en_ssh -m state --state NEW,ESTABLISHED -p tcp --dport 22 -j ACCEPT

- Mettre le ssh en écoute sur autre chose que 22 (10022 par exemple...)

- Installer un truc qui bloque l'ip de la personne après X tentatives infructueuses : par exemple denyhost

- Installer knockd et ouvrir le ssh uniquement en knoking...

Bref il y a moyen de sécuriser SSH.

J'aurais tendance à conseiller de mettre SSH que vraiment si c'est utile, après tout si tu n'en a pas plus besoin que sa (dans le sens vital) cela ne sert à rien d'ouvrir une porte, même si elle est sécurisé

En même temps pour administrer un serveur, c'est compliqué de se passer de SSH. A la limite tu m'aurait parlé d'un serveur web, ou autre, je ne dis pas, mais pour SSH, les mesures de sécurité ont été évoqués et sont simples à mettre en oeuvre.
Dans la même veine, on peut enlever les cartes réseau, cela sécurise aussi ;)

Ha oui, j'avais oublié le knocking parmi les solutions.
Pour ma part, mon serveur actuel est planqué derrière un VPN (accessible seulement avec un certificat valide), et le service SSH de la machine n'accepte que les clés RSA, pas de passwords. C'est un peu bourrin, mais je dors un peu mieux on va dire.

J'ai rien contre ce que tu fais G_Bot, mais le jour où ton PC qui contient le certificat public qui a été généré par le serveur, est volé, ben.... t'es bon pour aller dans la salle serveur pour regénérer le tout et bannir l'ancien

Nh3xus La salle des serveurs, actuellement, c'est ma chambre. (j'ai oublié de préciser ça)
C'est pour ça que j'ai opté pour cette solution, je sais que j'ai un accès physique à la machine en cas de besoin. (et franchement, ça m'énerve toujours un peu de ne pas avoir la possibilité d'accéder physiquement à un serveur quand je dois bosser souvent avec... même si je ne fais pas de connerie, je sais pas, ça manque de transparence pour moi c'est psychologique)