Forum Programmation.shell Bashrc avec paramètre ?

Posté par Sinistag le 12 avril 2015 à 19:33. Licence CC By‑SA.

Étiquettes :

avr.

2015

Bonjour,
J'effectue régulièrement la copie du même dossier depuis ma session dans mon école (sous debian 7 (sans accès root bien sur)) vers mon serveur (sous debian 7 également). En toute logique, il suffirais de faire un scp depuis le serveur (impossible dans l'autre sens, ssh ne fonctionne pas vers une ip externe à l'école).
Sauf que, à l'école j'affiche une image en ascii art au chargement du bashrc, ce qui fait planter scp, en couleur en plus avec tput, ce qui fait aussi planter scp, et surtout, ce que je ne peux pas me résoudre à enlever, j'ai un script qui demande un mot de passe lors du chargement du bashrc.
Ce que je fait pour le moment, c'est de me connecter au préalable en ssh, déplacer le bashrc, scp, remettre le bashrc
Mais j'aimerais beaucoup pouvoir automatiser le processus.

J'avais donc imaginé passer des arguments à mon bashrc qui permettent d'ignorer les étapes qui posent problème. Mais je ne suis même pas sur que ça soit possible…
Une idée ? voir même une solution ^ ^ ?

# Test de login interactif

Posté par littlebreizhman le 12 avril 2015 à 20:20. Évalué à 5. Dernière modification le 12 avril 2015 à 20:21.
ça ne répond pas à ta question mais devrait éviter ton plantage de scp

De mémoire … pas (re)testé

A rajouter en début de ton .bashrc ou au moins avant le echo
```
#test interactivité du shell : 
[ -z "$PS1" ] && return

# reste du bashrc
#...
```
- [^] # Re: Test de login interactif
  
  Posté par 🚲 Tanguy Ortolo (site web personnel) le 13 avril 2015 à 11:20. Évalué à 2.
  
  Ça ne devrait normalement servir à rien : le bashrc ne devrait même pas être lu pour les shells non interactifs !
  - [^] # Re: Test de login interactif
    
    Posté par kna le 13 avril 2015 à 11:36. Évalué à 2.
    Peut-être a-t-il dans son ~/.profile :
```
source .bashrc
```
    - [^] # Re: Test de login interactif
      
      Posté par 🚲 Tanguy Ortolo (site web personnel) le 15 avril 2015 à 17:02. Évalué à 3.
      
      Peut-être, mais ça n'expliquerait rien. Le .profile est seulement lu par les shells Bash de connexion.
  - [^] # Re: Test de login interactif
    
    Posté par littlebreizhman le 13 avril 2015 à 14:36. Évalué à 2. Dernière modification le 13 avril 2015 à 14:37.
    Certes mais a priori, dans son cas précis, il semble lu.
    
    Sur une ubuntu 14.10 par défaut, et comme l'évoque le commentaire ci dessus, le .bashrc est appelé par le .profile (qui replace le .bash_profile ici)
```
plop@plop $ more .profile
# ~/.profile: executed by the command interpreter for login shells.
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.

# the default umask is set in /etc/profile; for setting the umask
# for ssh logins, install and configure the libpam-umask package.
#umask 022

# if running bash
if [ -n "$BASH_VERSION" ]; then
    # include .bashrc if it exists
    if [ -f "$HOME/.bashrc" ]; then
        . "$HOME/.bashrc"
    fi
fi

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi
```
```
plop@plop $ man .bash
[...]
FILES
       /bin/bash
              The bash executable
       /etc/profile
              The systemwide initialization file, executed for login shells
       /etc/bash.bashrc
              The systemwide per-interactive-shell startup file
       /etc/bash.bash.logout
              The systemwide login shell cleanup file, executed when a login shell exits
       ~/.bash_profile
              The personal initialization file, executed for login shells
       ~/.bashrc
              The individual per-interactive-shell startup file
       ~/.bash_logout
              The individual login shell cleanup file, executed when a login shell exits
       ~/.inputrc
              Individual readline initialization file
[...]
```
    D'après le manuel, le fichier profile est exécuté pour les "login shell" : scp est-il un "login shell" ?
    - [^] # Re: Test de login interactif
      
      Posté par 🚲 Tanguy Ortolo (site web personnel) le 15 avril 2015 à 17:03. Évalué à 3.
      
      D'après le manuel, le fichier profile est exécuté pour les "login shell" : scp est-il un "login shell" ?
      
      Ah, voilà l'explication. scp, ça fait du ssh et ça lance des commandes genre cat pour transférer des fichiers. Donc fondamentalement, c'est comme ouvrir un simple ssh, et oui, ça doit être un shell de connexion !
