Effectivement dans le man ils disent que par défaut ça sera du rsa pourtant chez moi c'est du ed25519 qui est créé par défaut. Je suis sur de l'openssh7.9_p1-r1 .
C'est des saletés de hipsters, il ne faut pas les écouter ! Ha ha ha
Plus sérieusement moi aussi ssh-keygen ça fait du rsa, je suis en Mint 19.1 (basé sur Ubuntu 18.04) et openssh-client en 7.6. Après clairement il est temps de passer à ed25519.
J'ai jeté un oeil dans la page man de ssh-keygen, et je trouve ceci, dans la section DESCRIPTION.
“The type of key to be generated is specified with the -t option. If invoked without any arguments, ssh-keygen will generate an RSA key.”
Il semblerait donc qu'il soit nécessaire de spécifier explicitement l'utilisation d'ed25519. J'ai testé sur ma station de travail tournant sous OpenSUSE Leap 15.0, et c'est bien le cas.
Merci pour l'info. Je vais de ce pas répondre à votre suggestion et supprimer l'ensemble du blog, dont le contenu est invalidé par l'utilisation d'une option pas assez sécurisée.
Surtout que par défaut openssh créer des clés ed25519, pas besoin de rajouter d'options.
Globalement OpenSSH a l'habitude de régulièrement changer ses paramètres par défaut pour intégrer les bonnes pratiques de sécurité (tant que ça ne casse pas la compatibilité).
Clairement, je ne plussoierais pas l'article. Je m'explique :
dès le début de l'article, où il est expliqué la génération d'une clé SSH, où l'on retrouve la commande minimaliste sur ‘rsa’ - alors qu'on sait clairement depuis plusieurs années qu'il faut/vaut mieux privilégier ‘ed25519’, et si vraiment besoin d'utiliser l'algo ‘rsa’, il est impératif d'utiliser l'option ‘-o’ pour utiliser le durcissement PKBDF… pfff, marre de voire de tels articles minimalistes !
De base il ne génère pas de html mais affiche en console le résultat. Du coup tu peux l'utiliser via SSH comme n'importe quelle appli.
Tu peux aussi l'utiliser en local genre ssh user@host ‘cat /var/log/nginx/access.log’ | goaccess –log-format=COMBINED
mmmhhhh…. je me demande s'il est utilisable en remote access. Par contre, il faut surement décrire in extenso le format de logs à parser, plutôt que parler en preset
C'est une mauvaise idée de changer l'URL après la parution, les liens balancés sur les réseaux sociaux sont faux du coup. Il vaut mieux rester avec l'erreur ou faire une redirection niveau site.
Je dis ça en connaisseur, c'est déjà arrivé plusieurs fois.
Effectivement dans le man ils disent que par défaut ça sera du rsa pourtant chez moi c'est du ed25519 qui est créé par défaut. Je suis sur de l'openssh7.9_p1-r1 .
Je me suis dit ça quand j'ai vu le blog OpenBSD stylé comme un site porno russe de la fin des années 90.
:o)
C'est des saletés de hipsters, il ne faut pas les écouter ! Ha ha ha
Plus sérieusement moi aussi ssh-keygen ça fait du rsa, je suis en Mint 19.1 (basé sur Ubuntu 18.04) et openssh-client en 7.6. Après clairement il est temps de passer à ed25519.
Messieurs un bon réveillon à tous, Tcho !
J'ai jeté un oeil dans la page man de ssh-keygen, et je trouve ceci, dans la section DESCRIPTION.
“The type of key to be generated is specified with the -t option. If invoked without any arguments, ssh-keygen will generate an RSA key.”
Il semblerait donc qu'il soit nécessaire de spécifier explicitement l'utilisation d'ed25519. J'ai testé sur ma station de travail tournant sous OpenSUSE Leap 15.0, et c'est bien le cas.
Merci pour l'info. Je vais de ce pas répondre à votre suggestion et supprimer l'ensemble du blog, dont le contenu est invalidé par l'utilisation d'une option pas assez sécurisée.
Un gentil bonjour de la garrigue gardoise.
:o)
Surtout que par défaut openssh créer des clés ed25519, pas besoin de rajouter d'options.
Globalement OpenSSH a l'habitude de régulièrement changer ses paramètres par défaut pour intégrer les bonnes pratiques de sécurité (tant que ça ne casse pas la compatibilité).
C'était pour que tu finisses sur une note positive l'année 2018 ha ha ;)
Tcho !
Ressemble furieusement à ‘OpenSync’ :p
Clairement, je ne plussoierais pas l'article. Je m'explique :
Du coup, je n'ai même pas lu le reste !
(Juste pour rappel : https://blog.stephane-huc.net/securite/ssh/ssh-configuration-et-cles-plus-securisees#generation-des-cles - écrit déjà en juillet 2017, et j'étais personnellement en retard à l'époque)
Ahahhh, enfin un lien OpenBSD qui pointe son bout du nez ! :D
Même à la dernière semaine de l'année, on y est arrivé ! “Je l'ai eu un jour, je l'ai eu…” (pour plagier un certain slogan pub…) :p
Je suis très impressionné par la simplicité et l'enthousiasme de cette équipe.
De base il ne génère pas de html mais affiche en console le résultat. Du coup tu peux l'utiliser via SSH comme n'importe quelle appli. Tu peux aussi l'utiliser en local genre ssh user@host ‘cat /var/log/nginx/access.log’ | goaccess –log-format=COMBINED
J'utilise plus cette façon de faire, le but est de rendre le programme lancé “insensible” à la fermeture du shell notamment.
Tcho !
Je savais que ça existe… mais sur le moment j'ai trouvé plus pratique, n'ayant jamais fait mumuse avec ‘'xdg-open’‘…
je te remercie pour l'info, je vais regarder cela ;)
C'est quoi ce ‘disown & exit’ que tu rajoutes à chaque fin ?!
Je l'avais bien (com?)pris ;)
Et, pour te rassurer la redirection existe ! :p
J'ai une question peut-être bête pourquoi utiliser editor= à chaque fois et pas xdg-open ?
https://www.blog-libre.org/2017/03/17/la-commande-xdg-open/
Tcho !
C'était pas un reproche, c'était pour aider.
Tcho !
mmmhhhh…. je me demande s'il est utilisable en remote access. Par contre, il faut surement décrire in extenso le format de logs à parser, plutôt que parler en preset
Je sais bien… promis je le referais plus ! :p
C'est une mauvaise idée de changer l'URL après la parution, les liens balancés sur les réseaux sociaux sont faux du coup. Il vaut mieux rester avec l'erreur ou faire une redirection niveau site.
Je dis ça en connaisseur, c'est déjà arrivé plusieurs fois.
Tcho !