securetty opérant avec SSH ?

Posté par Dabowl_75 le 21 septembre 2011 à 09:53.

Étiquettes : aucune

sept.

2011

Salut Rum (comme Nal),

voici le cahier des charges :

--> bloquer l'accès au compte root à un shell interactif en SSH

Problématique :

--> Conserver la possibilité de soumettre des remote command en root en SSH

Pistes déjà parcourues :

|| la directive "forced-commands-only" ne me plait guère car la liste des
commandes à autoriser serait trop grande

|| Il n'est pas possible de bloquer l'accès au compte root complètement, car nous vivons dans un monde imparfait où il n'existe pas encore
de profils d'utilisateurs ayant juste les droits qu'il faut pour faire ce dont nous avons besoin....

|| l'utilisation de /etc/securetty serait le bon candidat me semble t-il
car dans le cas de remote command il n'y a pas de tty, du coup les shell ouverts sur /dev/pts seraient bloqués

D'après ce que j'ai pu lire, /etc/securetty est inopérant avec SSH et ce, même si on le force avec PAM (pam_securetty.so).

En revanche, /etc/securetty est opérant lors du vénérable processus de Login, l'astuce consistait donc à forcer SSH à utiliser "login"
pour toute ouverture de session (UseLogin yes), hélas cela ne fonctionne pas, d'après les logs il semblerait que la consultation de /etc/securetty intervienne trop tard...

Je sais que ce besoin est un peu tordu, mais sur d'autres Unix, comme la déclinaison propriétaire de big blue, ce besoin est couvert par une feature native de celui-ci, il serait donc fort appréciable qu'une âme charitable se penche sur cette problématique...

A votre bon ccœur...

# no-pty ?

Posté par nono14 (site web personnel) le 21 septembre 2011 à 10:47. Évalué à 0.

Tout est dans le titre.

Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
- [^] # Re: no-pty ?
  
  Posté par Dabowl_75 le 21 septembre 2011 à 11:05. Évalué à 1.
  
  c'est séduisant mais cela oblige d'utiliser la directive "forced-commands-only" et donc m'oblige à définir la liste de commandes à autoriser, chose que ne veut pas.
  - [^] # Re: no-pty ?
    
    Posté par nono14 (site web personnel) le 21 septembre 2011 à 13:08. Évalué à 1.
    
    http://books.google.fr/books?id=RIlcQLUQKl0C&pg=PA295&lpg=PA295&dq=openssh+no-pty&source=bl&ots=58t4wPlYEI&sig=3ISwYT3TLGAxDD3R4C2tFpE7p1Q&hl=fr&ei=ssR5TtHiNcrsOf2IuJ4C&sa=X&oi=book_result&ct=result&resnum=6&ved=0CFEQ6AEwBQ
    
    Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
# sudo

Posté par Xavier Teyssier (site web personnel) le 21 septembre 2011 à 10:52. Évalué à 5.

Je ne suis pas sûr de bien avec compris le besoin, mais je tente à tout hasard une réponse : bloquer complètement l'accès root, mais permettre aux profils utilisateurs qui ont besoin de commande nécessitant les droits root d'exécuter ces commandes via sudo.
- [^] # Re: sudo
  
  Posté par nono14 (site web personnel) le 21 septembre 2011 à 12:27. Évalué à 1.
  
  Cela nécessite de définir les commandes autorisées, non ?
  
  Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
  - [^] # Re: sudo
    
    Posté par fcartegnie le 21 septembre 2011 à 13:12. Évalué à 4.
    
    "commandes autorisées" == ALL == root
  - [^] # Re: sudo
    
    Posté par Marotte ⛧ le 22 septembre 2011 à 01:00. Évalué à 1.
    
    J'aurais tendance à dire oui.
    
    Et j'ai l'impression que c'est un peu une obligation. Car si un utilisateur peut lancer une commande "en root en ssh" qu'est-ce qui lui empêche de lancer justement un shell interactif ?
# PermitRootLogin = no

Posté par Marotte ⛧ le 22 septembre 2011 à 00:55. Évalué à 1.

J'ai du mal cerner ton problème. Sinon la directive indiquée dans le titre de mon commentaire, dans la conf de ton serveur SSH, interdira à root de se connecter via SSH. Il faudra donc se logger d'abord avec un compte utilisateur. Puis tu conserves la possibilité de lancer des commandes en tant que root grâce à la commande "su - root" ?
- [^] # Re: PermitRootLogin = no
  
  Posté par Nils Ratusznik (site web personnel, Mastodon) le 22 septembre 2011 à 10:59. Évalué à 1.
  
  Je crains qu'il ne cherche à lancer des scripts depuis une autre machines qui feront quelque chose du genre ssh root@lolcathost "/root/scripts/asciilolcat.sh"
  - [^] # Re: PermitRootLogin = no
    
    Posté par Nils Ratusznik (site web personnel, Mastodon) le 22 septembre 2011 à 11:01. Évalué à 1.
    
    J'oubliais : et dans ce cas, un sudo sur le script en question est faisable. On aurait donc :
    
    ssh root@lolcathost "sudo /root/scripts/asciilolcat.sh"
    - [^] # Re: PermitRootLogin = no
      
      Posté par Nils Ratusznik (site web personnel, Mastodon) le 22 septembre 2011 à 11:02. Évalué à 1.
      
      Je me corrige : ssh lolcat@lolcathost "sudo /home/lolcat/scripts/asciilolcat.sh"

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.