- [^] # Re: Test de login interactif
  
  Posté par Sinistag le 13 avril 2015 à 21:04. Évalué à 1.
  
  Ça marche très bien !
  Je me sens d'ailleurs très idiot, car ~~c'est probablement le cas~~ lorsque j'ai voulu rajouter la ligne, je me suis aperçu qu'il y avait déjà un petit bout de script avec pour commentaire "If not running interactively, don't do anything"… si j'avais inséré mon code juste après celui-là, tout aurais bien marché dès le début… Note pour moi-même, toujours lire tous les commentaires des scripts qu'on modifie
  
  Quand à savoir s'il s'agit du fonctionnement normal d'scp, la présence par défaut de la gestion du cas non-interactif semble indiquer que oui en tout logique…
  
  J'ai une autre question, le fait est que si ma session semble bien sécurisé par demande de mot de passe dans le bashrc, il reside tout de même une grosse faille. En effet, un ctrl_c bien placé lors d'un ssh empêche le chargement normal du bashrc, donc de la demande de mot de passe, mais fait quand même la connexion, laissant l'utilisateur avec un terminal certes moche, mais totalement ouvert quand même… savez vous s'il est possible d'empêcher cela ? (je précise que je trap déjà le control c au tout début du .profile)
  - [^] # Re: Test de login interactif
    
    Posté par littlebreizhman le 13 avril 2015 à 23:06. Évalué à 2.
    
    J'ai une autre question, le fait est que si ma session semble bien sécurisé par demande de mot de passe dans le bashrc, il reside tout de même une grosse faille. En effet, un ctrl_c bien placé lors d'un ssh empêche le chargement normal du bashrc, donc de la demande de mot de passe, mais fait quand même la connexion, laissant l'utilisateur avec un terminal certes moche, mais totalement ouvert quand même
    
    Heu, je suis loin d'être un expert en ssh and co mais l’authentification lors de la connexion ssh n'a rien à voir avec le .bashrc.
    
    Sauf erreur de ma part, si le serveur ssh accepte la connexion, alors il poursuit en ouvrant une sessio et exécute le shell associé à l’utilisateur. Le ctrl +c devrait tuer la connexion tant que le mot de passe n'est pas tapé et peut être effectivement interrompre potentiellement l’exécution du .profile / .bashrc s'il est effectué dans les temps après authentification.
    
    Ssh est quand même à la base un protocole sécurisé, cela serait étonnant qu'on puisse le truander ainsi, surtout depuis le temps que l'on s'en sert. Tu es sûr de ne pas avoir mise en place une authentification par clé ?
    - [^] # Re: Test de login interactif
      
      Posté par Sinistag le 14 avril 2015 à 01:01. Évalué à 1. Dernière modification le 14 avril 2015 à 01:05.
      
      Bien sur que ssh en lui même n'a aucun problème de sécurité (connu du moins…).
      Il fonctionne exactement comme il le doit, mais dans un environnement comme celui de mon école, il est quasi-necessaire d'ajouter une sécurité demandant un mot de passe supplémentaire qui ne puisse être esquivé d'aucune façon, parce que il suffit d'une seconde d'inattention et hop, une clef de plus dans le authorized_keys. Sans compter les petits scripts codé par des petits malins qui permettent de lancer divers jeux, et qui installent les clefs publiques au passage…
      Malheureusement, il existe une façon simple d'esquiver la technique de demande de mot de passe à l'execution du bashrc: control+c juste après l'authentification par clef
      - [^] # Re: Test de login interactif
        
        Posté par fearan le 14 avril 2015 à 11:29. Évalué à 2.
        
        j'ajouterai un ssh plop@example.com /bin/csh risque aussi de court-circuiter quelques rc ou .profile
        
        Il faudrait que tu ajoutes dans ton ~/.ssh/rc les protections que tu souhaites; cependant elles seront aussi exécutées pour les commandes, et, probablement, le scp
        
        De toutes façon quelle est l'utilité de réclamer un mot de passe dans le bash, la session n'est pas protégée?
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
      - [^] # Re: Test de login interactif
        
        Posté par gouttegd (site web personnel) le 14 avril 2015 à 11:34. Évalué à 4.
        
        dans un environnement comme celui de mon école, il est quasi-necessaire d'ajouter une sécurité demandant un mot de passe supplémentaire qui ne puisse être esquivé d'aucune façon, parce que il suffit d'une seconde d'inattention et hop, une clef de plus dans le authorized_keys. Sans compter les petits scripts codé par des petits malins qui permettent de lancer divers jeux, et qui installent les clefs publiques au passage…
        
        Si on veut combiner l’authentification par clef publique avec une authentification par mot de passe, on peut configurer sshd pour s’en charger lui-même (AuthenticationMethods publickey,password) plutôt que se fier à un bidouillage du .bashrc…
        
        Je ne sais pas ce que c’est que cet environnement, mais si n’importe qui peut ajouter une clef publique dans le ~/.ssh/authorized_keys (le dossier de l’utilisateur, y compris ~/.ssh, est accessible en écriture à tout le monde ? wtf ?), qu’est-ce qui empêcherait ce même n’importe qui de tripatouiller le ~/.bashrc pour, par exemple, supprimer la demande de mot de passe ?
        
        En fait, je dirais a priori qu’utiliser SSH dans un environnement pareil revient un peu à utiliser une porte blindée avec digicode juste à côté d’une fenêtre grande ouverte…
        
        [^] # Re: Test de login interactif
        
        Posté par fearan le 14 avril 2015 à 14:26. Évalué à 2.
        
        j'ajouterai que si un 'petit malin' a pu ajouter un clé ssh via un script ou un binaire, la sécurité du compte est déjà moisie; il suffit que le script fasse un petit cp de /bin/bash dans ~nuisible/owned/$USER suivi d'un chmod +s ~/nuisible/owned/$USER et il fait ce qu'il veut.
        
        Il lui suffira de tapper ~/owned/user --noprofile --norc pour avoir accès à ton compte de manière invisible pour toi et cela même si tu changes tes clé ou mots de passe. Et le pire c'est qu'il lui suffit d'avoir un petit ajout dans un binaire librement accessible avec pleins de liens symbolique vers le dit binaire, qui après avoir fait leur crasse appel le binaire original.
        
        Clairement, ajouter une clé est bien trop visible
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: Test de login interactif
        
        Posté par Sinistag le 14 avril 2015 à 21:24. Évalué à 1.
        
        En effet, on peu dire que la sécurité est complètement moisie. Tout est question de ratio sécurité/facilité. exemple : maintenant scp fonctionne car le bash ne lit plus le password dans le cas de l'utilisation d'scp. mais du coup, ben il suffit de remplacer le bashrc avec scp et plus de sécurité…
        Autre exemple, si je lance le binaire de quelqu'un (par exemple un jeu) ben rien ne me dit qu'il ne fait pas un rm… mais je ne peu pas arrêter de faire quoi que ce soit simplement par peur…
        Pour en revenir à scp, c'est en fait la raison pour laquelle je souhaitais à l'origine pouvoir passer des paramètre au bashrc, ainsi, scp aurais fourni le mot de passe, gardant ainsi une sécurité optimale.
        De la même manière le script tel que j'utilise actuellement garantie (il me semble) une sécurité suffisante contre quelqu'un utilisant les clef ssh, à condition qu'on ne puisse abandonner l'execution du bashrc. Bien sur, le "petit malin" peu tout aussi bien réécrire le bashrc, mais c'est évidement pas très discret…
        Et pour la technique que tu décrit fearan, je ne la connaissait pas, et c'est en effet dévastateur, à condition que ça marche… ce que je n'ai pas réussi à faire. En effet, après avoir fait le ~/owned/user --noprofile --norc, je suis toujours 'nuisible', et je n'ai pas accès à ~user. Bon, malgré le fait que je commence à savoir faire quelques truc en script unix, j'ai encore beaucoup à apprendre…
        
        [^] # Re: Test de login interactif
        
        Posté par fearan le 14 avril 2015 à 23:59. Évalué à 2.
        
        Et pour la technique que tu décrit fearan, je ne la connaissait pas, et c'est en effet dévastateur, à condition que ça marche…
        
        Oh c'est pas dur à tester suffit juste de convaincre un de tes camarade de faire un cp /bin/bash n'importe ou, faire un chmod +s dessus, et toi de faire le bash en question pour avoir l'uid de ton camarade ;) Bien plus discret que le rajout de clé ssh. Il est aussi possible que la partition home soit montée en nosuid, mais c'est une conf plutôt rare.
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: Test de login interactif
        
        Posté par kna le 15 avril 2015 à 00:45. Évalué à 1.
        
        si n’importe qui peut ajouter une clef publique dans le ~/.ssh/authorized_keys
        
        Normalement, ça ne doit pas être possible.
        En tout cas par défaut, si les droits d'écriture de ~/.ssh ne sont pas restreint au compte correspondant, sshd loggue l'erreur « Authentication refused: bad ownership or modes for directory /home/user/.ssh » et ignore la clé (on peut encore se connecter avec un mot de passe si la config le permet).
        
        [^] # Re: Test de login interactif
        
        Posté par claudex le 15 avril 2015 à 22:51. Évalué à 3.
        
        sshd loggue l'erreur « Authentication refused: bad ownership or modes for directory /home/user/.ssh » et ignore la clé
        
        C'est d'ailleurs bien relou quand on est confronté au problème.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Bizarre

Posté par 🚲 Tanguy Ortolo (site web personnel) le 13 avril 2015 à 11:19. Évalué à 4.

C'est très curieux, il faudrait effectuer quelques tests pour regarder ce qui cause ça, parce que le bashrc n'est pas censé être interprété pour les shells non interactifs ! En fait, ce fichier est lu uniquement pour les shells interactifs qui ne sont pas des shells de login, même si cette restriction bizarre est généralement contournée en sourçant le bashrc depuis le fichier profile, qui est lu pour tous les shells interactifs.

http://tanguy.ortolo.eu/blog/article25/shrc

Suivre le flux des commentaires

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