Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Conseils sur la sécurisation de ses accès par SSH

26 réponses
Avatar
Olivier
--001a114196b4d667d0052ff54ae2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Bonjour,

Je me connecte r=C3=A9guli=C3=A8rement par SSH =C3=A0 des serveurs sous Deb=
ian.
Par habitude, j'interdis sur ces serveurs l'acc=C3=A8s au compte root par S=
SH.
J'acc=C3=A8de =C3=A0 ces machines depuis un PC sous Debian, mais je peux pl=
us
rarement le faire depuis un PC sous Windows ou un smartphone sous Android.

Je souhaite am=C3=A9liorer la s=C3=A9curit=C3=A9 de ces acc=C3=A8s et me si=
mplifier la vie en
changeant mes habitudes.

J'ai pens=C3=A9 =C3=A0 la chose suivante:

- sur toutes les machines distantes (sous Debian), l'acc=C3=A8s par SSH s'o=
p=C3=A8re
uniquement par cl=C3=A9s SSH,
- je stocke mes propres cl=C3=A9s SSH sur une cl=C3=A9 USB (voir plus loin)=
qui comme
mon smartphone est toujours avec moi,
- quand je veux me connecter =C3=A0 une machine distante depuis un PC, j'in=
s=C3=A8re
la cl=C3=A9 USB dans le PC, je lance SSH agent en lui indiquant qu'il pourr=
a
trouver mes cl=C3=A9s sur la cl=C3=A9 USB
- quand je lance SSH agent, celui-ci me demande un mot de passe
- sur toutes les machines distantes, j'autorise les cl=C3=A9s SSH qui se
trouvent sur ma cl=C3=A9 USB et la cl=C3=A9 SSH sur mon smartphone
- en cas de perte de ma cl=C3=A9 USB ou de mon smartphone, je r=C3=A9pudie =
la cl=C3=A9 SSH
correspondante sur tous les machines qui l'autorise et je rajoute la
nouvelle cl=C3=A9 SSH.

J'utilise ici le terme cl=C3=A9 USB =C3=A0 la fois comme un terme g=C3=A9n=
=C3=A9rique d=C3=A9signant
un appareil portable avec une interface USB, et en pensant aux simples cl=
=C3=A9s
USB du commerce.


Mes questions sont nombreuses:
- Ai-je pens=C3=A9 =C3=A0 tout ?
- Que choisir comme cl=C3=A9 USB ?
- Comment la prot=C3=A9ger sans perdre la possibilit=C3=A9 de l'utiliser s=
ur une
machine occasionnelle (*) ?
- Y-a-t-il une astuce particuli=C3=A8re (ie une option d'un logiciel) pour
conserver la liste des machines sur lesquelles une cl=C3=A9 SSH a =C3=A9t=
=C3=A9 copi=C3=A9e
afin de ne pas oublier cette machine en cas de r=C3=A9pudiation) ?
- Conseils, remarques et suggestions ?

Slts

(*) Il m'arrive souvent, sur une machine occasionnelle, de t=C3=A9l=C3=A9-c=
harger
PuTTY avant de me connecter et =C3=A7a me semble acceptable. S'il fallait
installer des drivers et des logiciels, pour utiliser les cl=C3=A9s SSH sto=
ck=C3=A9es
sur la cl=C3=A9 USB, =C3=A7a ne me semble pas acceptable.

