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
Olivier
--001a1140204ac29f71052ff99117
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Le 8 avril 2016 à 14:59, Grégory Reinbold a écrit :

Oui et si tu venais à perdre cette clé USB ? Toutes tes machine s sont
menacées par tes deux seules clés :)

A méditer...




Je ne suis pas sûr d'avoir compris cette remarque.

Pour ma part, je pensais copier 2 ou 3 clés publiques (toujours les m êmes)
sur tous les machines distantes et d'avoir au moins 2 moyens d'accès ( mon
smartphone et un PC avec sa clé USB)





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 plusieur s
machines), personnellement j'évite. Pour chaque nouvelle machine q ui
entre dans mon scope, je créé une nouvelle clé qui lui a i dédié.
Inconvénient : en fonction du parc, tu peux te retrouver avec un g rand
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 ? pa s de souci, cela n'expose
qu'une machine au maximum et il me suffit de supprimer la clé publ ique
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





--001a1140204ac29f71052ff99117
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:59, Grégory Reinbold <span dir="ltr">& lt;<a href="mailto:" target="_blank"> fr</a>&gt;</span> a écrit :<br><blockquote class="gmail_quote" style ="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Oui et s i tu venais à perdre cette clé USB ? Toutes tes machines sont men acées par tes deux seules clés :)<br>
<br>
A méditer...</blockquote><div><br></div><div>Je ne suis pas sûr d &#39;avoir compris cette remarque.<br><br></div><div>Pour ma part, je pensa is copier 2 ou 3 clés publiques (toujours les mêmes) sur tous les machines distantes et d&#39;avoir au moins 2 moyens d&#39;accès (mon smartphone et un PC avec sa clé USB)<br></div><div><br> <br></div ><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1 px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br >
<br>
Le 08/04/2016 13:58, <a href="mailto:" target ="_blank"></a> a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1p x #ccc solid;padding-left:1ex">
On Friday 08 April 2016 11:20:41 Grégory Reinbold wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1p x #ccc solid;padding-left:1ex">
Pour ce qui est des clés ssh à usages multiples (sur plusieurs<br >
machines), personnellement j&#39;évite. Pour chaque nouvelle machine q ui<br>
entre dans mon scope, je créé une nouvelle clé qui lui ai d édié.<br>
Inconvénient : en fonction du parc, tu peux te retrouver avec un grand <br>
nombre de clés, il faut donc veiller à bien les nommer et à laisser un<br>
commentaire pertinent pour identfiier rapidement la machine concernée< br>
[ex. : (domaine).hostname.user]<br>
Avantage : clé perdue, dérobée ou vérolée ? pas de souci, cela n&#39;expose<br>
qu&#39;une machine au maximum et il me suffit de supprimer la clé publ ique<br>
correspondante dans le fichier authorized_keys<br>
Si ça peut t&#39;aider<br>
</blockquote>
Les connexions SSH avec clés publique et privées, restent trà ¨s sécurisées,<br>
qui peut se procurer les deux clés, sauf si on a perdu la clé USB les<br>
contenant.<br>
Il faut modifier l&#39;éternel port 22 par un autre,<br>
n&#39;autoriser qu&#39;une à deux personnes à se connecter au ser veur,<br>
n&#39;autoriser que la connexion par clés,<br>
ne pas autoriser le login root...<br>
Dès lors, on peut dormir tranquille.<br>
<br>
André<br>
<br>
</blockquote>
<br></div></div><span class="HOEnZb"><font color="#888888">
-- <br>
Grégory Reinbold<br>
<br>
</font></span></blockquote></div><br></div></div>

--001a1140204ac29f71052ff99117--
Avatar
honeyshell
Oui et si tu venais à perdre cette clé USB ? Toutes tes machine s sont menacées par tes deux seules clés :)





Mieux vaut-il un seul moyen sécurisé (crypté comme je l'ai d it) que
l'on perde, ou multiplier les moyens de connexions (voir un ordi
familliale ou pro sous surveillance ou keyloger avec plusieurs
utilisateurs) en ssh, ce qui reviendrait à ne plus suivre
l'intégrétité de la sécurité mise en place?
SSH est une chose, ainsi que la sécurité sur le serveur cible, ma is
celle mise en place lors de l'utilisation de SSH depuis le client est
en générale le point faible.
Après toute est question de paranoia pour cacher quel type de donnà ©es?

