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

Sécuriser un serveur ssh

5 réponses
Avatar
Nikö
Bonjour,

Je souhaiterai savoir quelles sont les mesures à mettre en place pour
sécuriser un serveur SSH. Je pense notamment au fait qu'un utilisateur
qui se connecte en SSH puisse aller dans les home des autres
utilisateurs. Comment empêcher cela ?

Y-a-t-il des mesures du même type à prendre pour empêcher les
utilisateurs d'atteindre les fichiers du système ?

--
Nikö

5 réponses

Avatar
Heyberger Ludovic
------=_Part_90359_25089645.1174134980754
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 3/17/07, Nikö wrote:

Je souhaiterai savoir quelles sont les mesures à mettre en place pour
sécuriser un serveur SSH.




La seule mesure que je vois a appliquer au niveau du "serveur SSH" bien qu e
ca n'en depende pas du tout, c'est une bonne politique de mots de passe.

Ensuite si t'es utilisateurs sont pret a changer un peu leurs habitudes, tu
peux deployer un systeme de clees publiques / privees (et interdire l'acces
par mot de passe uniquement). Ainsi les personnes souhaitant se connecter
devront posseder a la fois la bonne clee, ainsi que la bonne pass-phrase
(mot de passe de la clee).

Je pense notamment au fait qu'un utilisateur
qui se connecte en SSH puisse aller dans les home des autres
utilisateurs. Comment empêcher cela ?




C'est au niveau des droits de ton que tu dois agir. Il faut que tu joue sur
l'appartenance aux groupes et 'chmod' les homes des users avec les bons
droits.

Y-a-t-il des mesures du même type à prendre pour empêcher les
utilisateurs d'atteindre les fichiers du système ?




Idem. C'est une question de droits.

--
105 116 039 115 032 110 111 116 032 097
032 098 117 103 044 032 105 116 039 115
032 097 032 102 101 097 116 117 114 101

------=_Part_90359_25089645.1174134980754
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<br><br><div><span class="gmail_quote">On 3/17/07, <b class="gmail_send ername">Nikö</b> &lt;<a href="mailto:"> om</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-l eft: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Je souhaiterai savoir quelles sont les mesures à mettre en place pour<br> sécuriser un serveur SSH. </blockquote><div><br>&nbsp;La seule mesure que je vois a appliquer au niveau du &quot;serveur SSH&quot; bien que ca n&#39 ;en depende pas du tout, c&#39;est une bonne politique de mots de passe.
<br><br>Ensuite si t&#39;es utilisateurs sont pret a changer un peu leurs h abitudes, tu peux deployer un systeme de clees publiques / privees (et inte rdire l&#39;acces par mot de passe uniquement). Ainsi les personnes souhait ant se connecter devront posseder a la fois la bonne clee, ainsi que la bon ne pass-phrase (mot de passe de la clee).
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px s olid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Je pense notamment au fait qu&#39;un utilisateur<br>qui se connecte en SSH pui sse aller dans les home des autres
<br>utilisateurs. Comment empêcher cela ?</blockquote><div><br>C&#39;est au niveau des droits de ton que tu dois agir. Il faut que tu joue sur l&#39 ;appartenance aux groupes et &#39;chmod&#39; les homes des users avec les b ons droits.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px s olid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Y-a -t-il des mesures du même type à prendre pour empêcher les<br>utilisa teurs d&#39;atteindre les fichiers du système ?
</blockquote><div><br>Idem. C&#39;est une question de droits.<br clear="a ll"></div></div><br>-- <br>105 116 039 115 032 110 111 116 032 097<br>032 0 98 117 103 044 032 105 116 039 115<br>032 097 032 102 101 097 116 117 114 1 01

------=_Part_90359_25089645.1174134980754--


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Avatar
Shams Fantar
Nikö a écrit :
Bonjour,

Je souhaiterai savoir quelles sont les mesures à mettre en place pour
sécuriser un serveur SSH. Je pense notamment au fait qu'un utilisateur
qui se connecte en SSH puisse aller dans les home des autres
utilisateurs. Comment empêcher cela ?

Y-a-t-il des mesures du même type à prendre pour empêcher les
utilisateurs d'atteindre les fichiers du système ?




Il y a de la bonne documentation sur le net à ce sujet.

http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.fr.html