--001a114196b4d667d0052ff54ae2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div><div><div><div><div><div><div><di=
v><div><div>Bonjour,<br><br></div>Je me connecte r=C3=A9guli=C3=A8rement pa=
r SSH =C3=A0 des serveurs sous Debian.<br></div>Par habitude, j&#39;interdi=
s sur ces serveurs l&#39;acc=C3=A8s au compte root par SSH.<br></div><div>J=
&#39;acc=C3=A8de =C3=A0 ces machines depuis un PC sous Debian, mais je peux=
plus rarement le faire depuis un PC sous Windows ou un smartphone sous And=
roid.<br></div><div><br></div>Je souhaite am=C3=A9liorer la s=C3=A9curit=C3=
=A9 de ces acc=C3=A8s et me simplifier la vie en changeant mes habitudes.<b=
r><br></div>J&#39;ai pens=C3=A9 =C3=A0 la chose suivante:<br><br></div>- su=
r toutes les machines distantes (sous Debian), l&#39;acc=C3=A8s par SSH s&#=
39;op=C3=A8re uniquement par cl=C3=A9s SSH,<br></div>- je stocke mes propre=
s cl=C3=A9s SSH sur une cl=C3=A9 USB (voir plus loin) qui comme mon smartph=
one est toujours avec moi,<br></div>- quand je veux me connecter =C3=A0 une=
machine distante depuis un PC, j&#39;ins=C3=A8re la cl=C3=A9 USB dans le P=
C, je lance SSH agent en lui indiquant qu&#39;il pourra trouver mes cl=C3=
=A9s sur la cl=C3=A9 USB<br></div>- quand je lance SSH agent, celui-ci me =
demande un mot de passe<br></div>- sur toutes les machines distantes, j&#39=
;autorise les cl=C3=A9s SSH qui se trouvent sur ma cl=C3=A9 USB et la cl=C3=
=A9 SSH sur mon smartphone<br></div>- en cas de perte de ma cl=C3=A9 USB ou=
de mon smartphone, je r=C3=A9pudie la cl=C3=A9 SSH correspondante sur tous=
les machines qui l&#39;autorise et je rajoute la nouvelle cl=C3=A9 SSH.<br=
><br>J&#39;utilise ici le terme cl=C3=A9 USB =C3=A0 la fois comme un terme =
g=C3=A9n=C3=A9rique d=C3=A9signant un appareil portable avec une interface =
USB, et en pensant aux simples cl=C3=A9s USB du commerce.<br><br><br></div>=
Mes questions sont nombreuses:<br></div><div>-=C2=A0 Ai-je pens=C3=A9 =C3=
=A0 tout ?<br></div>-=C2=A0 Que choisir comme cl=C3=A9 USB ?<br></div>-=C2=
=A0 Comment la prot=C3=A9ger sans perdre la possibilit=C3=A9 de l&#39;utili=
ser sur une machine occasionnelle (*) ?<br></div><div>-=C2=A0 Y-a-t-il une =
astuce particuli=C3=A8re (ie une option d&#39;un logiciel) pour conserver l=
a liste des machines sur lesquelles une cl=C3=A9 SSH a =C3=A9t=C3=A9 copi=
=C3=A9e afin de ne pas oublier cette machine en cas de r=C3=A9pudiation) ?<=
br></div><div>-=C2=A0 Conseils, remarques et suggestions ?<br><br></div><di=
v>Slts<br></div><div><br></div>(*) Il m&#39;arrive souvent, sur une machine=
occasionnelle, de t=C3=A9l=C3=A9-charger PuTTY avant de me connecter et =
=C3=A7a me semble acceptable. S&#39;il fallait installer des drivers et des=
logiciels, pour utiliser les cl=C3=A9s SSH stock=C3=A9es sur la cl=C3=A9 U=
SB, =C3=A7a ne me semble pas acceptable.<br><div><br></div></div>

--001a114196b4d667d0052ff54ae2--

10 réponses

1 2 3
Avatar
Grégory Reinbold
Bonjour,

Pour ce qui est des clés ssh à usages multiples (sur plusieurs
machines), personnellement j'évite. Pour chaque nouvelle machine qui
entre dans mon scope, je créé une nouvelle clé qui lui ai dédié.

Inconvénient : en fonction du parc, tu peux te retrouver avec un grand
nombre de clés, il faut donc veiller à bien les nommer et à laisser un
commentaire pertinent pour identfiier rapidement la machine concernée
[ex. : (domaine).hostname.user]

Avantage : clé perdue, dérobée ou vérolée ? pas de souci, cela n'expose
qu'une machine au maximum et il me suffit de supprimer la clé publique
correspondante dans le fichier authorized_keys

Si ça peut t'aider

Le 08/04/2016 10:50, Olivier a écrit :
Bonjour,

Je me connecte régulièrement par SSH à des serveurs sous Debian.
Par habitude, j'interdis sur ces serveurs l'accès au compte root par SSH.
J'accède à ces machines depuis un PC sous Debian, mais je peux plus
rarement le faire depuis un PC sous Windows ou un smartphone sous Android.