on est encore vendredi?
Avatar
kaliderus
2 pistes de réflexion :
- Ne pas exposer de services ssh tant que tu n'en a pas besoin en
utilisant le port knocking.
- Utiliser des sous-clés (à vérifier car je ne suis pas expe rt dans le
domaine, mais je crois qu'il est possible de tout chiffrer à partir
d'un seul emplacement)

Bon courage

Le 8 avril 2016 à 22:43, honeyshell a à ©crit :
Oui et si tu venais à perdre cette clé USB ? Toutes tes machin es sont menacées par tes deux seules clés :)





Mieux vaut-il un seul moyen sécurisé (crypté comme je l'ai dit) que
l'on perde, ou multiplier les moyens de connexions (voir un ordi
familliale ou pro sous surveillance ou keyloger avec plusieurs
utilisateurs) en ssh, ce qui reviendrait à ne plus suivre
l'intégrétité de la sécurité mise en place?
SSH est une chose, ainsi que la sécurité sur le serveur cible, mais
celle mise en place lors de l'utilisation de SSH depuis le client est
en générale le point faible.
Après toute est question de paranoia pour cacher quel type de donn ées?

on est encore vendredi?

Avatar
David Demonchy
Je rejoins Grégory

1 machine 1 jeu de clé.
C'est à dire que chaque serveur à sa clé, mais aussi chaque client (pc
perso, boulot et smartphone)
Pour résumé, j'ai 3 jeux de clés par machine qui nécess ite une connexion ssh.
Si 2 machines peuvent communiquer entre elles, elles ont aussi leurs
jeu de clés.
Le tout avec des passphrases différentes.
J'ai supprimé les accès root
Et bien sur le port 22 est changé.
Pour finir un fw

Si un jour je perds le tout, le temps de casser les clés une à un e,
j'aurais le temps de révoquer le tout.

Mon seul souci retenir les passphrases....
Après est ce la bonne méthode, je ne sais pas, mais elle me parai t correct.

si on regarde ce que fait OVH pour les maintenances. ils sont loin de
s'embêter avec ça.
Ils ont 1 clé pour tous les serveurs, avec un accès root sur le p ort 22.



--
David DEMONCHY
@fusco_fr



Le 9 avril 2016 à 11:38, Grégory Reinbold a écrit :
La réponse à ta question réside dans ta réponse.

Tout est question de choix, de confort, de praticité et de connaissa nce.

Je ne suis pas un expert en sécurité et je ne prétend pas l'être. Mon niveau
de connaissance dans ce domaine est limité, mais me semble suffisant pour
limiter le risque.

Ma remarque porte sur le sujet d'avoir 2 ou 3 clés publiques pour TO UTES les
machines. Exemple tu gères un parc de 80 machines avec 2 ou 3 clà ©s sur un
support USB, portable, CD ou ce que tu veux.

Si par malheur tu perds ce support contenant ces clés, tu perds les clés
d'accès à TOUT ton parc. En d'autres termes, c'est comme si tu avais 10
résidences secondaires et que tu conserves les clés de TOUTES t es résidences
sur le même trousseau. Cela ne t'effraye pas ?

C'est tout :)


Le 08/04/2016 15:57, Olivier a écrit :



Le 8 avril 2016 à 14:59, Grégory Reinbold a écrit :

Oui et si tu venais à perdre cette clé USB ? Toutes tes machin es sont
menacées par tes deux seules clés :)

A méditer...




Je ne suis pas sûr d'avoir compris cette remarque.

Pour ma part, je pensais copier 2 ou 3 clés publiques (toujours les mêmes)
sur tous les machines distantes et d'avoir au moins 2 moyens d'accès (mon
smartphone et un PC avec sa clé USB)





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 plusieu rs
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 ? p as de souci, cela n'expose
qu'une machine au maximum et il me suffit de supprimer la clé pub lique
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





--
Grégory Reinbold
Avatar
Francois Lafont
Bonsoir,

Perso, voici comment je fais. Je ne sais pas si bien comme il faut ou non. Si certains ont des remarques, je suis preneur bien sûr.

Sur les serveurs que j'administre, le mot de passe root existe mais il fait dans les ~30 caractères et je ne l'utilise jamais. De toute façon la connexion en tant que root via ssh est impossible (PermitRootLogin false). C'est juste un mot de passe spécial coup dur ;). Ensuite, tout passe par des paires de clés ssh. On va dire que j'ai globalement 2 machines (une chez moi et une à mon travail) avec chacun sa paire de clés ssh et les clés publiques sont déployées sur les serveurs au niveau de root et d'un compte flaf qui est sudo (je reviens sur ce point ci-dessous).