--
Shams Fantar (http://snurf.info)


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Avatar
Heyberger Ludovic
------=_Part_90403_12163491.1174135595132
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 3/17/07, Nikö wrote:

Bien vu.
J'ai modifié le fichier adduser.conf afin que les homes soient en 700.
Ca a l'air nikel maintenant.

Pour ce qui est des fichiers du système, est-il nécessaire de jouer d u
chmod et des groupes pour empêcher les utilisateurs de ce balader ou
est-ce déjà sécurisé par défaut ? J'aimerais quelques détails ici si
vous pouvez m'aiguiller sur ce que je dois faire. A priori, avec les
utilisateurs qui existent déjà, je peux pas lire certains fichiers du
système.




normallement tu dois pouvoir laisser tel quel.

apres je suis pas admin sys, mais personnellement je ne vois pas trop de
raisons d'aller toucher aux droits dans les fichiers de conf etc...

par defaut les droits des fichiers systeme sont configures pour eviter que
tes users lambda ne mettent le souk sur ta becane ;-) (ne pas pouvoir les
modifiers sans etre root). Par contre ce qui arrive aussi c'est qu'ils
soient accessible en lecture pour plus de transparence au niveau de la
gestion du serveur.

--
105 116 039 115 032 110 111 116 032 097
032 098 117 103 044 032 105 116 039 115
032 097 032 102 101 097 116 117 114 101

------=_Part_90403_12163491.1174135595132
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 3/17/07, <b class="gmail_sendername">Nikö</b> &lt;<a href="mailto: "></a>&gt; wrote:<div><span class="gmai l_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Bien vu.<br>J&#39;ai modifié le fichier adduser.conf afin que les homes s oient en 700.<br>Ca a l&#39;air&nbsp;&nbsp;nikel maintenant.<br><br>Pour ce qui est des fichiers du système, est-il nécessaire de jouer du<br>chmo d et des groupes pour empêcher les utilisateurs de ce balader ou
<br>est-ce déjà sécurisé par défaut ? J&#39;aimerais quelques d étails ici si<br>vous pouvez m&#39;aiguiller sur ce que je dois faire. A priori, avec les<br>utilisateurs qui existent déjà, je peux pas lire ce rtains fichiers du
<br>système.</blockquote><div><br>normallement tu dois pouvoir laisser te l quel.<br><br>apres je suis pas admin sys, mais personnellement je ne vois pas trop de raisons d&#39;aller toucher aux droits dans les fichiers de co nf etc...
<br></div><div><br>par defaut les droits des fichiers systeme sont configur es pour eviter que tes users lambda ne mettent le souk sur ta becane ;-) (n e pas pouvoir les modifiers sans etre root). Par contre ce qui arrive aussi c&#39;est qu&#39;ils soient accessible en lecture pour plus de transparenc e au niveau de la gestion du serveur.
<br></div></div><br>-- <br>105 116 039 115 032 110 111 116 032 097<br>032 0 98 117 103 044 032 105 116 039 115<br>032 097 032 102 101 097 116 117 114 1 01

------=_Part_90403_12163491.1174135595132--


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Avatar
Nicolas Daney
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Heyberger Ludovic a écrit :


On 3/17/07, *Nikö* <mailto: wrote:

Je souhaiterai savoir quelles sont les mesures à mettre en place pour
sécuriser un serveur SSH.


La seule mesure que je vois a appliquer au niveau du "serveur SSH" bien
que ca n'en depende pas du tout, c'est une bonne politique de mots de
passe.

Ensuite si t'es utilisateurs sont pret a changer un peu leurs habitudes,
tu peux deployer un systeme de clees publiques / privees (et interdire
l'acces par mot de passe uniquement). Ainsi les personnes souhaitant se
connecter devront posseder a la fois la bonne clee, ainsi que la bonne
pass-phrase (mot de passe de la clee).

Je pense notamment au fait qu'un utilisateur
qui se connecte en SSH puisse aller dans les home des autres
utilisateurs. Comment empêcher cela ?


C'est au niveau des droits de ton que tu dois agir. Il faut que tu joue
sur l'appartenance aux groupes et 'chmod' les homes des users avec les
bons droits.

Y-a-t-il des mesures du même type à prendre pour empêcher les
utilisateurs d'atteindre les fichiers du système ?


Idem. C'est une question de droits.

--
105 116 039 115 032 110 111 116 032 097
032 098 117 103 044 032 105 116 039 115
032 097 032 102 101 097 116 117 114 101



Bonjour,
il y a quelques infos intéressantes dans cette doc :
http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.fr.html#s5.1
Présentation d'une configuration sécurisée, chroot de l'utilisateur, etc..
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF++R3usPLDboxH0YRApFzAJ9HBuKDoiv6QL/+lymAGy7Bk0JrfQCgjiEi
Z7nbju3nOOJUZLLGbkwcGZw =zV2B
-----END PGP SIGNATURE-----


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Avatar
Nikö
Ok, j'ai bien pris note.

Merci vous tous.

--
Nikö