Je souhaite améliorer la sécurité de ces accès et me simplifier la vie
en changeant mes habitudes.

J'ai pensé à la chose suivante:

- sur toutes les machines distantes (sous Debian), l'accès par SSH
s'opère uniquement par clés SSH,
- je stocke mes propres clés SSH sur une clé USB (voir plus loin) qui
comme mon smartphone est toujours avec moi,
- quand je veux me connecter à une machine distante depuis un PC,
j'insère la clé USB dans le PC, je lance SSH agent en lui indiquant
qu'il pourra trouver mes clés sur la clé USB
- quand je lance SSH agent, celui-ci me demande un mot de passe
- sur toutes les machines distantes, j'autorise les clés SSH qui se
trouvent sur ma clé USB et la clé SSH sur mon smartphone
- en cas de perte de ma clé USB ou de mon smartphone, je répudie la
clé SSH correspondante sur tous les machines qui l'autorise et je
rajoute la nouvelle clé SSH.

J'utilise ici le terme clé USB à la fois comme un terme générique
désignant un appareil portable avec une interface USB, et en pensant
aux simples clés USB du commerce.


Mes questions sont nombreuses:
- Ai-je pensé à tout ?
- Que choisir comme clé USB ?
- Comment la protéger sans perdre la possibilité de l'utiliser sur
une machine occasionnelle (*) ?
- Y-a-t-il une astuce particulière (ie une option d'un logiciel) pour
conserver la liste des machines sur lesquelles une clé SSH a été
copiée afin de ne pas oublier cette machine en cas de répudiation) ?
- Conseils, remarques et suggestions ?

Slts

(*) Il m'arrive souvent, sur une machine occasionnelle, de
télé-charger PuTTY avant de me connecter et ça me semble acceptable.
S'il fallait installer des drivers et des logiciels, pour utiliser les
clés SSH stockées sur la clé USB, ça ne me semble pas acceptable.




--
Grégory Reinbold
Avatar
Daniel Huhardeaux
Le 08/04/2016 10:50, Olivier a écrit :
Bonjour,



Bonjour

[...]
- Conseils, remarques et suggestions ?



. écouter sur un port différent du 22
. utiliser autossh: les clients se connectent sur une seule machine.
Cela règle le problème soulevé par Gregory dans sa réponse, une seule
clé. Si une machine est à bannir et que tu n'y a plus accès, une rle de
firewall suffit.

autossh a été discuté sur la liste il n'y a pas très longtemps.

--
Daniel
Avatar
S
Bonjour,

Le vendredi 08 avril 2016 à 10:50, Olivier a écrit :
- je stocke mes propres clés SSH sur une clé USB (voir plus loin) qui comme
mon smartphone est toujours avec moi,



[...]

- en cas de perte de ma clé USB ou de mon smartphone, je répudie la clé SSH
correspondante sur tous les machines qui l'autorise et je rajoute la
nouvelle clé SSH.



Personnellement, je chiffrerais la clé, ça fait une sécurité de plus (ce qui
n’empêche pas de révoquer les clés en cas de perte).

Par contre, ça impose de pouvoir déchiffrer sur différents types de systèmes. À
l’époque où je me souciais de ce genre de préoccupations, j’utilisais
« truecrypt », je ne sais pas si c’est encore une bonne piste. Tu trouveras
peut-être des infos intéressantes là [1].

1: http://arstechnica.com/civis/viewtopic.php?t45367

(*) Il m'arrive souvent, sur une machine occasionnelle, de télé-charger
PuTTY avant de me connecter et ça me semble acceptable. S'il fallait
installer des drivers et des logiciels, pour utiliser les clés SSH stockées
sur la clé USB, ça ne me semble pas acceptable.



Si tu crées deux partitions (une en clair et l’autre chiffrée), tu pourra te
balader avec les différents outils nécessaires pour les différents systèmes.

Il me semble me souvenir qu’à une époque, Windows n’était pas capable de gérer
plusieurs partitions sur une clé USB, à vérifier.

