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.
<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'interdi=
s sur ces serveurs l'acc=C3=A8s au compte root par SSH.<br></div><div>J=
'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'ai pens=C3=A9 =C3=A0 la chose suivante:<br><br></div>- su=
r toutes les machines distantes (sous Debian), l'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'ins=C3=A8re la cl=C3=A9 USB dans le P=
C, je lance SSH agent en lui indiquant qu'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'=
;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'autorise et je rajoute la nouvelle cl=C3=A9 SSH.<br=
><br>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.<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'utili=
ser sur une machine occasionnelle (*) ?<br></div><div>-=C2=A0 Y-a-t-il une =
astuce particuli=C3=A8re (ie une option d'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'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'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>
On 2016-04-09 18:45:36 +0200, David Demonchy wrote:
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écessite une connexion ssh. Si 2 machines peuvent communiquer entre elles, elles ont aussi leurs jeu de clés.
Tu as un jeu de clés pour chaque couple (client,serveur)???
On 2016-04-09 18:45:36 +0200, David Demonchy wrote:
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écessite une connexion ssh.
Si 2 machines peuvent communiquer entre elles, elles ont aussi leurs
jeu de clés.
Tu as un jeu de clés pour chaque couple (client,serveur)???
On 2016-04-09 18:45:36 +0200, David Demonchy wrote:
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écessite une connexion ssh. Si 2 machines peuvent communiquer entre elles, elles ont aussi leurs jeu de clés.
Tu as un jeu de clés pour chaque couple (client,serveur)???
Le lundi 11 avril 2016 à 12:38, Vincent Lefevre a écrit :
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)?
Présenté comme ça, ça n’a en effet aucun intérêt, mais ça peut en prendre si : — pas de passphrase (ok, pas forcément top, mais tellement pratique), — la clé contient d’autres données en clair (ce qui est mon cas, d’où ma remarque, mais on sort un peu du sujet initial).
Sébastien
Le lundi 11 avril 2016 à 12:38, Vincent Lefevre a écrit :
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)?
Présenté comme ça, ça n’a en effet aucun intérêt, mais ça peut en prendre si :
— pas de passphrase (ok, pas forcément top, mais tellement pratique),
— la clé contient d’autres données en clair (ce qui est mon cas, d’où ma
remarque, mais on sort un peu du sujet initial).
Le lundi 11 avril 2016 à 12:38, Vincent Lefevre a écrit :
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)?
Présenté comme ça, ça n’a en effet aucun intérêt, mais ça peut en prendre si : — pas de passphrase (ok, pas forcément top, mais tellement pratique), — la clé contient d’autres données en clair (ce qui est mon cas, d’où ma remarque, mais on sort un peu du sujet initial).
Si on suppose qu'en tant qu'administrateur, les opérations à effectuer à distance sur une machine demandent très souvent les privilèges de root, selon cette méthode, il faut se connecter par clé en tant qu'un utilisateur lamda, puis escalader en tant que root.
C'est ça ou lancer des commandes avec sudo. Chez nous, l'accès root via ssh n'est pas possible... avec un mot de passe (de toute façon celui-ci fait dans les 30 caractères environ).
Au passage, je m'étais planté dans mon message précédent, ce n'est pas "PermitRootLogin false" qu'on a mais "PermitRootLogin without-password" ce qui veut donc dire que :
a) une connexion "ssh root" est impossible via son mot de passe; b) une connexion "ssh root" est possible via une clé ssh.
Ceci étant, le cas b) n'est pas utilisé chez nous car nous ne déployons pas (en vérité on l'a fait mais on le fait plus désormais) de clé publique ssh dans /root/.ssh/authorized_keys.
Donc oui, en effet, on se connecte en ssh avec notre compte perso (qui possède un mot de passe qu'on ne saisit jamais car on utilise notre clé ssh) et ce compte est en effet « sudo » (pour les admins).
Pour cette escalade, dois-tu saisir le mot de passe de root (commande su) ou utilises-tu de préférence sudo ?
On utilise sudo et on a configuré sudo (via notre gestionnaire de conf) pour qu'on (les admins) puisse lancer "sudo cmd" sans demande de mot de passe _sauf_ dans le cas où la commande est "su" elle-même. Ceci étant, je crois bien que cette petite exception avec "su" est plus cosmétique qu'autre chose. ;)
Dans ce dernier cas (sudo) comment est gérée la saisie du mot de passe ( NOPASSWORD ? saisie du mot de passe ? ...)
NOPASSWORD donc modulo la petite exception avec la commande su.
-- François Lafont
Hello,
On 11/04/2016 17:09, Olivier wrote:
Si on suppose qu'en tant qu'administrateur, les opérations à effectuer à
distance sur une machine demandent très souvent les privilèges de root,
selon cette méthode, il faut se connecter par clé en tant qu'un utilisateur
lamda, puis escalader en tant que root.
C'est ça ou lancer des commandes avec sudo. Chez nous, l'accès root via ssh
n'est pas possible... avec un mot de passe (de toute façon celui-ci fait dans
les 30 caractères environ).
Au passage, je m'étais planté dans mon message précédent, ce n'est pas
"PermitRootLogin false" qu'on a mais "PermitRootLogin without-password" ce
qui veut donc dire que :
a) une connexion "ssh root" est impossible via son mot de passe;
b) une connexion "ssh root" est possible via une clé ssh.
Ceci étant, le cas b) n'est pas utilisé chez nous car nous ne déployons pas
(en vérité on l'a fait mais on le fait plus désormais) de clé publique ssh
dans /root/.ssh/authorized_keys.
Donc oui, en effet, on se connecte en ssh avec notre compte perso (qui
possède un mot de passe qu'on ne saisit jamais car on utilise notre clé ssh)
et ce compte est en effet « sudo » (pour les admins).
Pour cette escalade, dois-tu saisir le mot de passe de root (commande su)
ou utilises-tu de préférence sudo ?
On utilise sudo et on a configuré sudo (via notre gestionnaire de conf) pour
qu'on (les admins) puisse lancer "sudo cmd" sans demande de mot de passe _sauf_
dans le cas où la commande est "su" elle-même. Ceci étant, je crois bien que
cette petite exception avec "su" est plus cosmétique qu'autre chose. ;)
Dans ce dernier cas (sudo) comment est gérée la saisie du mot de passe (
NOPASSWORD ? saisie du mot de passe ? ...)
NOPASSWORD donc modulo la petite exception avec la commande su.
Si on suppose qu'en tant qu'administrateur, les opérations à effectuer à distance sur une machine demandent très souvent les privilèges de root, selon cette méthode, il faut se connecter par clé en tant qu'un utilisateur lamda, puis escalader en tant que root.
C'est ça ou lancer des commandes avec sudo. Chez nous, l'accès root via ssh n'est pas possible... avec un mot de passe (de toute façon celui-ci fait dans les 30 caractères environ).
Au passage, je m'étais planté dans mon message précédent, ce n'est pas "PermitRootLogin false" qu'on a mais "PermitRootLogin without-password" ce qui veut donc dire que :
a) une connexion "ssh root" est impossible via son mot de passe; b) une connexion "ssh root" est possible via une clé ssh.
Ceci étant, le cas b) n'est pas utilisé chez nous car nous ne déployons pas (en vérité on l'a fait mais on le fait plus désormais) de clé publique ssh dans /root/.ssh/authorized_keys.
Donc oui, en effet, on se connecte en ssh avec notre compte perso (qui possède un mot de passe qu'on ne saisit jamais car on utilise notre clé ssh) et ce compte est en effet « sudo » (pour les admins).
Pour cette escalade, dois-tu saisir le mot de passe de root (commande su) ou utilises-tu de préférence sudo ?
On utilise sudo et on a configuré sudo (via notre gestionnaire de conf) pour qu'on (les admins) puisse lancer "sudo cmd" sans demande de mot de passe _sauf_ dans le cas où la commande est "su" elle-même. Ceci étant, je crois bien que cette petite exception avec "su" est plus cosmétique qu'autre chose. ;)
Dans ce dernier cas (sudo) comment est gérée la saisie du mot de passe ( NOPASSWORD ? saisie du mot de passe ? ...)
NOPASSWORD donc modulo la petite exception avec la commande su.
C'est ça ou lancer des commandes avec sudo. Chez nous, l'accès root via ssh n'est pas possible... avec un mot de passe (de toute façon celui-ci fait dans les 30 caractères environ).
C'est ça ou lancer des commandes avec sudo. Chez nous, l'accès root via ssh
n'est pas possible... avec un mot de passe (de toute façon celui-ci fait
dans
les 30 caractères environ).
C'est ça ou lancer des commandes avec sudo. Chez nous, l'accès root via ssh n'est pas possible... avec un mot de passe (de toute façon celui-ci fait dans les 30 caractères environ).
On 2016-04-11 14:08:52 +0200, Sébastien NOBILI wrote:
Le lundi 11 avril 2016 à 12:38, Vincent Lefevre a écrit : > 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)?
Présenté comme ça, ça n’a en effet aucun intérêt, mais ça peut en prendre si : — pas de passphrase (ok, pas forcément top, mais tellement pratique),
Oui, mais si c'est pour les mettre sur une clé USB chiffrée, ce n'est plus trop pratique.
— la clé contient d’autres données en clair (ce qui est mon cas, d’où ma remarque, mais on sort un peu du sujet initial).
Oui, mais cela accroît le risque de divulguer ses données. Personnellement je fournirais le minimum d'info à une machine sous Windows.
On 2016-04-11 14:08:52 +0200, Sébastien NOBILI wrote:
Le lundi 11 avril 2016 à 12:38, Vincent Lefevre a écrit :
> 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)?
Présenté comme ça, ça n’a en effet aucun intérêt, mais ça peut en prendre si :
— pas de passphrase (ok, pas forcément top, mais tellement pratique),
Oui, mais si c'est pour les mettre sur une clé USB chiffrée, ce n'est
plus trop pratique.
— la clé contient d’autres données en clair (ce qui est mon cas, d’où ma
remarque, mais on sort un peu du sujet initial).
Oui, mais cela accroît le risque de divulguer ses données.
Personnellement je fournirais le minimum d'info à une machine
sous Windows.
On 2016-04-11 14:08:52 +0200, Sébastien NOBILI wrote:
Le lundi 11 avril 2016 à 12:38, Vincent Lefevre a écrit : > 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)?
Présenté comme ça, ça n’a en effet aucun intérêt, mais ça peut en prendre si : — pas de passphrase (ok, pas forcément top, mais tellement pratique),
Oui, mais si c'est pour les mettre sur une clé USB chiffrée, ce n'est plus trop pratique.
— la clé contient d’autres données en clair (ce qui est mon cas, d’où ma remarque, mais on sort un peu du sujet initial).
Oui, mais cela accroît le risque de divulguer ses données. Personnellement je fournirais le minimum d'info à une machine sous Windows.
