Salut journal,
OpenSSH (OpenBSD Secure Shell ou ssh pour les intimes) est un ensemble d'outils informatiques libres permettant des communications sécurisées sur un réseau informatique en utilisant le protocole SSH.
Et cet outil a une actu récente brûlante,
Comme je ne l'ai pas vu ces derniers jours dans linuxfr, je le pose là :
https://access.redhat.com/blogs/766093/posts/3051131
Attention c'est du sshpr0n - littéralement - au menu :
- Simplification de la configuration des proxy avec le nouveau paramètre ProxyJump
- Forward des Unix socket (oui oui!)
- Simplification de la configuration de ssh-agent (fini les scripts pourris)
Plus d'autres trucs trop nerdy (crypto, fingerprint, privileges) pour m'extasier…
Voilà voilà,
# Dernières actus... chez Red Hat
Posté par Cascador (site web personnel) . Évalué à 6.
Salute,
Juste pour préciser que la version 7.4 de OpenSSH (dont parle ton lien) est sortie le 19.12.2016, la 7.5 est sortie le 20.03.2017.
https://www.openssh.com/releasenotes.html
Tcho !
# Question pour les pros de SSH
Posté par snurpsss . Évalué à 2.
Petite question: pour éviter qu'on tente de se connecter à mon server (via SSH), j'ai modifier le port par defaut. Mais un scan peut encore le trouver, et si l assaillant tente de s'y connecter, il aura un prompt lui indiquant qu'il s'agit de mon port SSH.
Outre le port knocking et l'ajout de clé, je me demandais s'il était possible de mettre en place une passphrase additionnel pour autorisé le serveur à répondre:
ssh -p 1999 user@monserveur.com --passphrase:ouvretoi
Le serveur vois que j'initie une connexion avec la passphrase adéquate, et me renvois la demande de mot de passe habituelle.
ssh -p 1999 user@monserveur.com
Là, pas de passphrase, le serveur ne répond rien.
Est ce que cela existe ?
[^] # Re: Question pour les pros de SSH
Posté par Christophe B. (site web personnel) . Évalué à 3.
C'est pas une authentification par clé publique/privée que tu cherches ?
[^] # Re: Question pour les pros de SSH
Posté par Sufflope (site web personnel) . Évalué à 3.
Non, il veut schématiquement qu'il y ait un champ configurable dans le "premier paquet" envoyé lors de l'initiation de la connexion, et que s'il n'est pas présent, le serveur fasse le mort pour qu'on ne puisse meme pas savoir qu'un SSHd tourne. Ça me parait pas idiot mais ça ressemble à du port knocking, pas sûr que ce soit de la responsabilité d'SSH lui-même de gérer ça.
[^] # Re: Question pour les pros de SSH
Posté par Sacha Trémoureux (site web personnel) . Évalué à 4.
Si tu ne fais pas confiance en SSH pour sécuriser ton accès, il faut que tu passes par le réseau pour isoler d'une façon ou d'une autre le protocole.
Sinon tu t'embêtes pour rien. Surtout qu'il existe des softs pour limiter le bruteforcing.
[^] # Re: Question pour les pros de SSH
Posté par EauFroide . Évalué à 2. Dernière modification le 27 juillet 2017 à 17:23.
Tu peux aussi spécifier à ton serveur SSH de n'écouter que sur 127.0.0.1 (se qui va le faire disparaître de nmap (sauf en localhost)) et configurer un accès via Tor Hidden Service.
Je n'ai pour le moment jamais détecté de tentative d'intrusion via cette méthode.
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Question pour les pros de SSH
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Ssh + une lib de portknocking ?
[^] # oui avec 2 factor auth
Posté par SauronDeMordor (site web personnel) . Évalué à -1.
j utilise cela pour les connexions venant de l exterieur et aussi avec une règle match dans le sshd_config
et ensuite avec le google authentication ca fait le taf.
l'app dans le telephone et on a l'authent avec le totp.
[^] # Re: Question pour les pros de SSH
Posté par showtime . Évalué à 10.
Pour répondre à ta question, oui il existe une solution, et elle est meilleure que le port-knocking: c'est le Single Packet Authorization ou SPA.
De plus, cette solution est indépendante de SSH et tu peux donc l'utiliser pour n'importe quel service sur n'importe quel port.
Tout d'abord, le port-knocking possède (de mémoire) au moins deux faiblesses:
- Il utilises plusieurs paquets, ce qui peut être utilisé pour l'identifier et éventuellement le stopper (en empêchant le deuxième ou troisième paquet d'arriver à destination)
- Il n'utilise pas de partie aléatoire, ce qui permet de rejouer une séquence interceptée
NB: certes, ce n'est pas à la portée de tout le monde.
Ensuite, concernant le SPA, je te conseille ce très bon article:
https://www.linuxjournal.com/article/9565
Enfin, comme implémentation du SPA, il y a fwknop, et voici les 2 liens que j'ai conservés:
- http://www.cipherdyne.org/fwknop/
- http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html
Tout cela est très intéressant à lire et je parie que ça ne profitera pas qu'à toi.
# Puisque qu'on parle de ssh ...
Posté par Christophe B. (site web personnel) . Évalué à 4.
Bonjour à tous,
puisque que l'on parle de SSH j'en profites pour vous demander votre avis :
comment faites vous pour avoir 2 entrées SSH sur le même serveur
exemple :
port 2222 pour les accès depuis l'extérieur/WAN avec clé privée/publique
port 22 pour les accès depuis le LAN en mode password simple
sans réfléchir je me dit tu copies /etc/sshd en /etc/sshd_2222 et tu lances 2 services
mais il y a peut être plus intelligent
Donc si vous avez des idées ou si vous l'avez déjà fait … s'il vous plaît partagez
[^] # Re: Puisque qu'on parle de ssh ...
Posté par Dabowl_75 . Évalué à 10.
tu peux demander à ssh d'écouter sur plusieurs ports et pour chacun d'entre-eux, spécifier une adresse d'écoute différente (si ton serveur a plusieurs adresses) :
Et pour autoriser l'authentification par password uniquement depuis le lan :
[^] # Re: Puisque qu'on parle de ssh ...
Posté par Christophe B. (site web personnel) . Évalué à 3.
Merci beaucoup pour l'info tu viens de faire un heureux :)
j'avais pas du chercher dans le bon sens …
et respect pour les concepteurs/mainteneurs de SSH
[^] # Re: Puisque qu'on parle de ssh ...
Posté par copapa . Évalué à 1.
L'exemple d'une deuxième configuration ssh est un des exemples utilisés par Redhat pour expliquer comment créer des unit files pour systemd : https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect-Managing_Services_with_systemd-Unit_Files.html#ex-Managing_Services_with_systemd-Multiple_sshd
Et comme tu le dit, il copie la config et créé un nouveau service.
[^] # Re: Puisque qu'on parle de ssh ...
Posté par Christophe B. (site web personnel) . Évalué à 3.
Oui mais je trouve l'autre solution plus élégante …
et honnêtement en cas de dépannage … chercher un 2eme fichier de config ssh … c'est pas le premier truc que je ferais
mais merci aussi pour le lien
SSH c'est bon pour la santé … et sans modération
[^] # Re: Puisque qu'on parle de ssh ...
Posté par Sufflope (site web personnel) . Évalué à 3.
Elle parait peut-être plus élégante parce qu'il n'y a que deux lignes qui changent dans une grosse config ; si les configs divergeaient fortement ça serait sûrement l'option à deux configs qui serait plus élégante qu'un fichier avec du spécifique partout.
Si tu es prêt à spécifier le port sur la ligne de commande de SSHd plutôt que dans la conf, et si c'est la seule chose qui diffère, tu peux même le faire avec un fichier et des
template units
.[^] # Re: Puisque qu'on parle de ssh ...
Posté par Dabowl_75 . Évalué à 1.
Pour industrialiser c'est clairement plus propre d'avoir plusieurs fichiers de conf. Mais dans son cas c'était du perso alors j'ai proposé un peu plus tricky.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.