Sébastien
Avatar
Olivier
--001a1140204a7265e2052ff7a38b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Le 8 avril 2016 à 11:31, Daniel Huhardeaux a à ©crit :

Le 08/04/2016 10:50, Olivier a écrit :

Bonjour,




Bonjour

[...]
- Conseils, remarques et suggestions ?




. écouter sur un port différent du 22
. utiliser autossh: les clients se connectent sur une seule machine. Cela
règle le problème soulevé par Gregory dans sa réponse , une seule clé. Si
une machine est à bannir et que tu n'y a plus accès, une rle de firewall
suffit.




L'idée de transiter par un intermédiaire pour faciliter la gestio n des
machines distantes est très intéressante, d'autant qu'elle colle assez bien
à la centralisation des moyens de télé-maintenance.

Un outil comme Gnome SSH Tunnel Manager (que je ne connais pas) devrait
sans doute être très utile dans cet environnement pour palier à   l'ajout
d'intermédiaires.





autossh a été discuté sur la liste il n'y a pas très longtemps.




autossh serait si j'ai bien compris, une façon d'implémenter la
télé-maintenance avec l'avantage d'utiliser des connexions sortan tes plus
rarement contrôlées que les connexions spécifiques comme une connexion
OpenVPN, par exemple.

Merci beaucoup de l'info.



--
Daniel





--001a1140204a7265e2052ff7a38b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quo te">Le 8 avril 2016 à 11:31, Daniel Huhardeaux <span dir="ltr">&lt;< a href="mailto:" target="_blank"></ a>&gt;</span> a écrit :<br><blockquote class="gmail_quote" style=" margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef t:1ex"><span class="">Le 08/04/2016 10:50, Olivier a écrit :<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border- left:1px solid rgb(204,204,204);padding-left:1ex">
Bonjour,<br>
</blockquote>
<br></span>
Bonjour<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border- left:1px solid rgb(204,204,204);padding-left:1ex">
[...]<span class=""><br>
-  Conseils, remarques et suggestions ?<br>
</span></blockquote>
<br>
. écouter sur un port différent du 22<br>
. utiliser autossh: les clients se connectent sur une seule machine. Cela r ègle le problème soulevé par Gregory dans sa réponse, u ne seule clé. Si une machine est à bannir et que tu n&#39;y a plu s accès, une rle de firewall suffit.<br></blockquote><div><br></div><d iv>L&#39;idée de transiter par un intermédiaire pour faciliter la gestion des machines distantes est très intéressante, d&#39;auta nt qu&#39;elle colle assez bien à la centralisation des moyens de tà ©lé-maintenance.<br><br></div><div>Un outil comme Gnome SSH Tunnel M anager (que je ne connais pas) devrait sans doute être très utile dans cet environnement pour palier à l&#39;ajout d&#39;intermédi aires.<br><br></div><div><br></div><div> </div><blockquote class="gm ail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204, 204,204);padding-left:1ex">
<br>
autossh a été discuté sur la liste il n&#39;y a pas trè s longtemps.<span class=""><font color="#888888"><br></font></span></bl ockquote><div><br>autossh serait si j&#39;ai bien compris, une façon d &#39;implémenter la télé-maintenance avec l&#39;avantage d&# 39;utiliser des connexions sortantes plus rarement contrôlées que les connexions spécifiques comme une connexion OpenVPN, par exemple.< br><br></div><div>Merci beaucoup de l&#39;info.<br></div><div> </div>< blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-l eft:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><font col or="#888888">
<br>
-- <br>
Daniel<br>
<br>
</font></span></blockquote></div><br></div></div>

--001a1140204a7265e2052ff7a38b--
Avatar
Olivier
--001a11c32636f82c6a052ff7c500
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Le 8 avril 2016 à 11:38, Sébastien NOBILI a écrit :

Bonjour,

Le vendredi 08 avril 2016 à 10:50, Olivier a écrit :
> - je stocke mes propres clés SSH sur une clé USB (voir plus l oin) qui
comme
> mon smartphone est toujours avec moi,

[...]

> - en cas de perte de ma clé USB ou de mon smartphone, je répu die la clé
SSH
> correspondante sur tous les machines qui l'autorise et je rajoute la
> nouvelle clé SSH.

