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

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

Bonjour,

Je me connecte régulièrement par SSH à des serveurs sous Deb=
ian.
Par habitude, j'interdis sur ces serveurs l'accès au compte root par S=
SH.
J'accède à 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éliorer la sécurité de ces accès et me si=
mplifier 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'o=
pè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'in=
sère
la clé USB dans le PC, je lance SSH agent en lui indiquant qu'il pourr=
a
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 s=
ur 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é-c=
harger
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 sto=
ckées
sur la clé USB, ça ne me semble pas acceptable.

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

<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><di=
v><div><div>Bonjour,<br><br></div>Je me connecte régulièrement pa=
r SSH à des serveurs sous Debian.<br></div>Par habitude, j&#39;interdi=
s sur ces serveurs l&#39;accès au compte root par SSH.<br></div><div>J=
&#39;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 And=
roid.<br></div><div><br></div>Je souhaite améliorer la sécuritÃ=
© de ces accès et me simplifier la vie en changeant mes habitudes.<b=
r><br></div>J&#39;ai pensé à la chose suivante:<br><br></div>- su=
r toutes les machines distantes (sous Debian), l&#39;accès par SSH s&#=
39;opère uniquement par clés SSH,<br></div>- je stocke mes propre=
s clés SSH sur une clé USB (voir plus loin) qui comme mon smartph=
one est toujours avec moi,<br></div>- quand je veux me connecter à une=
machine distante depuis un PC, j&#39;insère la clé USB dans le P=
C, je lance SSH agent en lui indiquant qu&#39;il pourra trouver mes clÃ=
©s sur la clé 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és SSH qui se trouvent sur ma clé USB et la clÃ=
© SSH sur mon smartphone<br></div>- 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&#39;autorise et je rajoute la nouvelle clé SSH.<br=
><br>J&#39;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.<br><br><br></div>=
Mes questions sont nombreuses:<br></div><div>-  Ai-je pensé Ã=
  tout ?<br></div>-  Que choisir comme clé USB ?<br></div>-Â=
  Comment la protéger sans perdre la possibilité de l&#39;utili=
ser sur une machine occasionnelle (*) ?<br></div><div>-  Y-a-t-il une =
astuce particulière (ie une option d&#39;un logiciel) pour conserver l=
a liste des machines sur lesquelles une clé SSH a été copi=
ée afin de ne pas oublier cette machine en cas de répudiation) ?<=
br></div><div>-  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élé-charger PuTTY avant de me connecter et =
ça me semble acceptable. S&#39;il fallait installer des drivers et des=
logiciels, pour utiliser les clés SSH stockées sur la clé U=
SB, ça ne me semble pas acceptable.<br><div><br></div></div>

--001a114196b4d667d0052ff54ae2--
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Grégory Reinbold
Le #26394917
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
Daniel Huhardeaux
Le #26394918
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
S
Le #26394919
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
Olivier
Le #26394941
--001a1140204a7265e2052ff7a38b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Le 8 avril 2016 à 11:31, 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.




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

Bonjour,<br>
</blockquote>
<br></span>
Bonjour<br>
<br>
[...]<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>
autossh a été discuté sur la liste il n&#39;y a pas trè s longtemps. <br>
-- <br>
Daniel<br>
<br>
</font></span></blockquote></div><br></div></div>

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

Le 8 avril 2016 à 11:38, Sébastien NOBILI
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

<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 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>
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: <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. <span class=""><font color="#888888"><br>
Sébastien<br>
<br>
</font></span></blockquote></div><br></div></div>

--001a11c32636f82c6a052ff7c500--
andre_debian
Le #26394943
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é
S
Le #26394948
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
honeyshell
Le #26394949
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.
Grégory Reinbold
Le #26394950
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
Olivier
Le #26394955
--001a11c2a11291232e052ff97cd5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Le 8 avril 2016 à 14:37, honeyshell
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

de passe, pas de connexion sur root, 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. 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--
Publicité
Poster une réponse
Anonyme