La chose qui me semble _absolument_ indispensable pour ce type de clés (ie utilisées par un humain, en l'occurrence moi-même, et pas dans un script non interactif), c'est une bonne passphrase sur chaque chaque clés privées. Pour ce type de clés, je pense que c'est vraiment imprudent de ne pas avoir de passphrase. Ensuite, avoir un agent ssh qui tourne sur sa machine de travail pour n'avoir à saisir la passphrase qu'une seule fois à chaque début de session me semble un _excellent_ compris entre sécurité et commodité.

Je sauvegarde quelque part au chaud mes 2 paires de clés ssh.

Enfin, et c'est un point important je pense, les clés publiques sur les serveurs sont déployées via un logiciel de gestionnaire de configuration (en l'occurrence Puppet). Si jamais je me fait piquer une paire de clés ssh, le temps que le pirate arrive à me casser la passphrase, je peux supprimer les clés publiques des serveurs et en redéployer une nouvelle en une dizaine de minutes.

Voilà.

--
François Lafont
Avatar
honeyshell
--001a113557a0e9e5ac05301f8042
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Je pense que la question sur l'utilisation des clefs ssh à bien fait s on
tour. Chacun pourra prendre la méthode qui lui semble la plus commode et
sécuritaire en fonction de l'importance des serveurs administrés.

Une question reste en suspent: quelle techno avez vous mis en place pour
être alerté d'une intrusion vi ssh avant que le vole d'informatio ns ne
commence?

Bon dimanche à tous :-)

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

<p dir="ltr">Je pense que la question sur l&#39;utilisation des clefs ssh à bien fait son tour. Chacun pourra prendre la méthode qui lui s emble la plus commode et sécuritaire en fonction de l&#39;importance d es serveurs administrés.</p>
<p dir="ltr">Une question reste en suspent: quelle techno avez vous mis e n place pour être alerté d&#39;une intrusion vi ssh avant que le vole d&#39;informations ne commence?</p>
<p dir="ltr">Bon dimanche à tous :-)</p>

--001a113557a0e9e5ac05301f8042--
Avatar
Grégory Reinbold
C'est une bonne question et j'avoue que perso je n'ai rien mis en place.
J'imagine mal le jour où mes accès ssh seraient corrompus et pourtant,
cela peut arriver.

Tu as des suggestions de solution pour détecter l'intrusion ?

Bonne fin de dimanche -_-

Le 10/04/2016 13:12, honeyshell a écrit :

Je pense que la question sur l'utilisation des clefs ssh à bien fait
son tour. Chacun pourra prendre la méthode qui lui semble la plus
commode et sécuritaire en fonction de l'importance des serveurs
administrés.

Une question reste en suspent: quelle techno avez vous mis en place
pour être alerté d'une intrusion vi ssh avant que le vole
d'informations ne commence?

Bon dimanche à tous :-)




--
Grégory Reinbold
Avatar
Yves Rutschle
On Fri, Apr 08, 2016 at 02:37:56PM +0200, honeyshell wrote:
Si tu utilises Putty tu as du te rendre compte que putty ne gère pas
la phrase de passe.



Bah si, y'a même un PAGENT.EXE qui est un agent SSH pour
Windows...

Y.
Avatar
Francois Lafont
On 10/04/2016 19:35, Grégory Reinbold wrote:

C'est une bonne question et j'avoue que perso je n'ai rien mis en place.



Tout pareil.

À partir du moment où on se fait piquer sa clé privée, comment un serveur pourrait-il détecter qu'une connexion ssh est illicite alors que justement le contrat est "seul le détenteur de la clé privée pourra se connecter" ? Je serais curieux d'avoir des infos sur tout ça.

--
François Lafont
Avatar
Vincent Lefevre
On 2016-04-08 14:26:03 +0200, Sébastien NOBILI wrote:
Je ne parlais pas de chiffrer les clés SSH, mais de chiffrer la clé USB.



Quel est l'intérêt de chiffrer la clé USB alors que la clé SSH est
déjà chiffrée en standard (de manière optionnelle, mais je suppose
que l'utilisateur a choisi une passphrase non vide)?

--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
1 2 3