Personnellement, je chiffrerais la clé, ça fait une sécuri té de plus (ce
qui
n’empêche pas de révoquer les clés en cas de perte ).




Très intéressant !
J'ai trouvé [1].
Comment copie-t-on une clé chiffrée ? On la colle simplement dans
authorized_keys ?

[1]
https://martin.kleppmann.com/2013/05/24/improving-security-of-ssh-private-k eys.html


Par contre, ça impose de pouvoir déchiffrer sur différents types de
systèmes. À
l’époque où je me souciais de ce genre de préoccup ations, j’utilisais
« truecrypt », je ne sais pas si c’est encore une bonne piste. Tu trouveras
peut-être des infos intéressantes là [1].

1: http://arstechnica.com/civis/viewtopic.php?t45367

> (*) Il m'arrive souvent, sur une machine occasionnelle, de télà ©-charger
> PuTTY avant de me connecter et ça me semble acceptable. S'il falla it
> installer des drivers et des logiciels, pour utiliser les clés SSH
stockées
> sur la clé USB, ça ne me semble pas acceptable.

Si tu crées deux partitions (une en clair et l’autre chiffr ée), tu pourra
te
balader avec les différents outils nécessaires pour les diffà ©rents
systèmes.

Il me semble me souvenir qu’à une époque, Windows n⠀™Ã©tait pas capable de
gérer
plusieurs partitions sur une clé USB, à vérifier.





Si j'ai bien compris [2], on ne devrait pas avoir besoin d'autre chose que
PuTTY et la clé USB, ce qui correspond à mon cahier des charges.
À tester ASAP.

[2]
https://support.rackspace.com/how-to/logging-in-with-an-ssh-private-key-on- windows/



Sébastien





--001a11c32636f82c6a052ff7c500
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quo te">Le 8 avril 2016 à 11:38, Sébastien NOBILI <span dir="ltr">& lt;<a href="mailto:" target="_blank">sebnewsletter @free.fr</a>&gt;</span> a écrit :<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p adding-left:1ex">Bonjour,<br>
<span class=""><br>
Le vendredi 08 avril 2016 à 10:50, Olivier a écrit :<br>
&gt; - je stocke mes propres clés SSH sur une clé USB (voir plus loin) qui comme<br>
&gt; mon smartphone est toujours avec moi,<br>
<br>
</span>[...]<br>
<span class=""><br>
&gt; - en cas de perte de ma clé USB ou de mon smartphone, je rép udie la clé SSH<br>
&gt; correspondante sur tous les machines qui l&#39;autorise et je rajoute la<br>
&gt; nouvelle clé SSH.<br>
<br>
</span>Personnellement, je chiffrerais la clé, ça fait une sà ©curité de plus (ce qui<br>
n’empêche pas de révoquer les clés en cas de perte). <br></blockquote><div><br></div><div>Très intéressant !<br></div> <div>J&#39;ai trouvé [1].<br></div><div>Comment copie-t-on une clà © chiffrée ? On la colle simplement dans authorized_keys ?<br></div> <div><br>[1] <a href="https://martin.kleppmann.com/2013/05/24/improving-s ecurity-of-ssh-private-keys.html">https://martin.kleppmann.com/2013/05/24/i mproving-security-of-ssh-private-keys.html</a><br></div><blockquote class ="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rg b(204,204,204);padding-left:1ex">
<br>
Par contre, ça impose de pouvoir déchiffrer sur différents t ypes de systèmes. À<br>
l’époque où je me souciais de ce genre de préoccupat ions, j’utilisais<br>
« truecrypt », je ne sais pas si c’est encore u ne bonne piste. Tu trouveras<br>
peut-être des infos intéressantes là [1].<br>
<br>
    1: <a href="http://arstechnica.com/civis/viewtopic.php?t= 1245367" rel="noreferrer" target="_blank">http://arstechnica.com/civis/ viewtopic.php?t45367</a><br>
