je souhaiterai enregistrer/visualiser les commandes tapées dans une
session ssh en temps réel.
L'idée est que je suis root sur un serveur, je voudrais permettre à
qq'un de se connecter sur celui mais à condition de pouvoir visualiser
tout ce qu'il tape en temps réel (pour pouvoir le jeter au cas où).
Exemple vécu: notre parc de portables ne se connecte qu'au réseau local. Les utilisateurs n'ont donc aucun droit d'administration, et ne peuvent changer la configuration du réseau. Un jour, un commercial en emprunte un pour une présentation lors d'un salon à San Francisco, veut se connecter au réseau disponible sur place, et bien sûr ne peut pas, faute de pouvoir configurer correctement le réseau... Donc soit je prenais l'avion pour aller régler ça, soit je lui donnais le mot de passe root par téléphone afin qu'il le règle lui-même (ou qu'un type sur place le fasse pour lui). A part ça, je n'ai pas vu d'autre solution...
Oui mais ça c'est pas un gros problème car chaque portable a son propre mot de passe root.
-- __Pascal Bourguignon__ http://www.informatimago.com/ Our enemies are innovative and resourceful, and so are we. They never stop thinking about new ways to harm our country and our people, and neither do we. -- Georges W. Bush
Jerome Lambert <jerome.lambert@swing.be> writes:
Exemple vécu: notre parc de portables ne se connecte qu'au réseau
local. Les utilisateurs n'ont donc aucun droit d'administration, et ne
peuvent changer la configuration du réseau.
Un jour, un commercial en emprunte un pour une présentation lors d'un
salon à San Francisco, veut se connecter au réseau disponible sur
place, et bien sûr ne peut pas, faute de pouvoir configurer
correctement le réseau...
Donc soit je prenais l'avion pour aller régler ça, soit je lui donnais
le mot de passe root par téléphone afin qu'il le règle lui-même (ou
qu'un type sur place le fasse pour lui). A part ça, je n'ai pas vu
d'autre solution...
Oui mais ça c'est pas un gros problème car chaque portable a son
propre mot de passe root.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we. -- Georges W. Bush
Exemple vécu: notre parc de portables ne se connecte qu'au réseau local. Les utilisateurs n'ont donc aucun droit d'administration, et ne peuvent changer la configuration du réseau. Un jour, un commercial en emprunte un pour une présentation lors d'un salon à San Francisco, veut se connecter au réseau disponible sur place, et bien sûr ne peut pas, faute de pouvoir configurer correctement le réseau... Donc soit je prenais l'avion pour aller régler ça, soit je lui donnais le mot de passe root par téléphone afin qu'il le règle lui-même (ou qu'un type sur place le fasse pour lui). A part ça, je n'ai pas vu d'autre solution...
Oui mais ça c'est pas un gros problème car chaque portable a son propre mot de passe root.
-- __Pascal Bourguignon__ http://www.informatimago.com/ Our enemies are innovative and resourceful, and so are we. They never stop thinking about new ways to harm our country and our people, and neither do we. -- Georges W. Bush
gregg
Rakotomandimby (R12y) Mihamina wrote:
Bonsoir,
Il va donc lui donner un accès root pour voir comment l'ami de l'ami s'en sort. Il va donc donner les droits qu'il faut à quelqu'un à qui il n'a pas confiance. Et se reserve le droit de la kicker ensuite.
Mais où l'OP a-t-il précisé qu'il allait donner les droits root ? J'avais compris qu'il voulait donner un accès utilisateur, voir ce qu'il fait, et se réserver le droit de déconnecter de force cet utilisateur s'il estime que ce dernier fait quelquechose de mal.
(Ouvrir un tail -f sur le fichier d'historique des commandes peut-être ?)
Aurais-je mal compris les intentions originelles ?
++
Rakotomandimby (R12y) Mihamina wrote:
Bonsoir,
Il va donc lui donner un accès root pour voir comment l'ami de l'ami s'en
sort. Il va donc donner les droits qu'il faut à quelqu'un à qui il n'a
pas confiance. Et se reserve le droit de la kicker ensuite.
Mais où l'OP a-t-il précisé qu'il allait donner les droits root ?
J'avais compris qu'il voulait donner un accès utilisateur, voir ce qu'il
fait, et se réserver le droit de déconnecter de force cet utilisateur
s'il estime que ce dernier fait quelquechose de mal.
(Ouvrir un tail -f sur le fichier d'historique des commandes peut-être ?)
Aurais-je mal compris les intentions originelles ?
Il va donc lui donner un accès root pour voir comment l'ami de l'ami s'en sort. Il va donc donner les droits qu'il faut à quelqu'un à qui il n'a pas confiance. Et se reserve le droit de la kicker ensuite.
Mais où l'OP a-t-il précisé qu'il allait donner les droits root ? J'avais compris qu'il voulait donner un accès utilisateur, voir ce qu'il fait, et se réserver le droit de déconnecter de force cet utilisateur s'il estime que ce dernier fait quelquechose de mal.
(Ouvrir un tail -f sur le fichier d'historique des commandes peut-être ?)
Aurais-je mal compris les intentions originelles ?
++
Jérémy JUST
On Wed, 25 May 2005 22:08:38 +0200 gregg wrote:
(Ouvrir un tail -f sur le fichier d'historique des commandes peut-être ?)
Avec Bash, l'historique est écrit au moment de la fermeture du shell, il me semble. Je ne sais pas ce qu'il en est pour les autres.
Donc pas terrible pour suivre en temps réel.
-- Jérémy JUST
On Wed, 25 May 2005 22:08:38 +0200
gregg <greggNOSPAMarbage@NOSPAMfree.WANTEDfr> wrote:
(Ouvrir un tail -f sur le fichier d'historique des commandes
peut-être ?)
Avec Bash, l'historique est écrit au moment de la fermeture du shell,
il me semble. Je ne sais pas ce qu'il en est pour les autres.
(Ouvrir un tail -f sur le fichier d'historique des commandes peut-être ?)
Avec Bash, l'historique est écrit au moment de la fermeture du shell, il me semble. Je ne sais pas ce qu'il en est pour les autres.
Donc pas terrible pour suivre en temps réel.
-- Jérémy JUST
Hugues
Ce cher Jérémy JUST a dit :
On Wed, 25 May 2005 22:08:38 +0200 gregg wrote:
(Ouvrir un tail -f sur le fichier d'historique des commandes peut-être ?)
Avec Bash, l'historique est écrit au moment de la fermeture du shell, il me semble. Je ne sais pas ce qu'il en est pour les autres.
Donc pas terrible pour suivre en temps réel.
Avec zsh il peut etre rempli au fur et a mesure, c'est d'ailleurs le cas sur ma config. (si j'ouvre un autre terminal avec zsh dedans, la derni ere commande accessible est celle que j'ai tapee dans un autre terminal, toujo urs ouvert).
Du coup, un simple "tail -f $HISTFILE" permet d'avoir quasiment en temps r eel les commandes tappees.
Cependant il demeure tres facile pour un quelconque utilisateur de changer le fichier d'historique par defaut, il faut donc etre vigilant sur ce point. Par exemple, je suppose que l'initiateur de ce thread a des droits root, il p eut tres bien lancer un shell sous l'identite de cet utiliateur et lancer la commande precisee ci dessus. Mais dans ce cas, c'est presque une violation de l'ethique d'un administrateur (je ne me permettrai jamais de me faire pas ser pour quelqu'un d'autre meme pour une commande bidon).
-- Hugues - Debianiste avant tout - http://www.nullpart.net/~hugues/Linux/
Ce cher Jérémy JUST <jeremy_just@netcourrier.com> a dit :
On Wed, 25 May 2005 22:08:38 +0200
gregg <greggNOSPAMarbage@NOSPAMfree.WANTEDfr> wrote:
(Ouvrir un tail -f sur le fichier d'historique des commandes
peut-être ?)
Avec Bash, l'historique est écrit au moment de la fermeture du shell,
il me semble. Je ne sais pas ce qu'il en est pour les autres.
Donc pas terrible pour suivre en temps réel.
Avec zsh il peut etre rempli au fur et a mesure, c'est d'ailleurs le cas sur
ma config. (si j'ouvre un autre terminal avec zsh dedans, la derni ere
commande accessible est celle que j'ai tapee dans un autre terminal, toujo urs
ouvert).
Du coup, un simple "tail -f $HISTFILE" permet d'avoir quasiment en temps r eel
les commandes tappees.
Cependant il demeure tres facile pour un quelconque utilisateur de changer le
fichier d'historique par defaut, il faut donc etre vigilant sur ce point. Par
exemple, je suppose que l'initiateur de ce thread a des droits root, il p eut
tres bien lancer un shell sous l'identite de cet utiliateur et lancer la
commande precisee ci dessus. Mais dans ce cas, c'est presque une violation de
l'ethique d'un administrateur (je ne me permettrai jamais de me faire pas ser
pour quelqu'un d'autre meme pour une commande bidon).
--
Hugues - Debianiste avant tout - http://www.nullpart.net/~hugues/Linux/
(Ouvrir un tail -f sur le fichier d'historique des commandes peut-être ?)
Avec Bash, l'historique est écrit au moment de la fermeture du shell, il me semble. Je ne sais pas ce qu'il en est pour les autres.
Donc pas terrible pour suivre en temps réel.
Avec zsh il peut etre rempli au fur et a mesure, c'est d'ailleurs le cas sur ma config. (si j'ouvre un autre terminal avec zsh dedans, la derni ere commande accessible est celle que j'ai tapee dans un autre terminal, toujo urs ouvert).
Du coup, un simple "tail -f $HISTFILE" permet d'avoir quasiment en temps r eel les commandes tappees.
Cependant il demeure tres facile pour un quelconque utilisateur de changer le fichier d'historique par defaut, il faut donc etre vigilant sur ce point. Par exemple, je suppose que l'initiateur de ce thread a des droits root, il p eut tres bien lancer un shell sous l'identite de cet utiliateur et lancer la commande precisee ci dessus. Mais dans ce cas, c'est presque une violation de l'ethique d'un administrateur (je ne me permettrai jamais de me faire pas ser pour quelqu'un d'autre meme pour une commande bidon).
-- Hugues - Debianiste avant tout - http://www.nullpart.net/~hugues/Linux/
Hugues
Bonjour,
Bonjour,
je souhaiterai enregistrer/visualiser les commandes tapées dans une session ssh en temps réel.
L'idée est que je suis root sur un serveur, je voudrais permettre à qq'un de se connecter sur celui mais à condition de pouvoir visualiser tout ce qu'il tape en temps réel (pour pouvoir le jeter au cas où).
Comment faire cela ?
Je t'invite *très fortement* à consulter la section 4.10.9 du manuel de sécurité Debian (en français en plus...) :
Elle te donnera plein d'idées pour ce que tu veux faire. (Il te suffira ensuite de faire un "tail -f <monfichier>" sur ton fichier de log des commandes tapées)
Cordialement, Hugues
Bonjour,
Bonjour,
je souhaiterai enregistrer/visualiser les commandes tapées dans une
session ssh en temps réel.
L'idée est que je suis root sur un serveur, je voudrais permettre à
qq'un de se connecter sur celui mais à condition de pouvoir visualiser
tout ce qu'il tape en temps réel (pour pouvoir le jeter au cas où).
Comment faire cela ?
Je t'invite *très fortement* à consulter la section 4.10.9 du manuel
de sécurité Debian (en français en plus...) :
Elle te donnera plein d'idées pour ce que tu veux faire.
(Il te suffira ensuite de faire un "tail -f <monfichier>" sur ton
fichier de log des commandes tapées)
je souhaiterai enregistrer/visualiser les commandes tapées dans une session ssh en temps réel.
L'idée est que je suis root sur un serveur, je voudrais permettre à qq'un de se connecter sur celui mais à condition de pouvoir visualiser tout ce qu'il tape en temps réel (pour pouvoir le jeter au cas où).
Comment faire cela ?
Je t'invite *très fortement* à consulter la section 4.10.9 du manuel de sécurité Debian (en français en plus...) :
Elle te donnera plein d'idées pour ce que tu veux faire. (Il te suffira ensuite de faire un "tail -f <monfichier>" sur ton fichier de log des commandes tapées)
Cordialement, Hugues
Cedric Foll
Je t'invite *très fortement* à consulter la section 4.10.9 du manuel de sécurité Debian (en français en plus...) :
Merci c'est exactement ce que je cherchais. Pour info, si j'ai été amené à me poser cette question c'est parce qu'un vendeur de soft était incapable de nous dépanner. Le soft livré ne fonctionnait pas et les développeur nous ont demandé un accès ssh sur le serveur. Ayant moyennement confiance je voulais voir tout ce que le type tapait et le virer si j'aimais pas ce que je voyais. Je suis étonné que des "administrateurs" n'aient jamais été confronté à ce genre de demande. J'ai même eu un jour le constructeur d'un de mes fw qui m'a demandé un accès ssh sur notre fw en prod pour comprendre un bug que nous rencontrions. Pour info j'ai systématiquement refusé ce genre d'ingérence sur mon parc mais je voulais savoir au cas où si je me retrouvais au pieds du mur sans pouvoir faire autrement.
Je t'invite *très fortement* à consulter la section 4.10.9 du manuel
de sécurité Debian (en français en plus...) :
Merci c'est exactement ce que je cherchais.
Pour info, si j'ai été amené à me poser cette question c'est parce qu'un
vendeur de soft était incapable de nous dépanner. Le soft livré ne
fonctionnait pas et les développeur nous ont demandé un accès ssh sur le
serveur. Ayant moyennement confiance je voulais voir tout ce que le type
tapait et le virer si j'aimais pas ce que je voyais.
Je suis étonné que des "administrateurs" n'aient jamais été confronté à
ce genre de demande. J'ai même eu un jour le constructeur d'un de mes fw
qui m'a demandé un accès ssh sur notre fw en prod pour comprendre un bug
que nous rencontrions.
Pour info j'ai systématiquement refusé ce genre d'ingérence sur mon parc
mais je voulais savoir au cas où si je me retrouvais au pieds du mur
sans pouvoir faire autrement.
Merci c'est exactement ce que je cherchais. Pour info, si j'ai été amené à me poser cette question c'est parce qu'un vendeur de soft était incapable de nous dépanner. Le soft livré ne fonctionnait pas et les développeur nous ont demandé un accès ssh sur le serveur. Ayant moyennement confiance je voulais voir tout ce que le type tapait et le virer si j'aimais pas ce que je voyais. Je suis étonné que des "administrateurs" n'aient jamais été confronté à ce genre de demande. J'ai même eu un jour le constructeur d'un de mes fw qui m'a demandé un accès ssh sur notre fw en prod pour comprendre un bug que nous rencontrions. Pour info j'ai systématiquement refusé ce genre d'ingérence sur mon parc mais je voulais savoir au cas où si je me retrouvais au pieds du mur sans pouvoir faire autrement.
Hugues
Ce cher Cedric Foll a dit :
Je t'invite *très fortement* à consulter la section 4.10.9 du manuel de sécurité Debian (en français en plus...) : http://www.debian.org/doc/manuals/securing-debian-howto/ch4.fr.html
Merci c'est exactement ce que je cherchais.
Tu m'en vois ravi :-)
Pour info, si j'ai été amené à me poser cette question c'est parc e qu'un vendeur de soft était incapable de nous dépanner. Le soft livré ne fonctionnait pas et les développeur nous ont demandé un accès ssh s ur le serveur. Ayant moyennement confiance je voulais voir tout ce que le type tapait et le virer si j'aimais pas ce que je voyais.
En effet, et franchement, je trouve la demande d'acces ssh abusive. Generalement, demander les bonnes infos (et accessoirement sav oir demander les bonnes infos) permet de sortir de ce genre de situations. Ou alors demander un rapport de strace, gdb ou je ne sais quoi..
Je suis curieux : si ca n'est pas indiscret, bien entendu, quelles sont les infos que ton vendeur de soft a obtenues sans pouvoir te depanner, au po int d'en venir a demander l'acces ssh ?
Je suis étonné que des "administrateurs" n'aient jamais été confr onté à ce genre de demande. J'ai même eu un jour le constructeur d'un de mes fw q ui m'a demandé un accès ssh sur notre fw en prod pour comprendre un bug que nous rencontrions.
Je pense surtout que c'est assez rare d'avoir a en arriver la, d'autant p lus qu'avec des informations ciblees, on peut arriver a resoudre bien des problemes..
J'imagine toutefois que le mode de developpement autour du logiciel li bre permet plus de libertes de la part du "client", ce qui fait que je s uis quelque peu inhabitue a ce genre de demandes sur un soft proprio (je suppos e ?)
Pour info j'ai systématiquement refusé ce genre d'ingérence sur mon parc mais je voulais savoir au cas où si je me retrouvais au pieds du mur sans po uvoir faire autrement.
Sage decision !
-- Hugues - Debianiste avant tout - http://www.nullpart.net/~hugues/Linux/
Ce cher Cedric Foll <cedric.foll@ac-rouen.fr> a dit :
Je t'invite *très fortement* à consulter la section 4.10.9 du manuel
de sécurité Debian (en français en plus...) :
http://www.debian.org/doc/manuals/securing-debian-howto/ch4.fr.html
Merci c'est exactement ce que je cherchais.
Tu m'en vois ravi :-)
Pour info, si j'ai été amené à me poser cette question c'est parc e qu'un
vendeur de soft était incapable de nous dépanner. Le soft livré ne
fonctionnait pas et les développeur nous ont demandé un accès ssh s ur le
serveur. Ayant moyennement confiance je voulais voir tout ce que le type
tapait et le virer si j'aimais pas ce que je voyais.
En effet, et franchement, je trouve la demande d'acces ssh
abusive. Generalement, demander les bonnes infos (et accessoirement sav oir
demander les bonnes infos) permet de sortir de ce genre de situations. Ou
alors demander un rapport de strace, gdb ou je ne sais quoi..
Je suis curieux : si ca n'est pas indiscret, bien entendu, quelles sont les
infos que ton vendeur de soft a obtenues sans pouvoir te depanner, au po int
d'en venir a demander l'acces ssh ?
Je suis étonné que des "administrateurs" n'aient jamais été confr onté à ce
genre de demande. J'ai même eu un jour le constructeur d'un de mes fw q ui m'a
demandé un accès ssh sur notre fw en prod pour comprendre un bug que nous
rencontrions.
Je pense surtout que c'est assez rare d'avoir a en arriver la, d'autant p lus
qu'avec des informations ciblees, on peut arriver a resoudre bien des
problemes..
J'imagine toutefois que le mode de developpement autour du logiciel li bre
permet plus de libertes de la part du "client", ce qui fait que je s uis
quelque peu inhabitue a ce genre de demandes sur un soft proprio (je suppos e ?)
Pour info j'ai systématiquement refusé ce genre d'ingérence sur mon parc mais
je voulais savoir au cas où si je me retrouvais au pieds du mur sans po uvoir
faire autrement.
Sage decision !
--
Hugues - Debianiste avant tout - http://www.nullpart.net/~hugues/Linux/
Je t'invite *très fortement* à consulter la section 4.10.9 du manuel de sécurité Debian (en français en plus...) : http://www.debian.org/doc/manuals/securing-debian-howto/ch4.fr.html
Merci c'est exactement ce que je cherchais.
Tu m'en vois ravi :-)
Pour info, si j'ai été amené à me poser cette question c'est parc e qu'un vendeur de soft était incapable de nous dépanner. Le soft livré ne fonctionnait pas et les développeur nous ont demandé un accès ssh s ur le serveur. Ayant moyennement confiance je voulais voir tout ce que le type tapait et le virer si j'aimais pas ce que je voyais.
En effet, et franchement, je trouve la demande d'acces ssh abusive. Generalement, demander les bonnes infos (et accessoirement sav oir demander les bonnes infos) permet de sortir de ce genre de situations. Ou alors demander un rapport de strace, gdb ou je ne sais quoi..
Je suis curieux : si ca n'est pas indiscret, bien entendu, quelles sont les infos que ton vendeur de soft a obtenues sans pouvoir te depanner, au po int d'en venir a demander l'acces ssh ?
Je suis étonné que des "administrateurs" n'aient jamais été confr onté à ce genre de demande. J'ai même eu un jour le constructeur d'un de mes fw q ui m'a demandé un accès ssh sur notre fw en prod pour comprendre un bug que nous rencontrions.
Je pense surtout que c'est assez rare d'avoir a en arriver la, d'autant p lus qu'avec des informations ciblees, on peut arriver a resoudre bien des problemes..
J'imagine toutefois que le mode de developpement autour du logiciel li bre permet plus de libertes de la part du "client", ce qui fait que je s uis quelque peu inhabitue a ce genre de demandes sur un soft proprio (je suppos e ?)
Pour info j'ai systématiquement refusé ce genre d'ingérence sur mon parc mais je voulais savoir au cas où si je me retrouvais au pieds du mur sans po uvoir faire autrement.
Sage decision !
-- Hugues - Debianiste avant tout - http://www.nullpart.net/~hugues/Linux/
Cedric Foll
Je suis curieux : si ca n'est pas indiscret, bien entendu, quelles sont les infos que ton vendeur de soft a obtenues sans pouvoir te depanner, au point d'en venir a demander l'acces ssh ?
Dans le cas du fw, des fichiers de logs, tous nos fichiers de conf, des trace tcpdumps. Pour le soft qui a motivé ma requête, ce n'ai pas moi qui est suivi l'affaire mais étant responsable sécu on m'a remonté la demande.
"More people are killed every year by pigs than by sharks, which shows you how good we are at evaluating risk." Bruce Schneier
Je suis curieux : si ca n'est pas indiscret, bien entendu, quelles sont les
infos que ton vendeur de soft a obtenues sans pouvoir te depanner, au point
d'en venir a demander l'acces ssh ?
Dans le cas du fw, des fichiers de logs, tous nos fichiers de conf, des
trace tcpdumps.
Pour le soft qui a motivé ma requête, ce n'ai pas moi qui est suivi
l'affaire mais étant responsable sécu on m'a remonté la demande.
Je suis curieux : si ca n'est pas indiscret, bien entendu, quelles sont les infos que ton vendeur de soft a obtenues sans pouvoir te depanner, au point d'en venir a demander l'acces ssh ?
Dans le cas du fw, des fichiers de logs, tous nos fichiers de conf, des trace tcpdumps. Pour le soft qui a motivé ma requête, ce n'ai pas moi qui est suivi l'affaire mais étant responsable sécu on m'a remonté la demande.
