Sinistag a écrit 3 commentaires

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…

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

Ç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)