<span class=""><br>
&gt; (*) Il m&#39;arrive souvent, sur une machine occasionnelle, de té lé-charger<br>
&gt; PuTTY avant de me connecter et ça me semble acceptable. S&#39;il fallait<br>
&gt; installer des drivers et des logiciels, pour utiliser les clés SS H stockées<br>
&gt; sur la clé USB, ça ne me semble pas acceptable.<br>
<br>
</span>Si tu crées deux partitions (une en clair et l’autre ch iffrée), tu pourra te<br>
balader avec les différents outils nécessaires pour les diffà ©rents systèmes.<br>
<br>
Il me semble me souvenir qu’à une époque, Windows n†™Ã©tait pas capable de gérer<br>
plusieurs partitions sur une clé USB, à vérifier.<br></block quote><div><br><br>Si j&#39;ai bien compris [2], on ne devrait pas avoir be soin d&#39;autre chose que PuTTY et la clé USB, ce qui correspond à   mon cahier des charges.<br>À tester ASAP.<br></div><div><br>[2] <a href="https://support.rackspace.com/how-to/logging-in-with-an-ssh-privat e-key-on-windows/">https://support.rackspace.com/how-to/logging-in-with-an- ssh-private-key-on-windows/</a><br> </div><blockquote class="gmail_q uote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2 04);padding-left:1ex">
<span class=""><font color="#888888"><br>
Sébastien<br>
<br>
</font></span></blockquote></div><br></div></div>

--001a11c32636f82c6a052ff7c500--
Avatar
andre_debian
On Friday 08 April 2016 11:20:41 Grégory Reinbold wrote:
Pour ce qui est des clés ssh à usages multiples (sur plusieurs
machines), personnellement j'évite. Pour chaque nouvelle machine qui
entre dans mon scope, je créé une nouvelle clé qui lui ai dédié.
Inconvénient : en fonction du parc, tu peux te retrouver avec un gra nd
nombre de clés, il faut donc veiller à bien les nommer et à   laisser un
commentaire pertinent pour identfiier rapidement la machine concerné e
[ex. : (domaine).hostname.user]
Avantage : clé perdue, dérobée ou vérolée ? pas de souci, cela n'expose
qu'une machine au maximum et il me suffit de supprimer la clé publiq ue
correspondante dans le fichier authorized_keys
Si ça peut t'aider



Les connexions SSH avec clés publique et privées, restent trà ¨s sécurisées,
qui peut se procurer les deux clés, sauf si on a perdu la clé USB les
contenant.
Il faut modifier l'éternel port 22 par un autre,
n'autoriser qu'une à deux personnes à se connecter au serveur,
n'autoriser que la connexion par clés,
ne pas autoriser le login root...
Dès lors, on peut dormir tranquille.

André
Avatar
S
Le vendredi 08 avril 2016 à 13:48, Olivier a écrit :
Comment copie-t-on une clé chiffrée ? On la colle simplement dans
authorized_keys ?



En fait, je me suis mal exprimé…

Je ne parlais pas de chiffrer les clés SSH, mais de chiffrer la clé USB. L’idée
c’est simplement de vivre un peu mieux avec le risque de perte. Si tu perds ta
clé USB, tu sais que celui qui la trouvera n’aura sûrement pas les compétences
ni l’envie d’en exploiter le contenu et que, si tu tombes sur quelqu’un qui les
a (compétences, envie), ça te laisse un délai supplémentaire pour révoquer les
clés SSH (le temps qu’il casse ta crypto).

Sébastien
Avatar
honeyshell
le classique : fail2ban sur les serveurs , ssh avec clef RSA, phrase
de passe, pas de connexion sur root, autre port que 22 (sup à 10000),
le tout sur une clef usb bootable encryptée.

Si tu utilises Putty tu as du te rendre compte que putty ne gère pas
la phrase de passe. Il faut aussi générer les clefs via putty pou r les
exporter sur le serveur. L'encryptage est moins poussé.
Je ne suis donc pas fan de putty du fait de ces faiblesses.
Avatar
Grégory Reinbold
Oui et si tu venais à perdre cette clé USB ? Toutes tes machines sont
menacées par tes deux seules clés :)

A méditer...

Le 08/04/2016 13:58, a écrit :
On Friday 08 April 2016 11:20:41 Grégory Reinbold wrote:
Pour ce qui est des clés ssh à usages multiples (sur plusieurs
machines), personnellement j'évite. Pour chaque nouvelle machine qui
entre dans mon scope, je créé une nouvelle clé qui lui ai dédié.
Inconvénient : en fonction du parc, tu peux te retrouver avec un grand
nombre de clés, il faut donc veiller à bien les nommer et à laisser un
commentaire pertinent pour identfiier rapidement la machine concernée
[ex. : (domaine).hostname.user]
Avantage : clé perdue, dérobée ou vérolée ? pas de souci, cela n'expose
qu'une machine au maximum et il me suffit de supprimer la clé publique
correspondante dans le fichier authorized_keys
Si ça peut t'aider


Les connexions SSH avec clés publique et privées, restent très sécurisées,
qui peut se procurer les deux clés, sauf si on a perdu la clé USB les
contenant.
Il faut modifier l'éternel port 22 par un autre,
n'autoriser qu'une à deux personnes à se connecter au serveur,
n'autoriser que la connexion par clés,
ne pas autoriser le login root...
Dès lors, on peut dormir tranquille.

André




--
Grégory Reinbold
Avatar
Olivier
--001a11c2a11291232e052ff97cd5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Le 8 avril 2016 à 14:37, honeyshell a à ©crit :

le classique : fail2ban sur les serveurs , ssh avec clef RSA, phrase
de passe, pas de connexion sur root,



Sur ce point précis (connexion à root), je l'autoriserai unique p ar clé
comme pour tous les autres utilisateurs, d'ailleurs.
C'est le paramétrage par défaut avec Jessie et ça me parait finalement
suffisant et bien pratique.


autre port que 22 (sup à 10000),
le tout sur une clef usb bootable encryptée.

Si tu utilises Putty tu as du te rendre compte que putty ne gère pas
la phrase de passe.



Non, je ne savais pas car je n'ai pas encore essayé avec la phrase de passe.
C'est bien contrariant car l'idée me plaisait bien.

Que penser de [3] ?
Est-ce quelque chose qui ne marche que sur PuTTY/Linux et par sur
PuTTY/Windows ?
[3] http://linux-sxs.org/networking/openssh.putty.html



Il faut aussi générer les clefs via putty pour les
exporter sur le serveur. L'encryptage est moins poussé.
Je ne suis donc pas fan de putty du fait de ces faiblesses.





--001a11c2a11291232e052ff97cd5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quo te">Le 8 avril 2016 à 14:37, honeyshell <span dir="ltr">&lt;<a href ="mailto:" target="_blank"> ll.com</a>&gt;</span> a écrit :<br><blockquote class="gmail_quote" s tyle="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad ding-left:1ex">le classique : fail2ban sur les serveurs , ssh avec clef RSA , phrase<br>
de passe, pas de connexion sur root,</blockquote><div>Sur ce point pré cis (connexion à root), je l&#39;autoriserai unique par clé comme pour tous les autres utilisateurs, d&#39;ailleurs.<br></div><div>C&#39;est le paramétrage par défaut avec Jessie et ça me parait final ement suffisant et bien pratique.<br></div><div> </div><blockquote cla ss="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> autre port que 22 (sup à 10000),<b r>
le tout sur une clef usb bootable encryptée.<br>
<br>
Si tu utilises Putty tu as du te rendre compte que putty ne gère pas<b r>
la phrase de passe.</blockquote><div>Non, je ne savais pas car je n&#39;ai pas encore essayé avec la phrase de passe.<br></div><div>C&#39;est bie n contrariant car l&#39;idée me plaisait bien.<br><br></div><div>Que p enser de [3] ?<br>Est-ce quelque chose qui ne marche que sur PuTTY/Linux et par sur PuTTY/Windows ?<br>[3] <a href="http://linux-sxs.org/networking/ openssh.putty.html">http://linux-sxs.org/networking/openssh.putty.html</a>< br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa dding-left:1ex"> Il faut aussi générer les clefs via putty pour l es<br>
exporter sur le serveur. L&#39;encryptage est moins poussé.<br>
Je ne suis donc pas fan de putty du fait de ces faiblesses.<br>
<br>
</blockquote></div><br></div></div>

--001a11c2a11291232e052ff97cd5--
1 2 3