modem/routeur
|
|
serveur Linux (mail, proxy, etc.)
|
|
stations de travail sous Windows
Si je veux prendre le contrôle de mon PC du bureau depuis chez moi,
pas de problème : un p'tit tunnel SSH et le tour est joué.
Sauf qu'un collègue veut faire pareil, et j'aimerais autant éviter de
lui donner un accès au shell de la machine Linux.
En fait, je voudrais qu'il ne puisse rien faire d'autre qu'ouvrir un
tunnel vers 192.168.5.12:5900.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Bruno Bonfils
Fabien LE LEZ writes:
Sauf qu'un collègue veut faire pareil, et j'aimerais autant éviter de lui donner un accès au shell de la machine Linux. En fait, je voudrais qu'il ne puisse rien faire d'autre qu'ouvrir un tunnel vers 192.168.5.12:5900.
Est-ce possible ?
Cela doit être possible via le fichier ~user/.ssh/config en mettant un forward et en restreignant la clé à une commande comme cat.
Sauf qu'un collègue veut faire pareil, et j'aimerais autant éviter de
lui donner un accès au shell de la machine Linux.
En fait, je voudrais qu'il ne puisse rien faire d'autre qu'ouvrir un
tunnel vers 192.168.5.12:5900.
Est-ce possible ?
Cela doit être possible via le fichier ~user/.ssh/config en mettant un
forward et en restreignant la clé à une commande comme cat.
Sauf qu'un collègue veut faire pareil, et j'aimerais autant éviter de lui donner un accès au shell de la machine Linux. En fait, je voudrais qu'il ne puisse rien faire d'autre qu'ouvrir un tunnel vers 192.168.5.12:5900.
Est-ce possible ?
Cela doit être possible via le fichier ~user/.ssh/config en mettant un forward et en restreignant la clé à une commande comme cat.
En fait, je voudrais qu'il ne puisse rien faire d'autre qu'ouvrir un tunnel vers 192.168.5.12:5900.
Est-ce possible ?
Oui : -1- lui creer un compte, un $HOME, ne pas mettre de mot de passe -2- lui faire creer une clef SSH et deposer la clef dans son $HOME sur le serveur -3- dans $HOME/.ssh/authorized_keys, interdire l'ouverture de shell avec 'no-pty'. On peut aussi : * forcer des commandes avec 'command="..."' (peu interessant dans ce contexte AMHA), * utiliser tun(4) avec 'tunnel="X"' (idem), * limiter les tunnels avec 'permitopen="host:port"' (nettement plus utilisable), C'est documente dans le manuel de sshd(8). -4- tester !
Sinon, il existe scponly et rssh ; le second permet peut-etre de faire des choses comme ca, a voir.
HTH,
-- Pascal Cabaud
Fabien LE LEZ wrote:
...snip tunnels SSH sans acces au shell...
En fait, je voudrais qu'il ne puisse rien faire d'autre qu'ouvrir un
tunnel vers 192.168.5.12:5900.
Est-ce possible ?
Oui :
-1- lui creer un compte, un $HOME, ne pas mettre de mot de passe
-2- lui faire creer une clef SSH et deposer la clef dans son $HOME sur
le serveur
-3- dans $HOME/.ssh/authorized_keys, interdire l'ouverture de shell avec
'no-pty'. On peut aussi :
* forcer des commandes avec 'command="..."' (peu interessant dans ce
contexte AMHA),
* utiliser tun(4) avec 'tunnel="X"' (idem),
* limiter les tunnels avec 'permitopen="host:port"' (nettement plus
utilisable),
C'est documente dans le manuel de sshd(8).
-4- tester !
Sinon, il existe scponly et rssh ; le second permet peut-etre de faire
des choses comme ca, a voir.
En fait, je voudrais qu'il ne puisse rien faire d'autre qu'ouvrir un tunnel vers 192.168.5.12:5900.
Est-ce possible ?
Oui : -1- lui creer un compte, un $HOME, ne pas mettre de mot de passe -2- lui faire creer une clef SSH et deposer la clef dans son $HOME sur le serveur -3- dans $HOME/.ssh/authorized_keys, interdire l'ouverture de shell avec 'no-pty'. On peut aussi : * forcer des commandes avec 'command="..."' (peu interessant dans ce contexte AMHA), * utiliser tun(4) avec 'tunnel="X"' (idem), * limiter les tunnels avec 'permitopen="host:port"' (nettement plus utilisable), C'est documente dans le manuel de sshd(8). -4- tester !
Sinon, il existe scponly et rssh ; le second permet peut-etre de faire des choses comme ca, a voir.
HTH,
-- Pascal Cabaud
Eric Lalitte
"Fabien LE LEZ" wrote in message news:
En fait, je voudrais qu'il ne puisse rien faire d'autre qu'ouvrir un tunnel vers 192.168.5.12:5900.
Est-ce possible ?
Oui. Cela peut se faire en limitant les commandes exécutées sur le shell. Cela se fait au niveau de la clef publique positionnée sur le serveur. Avant la clef, tu mets un truc du genre command="ls -la" et la commande ls -la sera la seule automatiquement effectuée sur le serveur. Pour lancer des choses plus élaborées, tu as la variable $SSH_ORIGINAL_COMMAND qui te permet de faire un script sur les commandes autorisées ou non.
"Fabien LE LEZ" <gramster@gramster.com> wrote in message
news:pbeov1hkt4c8jbnfa8piqot07equ56hotn@4ax.com
En fait, je voudrais qu'il ne puisse rien faire d'autre qu'ouvrir un
tunnel vers 192.168.5.12:5900.
Est-ce possible ?
Oui.
Cela peut se faire en limitant les commandes exécutées sur le shell.
Cela se fait au niveau de la clef publique positionnée sur le serveur.
Avant la clef, tu mets un truc du genre command="ls -la" et la commande
ls -la sera la seule automatiquement effectuée sur le serveur.
Pour lancer des choses plus élaborées, tu as la variable
$SSH_ORIGINAL_COMMAND qui te permet de faire un script sur les commandes
autorisées ou non.
C'est en partie expliqué là, mais dans un autre contexte:
<http://www.lalitte.com/rsync.html#secu>
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
En fait, je voudrais qu'il ne puisse rien faire d'autre qu'ouvrir un tunnel vers 192.168.5.12:5900.
Est-ce possible ?
Oui. Cela peut se faire en limitant les commandes exécutées sur le shell. Cela se fait au niveau de la clef publique positionnée sur le serveur. Avant la clef, tu mets un truc du genre command="ls -la" et la commande ls -la sera la seule automatiquement effectuée sur le serveur. Pour lancer des choses plus élaborées, tu as la variable $SSH_ORIGINAL_COMMAND qui te permet de faire un script sur les commandes autorisées ou non.
-3- dans $HOME/.ssh/authorized_keys, interdire l'ouverture de shell avec 'no-pty'. On peut aussi :
Le no-pty interdit l'allocation d'un pty (comme son nom l'indique !), mais n'empêche pas une commande du goût ssh -T hote /bin/sh , il me semble ?
Peut-être utiliser command='/bin/cat' et forcer son shell à /bin/cat ?
Fred -- Something inside of me has opened up its eyes Why did you put it there did you not realize This thing inside of me it screams the loudest sound Sometimes I think I could (Nine Inch Nails, Burn)
-3- dans $HOME/.ssh/authorized_keys, interdire l'ouverture de shell avec
'no-pty'. On peut aussi :
Le no-pty interdit l'allocation d'un pty (comme son nom l'indique !),
mais n'empêche pas une commande du goût ssh -T hote /bin/sh , il me
semble ?
Peut-être utiliser command='/bin/cat' et forcer son shell à /bin/cat ?
Fred
--
Something inside of me has opened up its eyes
Why did you put it there did you not realize
This thing inside of me it screams the loudest sound
Sometimes I think I could (Nine Inch Nails, Burn)
-3- dans $HOME/.ssh/authorized_keys, interdire l'ouverture de shell avec 'no-pty'. On peut aussi :
Le no-pty interdit l'allocation d'un pty (comme son nom l'indique !), mais n'empêche pas une commande du goût ssh -T hote /bin/sh , il me semble ?
Peut-être utiliser command='/bin/cat' et forcer son shell à /bin/cat ?
Fred -- Something inside of me has opened up its eyes Why did you put it there did you not realize This thing inside of me it screams the loudest sound Sometimes I think I could (Nine Inch Nails, Burn)
Fabien LE LEZ
On 22 Feb 2006 21:52:53 GMT, Fabien LE LEZ :
Sauf qu'un collègue veut faire pareil, et j'aimerais autant éviter de lui donner un accès au shell de la machine Linux. En fait, je voudrais qu'il ne puisse rien faire d'autre qu'ouvrir un tunnel vers 192.168.5.12:5900.
Merci à tous pour vos réponses. Voici ce que j'ai fait :
1- J'ai créé un petit programme, /bin/shell-sleep, qui se contente d'attendre deux minutes un peu verbeusement[*]. Ça laisse le temps de lancer vncviewer. Bien sûr, je l'ai mis en "chown root"/"chmod 755".
2- J'ai créé un utilisateur "schtroumpf", avec ce programme comme shell.
3- J'ai créé une clé avec "ssh-keygen -t rsa -b 1024" avec, tant qu'à faire, un mot de passe non-vide.
4- J'ai créé le fichier /home/schtroumpf/.ssh/authorized_keys, avec une seule ligne :
5- Je peux alors me connecter avec ssh -L 9999:192.168.5.12:5900 -P -i /cygdrive/c/.ssh/id_rsa -l schtroumpf adresse-IP-du-serveur
Est-ce correct ? Y a-t-il un trou que je n'aurais pas vu ? J'ai l'impression que ça suffit pour m'assurer que l'utilisateur en question ne pourra rien faire d'autre qu'accéder à sa machine en VNC, mais j'aimerais avoir confirmation. Merci d'avance...
[*] Le source :
#include <stdio.h> #include <unistd.h>
int main() { for (int i0; i>0; --i) { printf ("%d seconde%sn", i, ((i>1)?"s":"")); sleep (1); } }
En gros, il affiche "120 secondes" "119 secondes" etc., et n'accepte aucune entrée.
On 22 Feb 2006 21:52:53 GMT, Fabien LE LEZ <gramster@gramster.com>:
Sauf qu'un collègue veut faire pareil, et j'aimerais autant éviter de
lui donner un accès au shell de la machine Linux.
En fait, je voudrais qu'il ne puisse rien faire d'autre qu'ouvrir un
tunnel vers 192.168.5.12:5900.
Merci à tous pour vos réponses.
Voici ce que j'ai fait :
1- J'ai créé un petit programme, /bin/shell-sleep, qui se contente
d'attendre deux minutes un peu verbeusement[*]. Ça laisse le temps de
lancer vncviewer.
Bien sûr, je l'ai mis en "chown root"/"chmod 755".
2- J'ai créé un utilisateur "schtroumpf", avec ce programme comme
shell.
3- J'ai créé une clé avec "ssh-keygen -t rsa -b 1024" avec, tant qu'à
faire, un mot de passe non-vide.
4- J'ai créé le fichier /home/schtroumpf/.ssh/authorized_keys, avec
une seule ligne :
5- Je peux alors me connecter avec
ssh -L 9999:192.168.5.12:5900 -P -i /cygdrive/c/.ssh/id_rsa -l
schtroumpf adresse-IP-du-serveur
Est-ce correct ? Y a-t-il un trou que je n'aurais pas vu ?
J'ai l'impression que ça suffit pour m'assurer que l'utilisateur en
question ne pourra rien faire d'autre qu'accéder à sa machine en VNC,
mais j'aimerais avoir confirmation.
Merci d'avance...
[*] Le source :
#include <stdio.h>
#include <unistd.h>
int main()
{
for (int i0; i>0; --i)
{
printf ("%d seconde%sn", i, ((i>1)?"s":""));
sleep (1);
}
}
En gros, il affiche "120 secondes" "119 secondes" etc., et n'accepte
aucune entrée.
Sauf qu'un collègue veut faire pareil, et j'aimerais autant éviter de lui donner un accès au shell de la machine Linux. En fait, je voudrais qu'il ne puisse rien faire d'autre qu'ouvrir un tunnel vers 192.168.5.12:5900.
Merci à tous pour vos réponses. Voici ce que j'ai fait :
1- J'ai créé un petit programme, /bin/shell-sleep, qui se contente d'attendre deux minutes un peu verbeusement[*]. Ça laisse le temps de lancer vncviewer. Bien sûr, je l'ai mis en "chown root"/"chmod 755".
2- J'ai créé un utilisateur "schtroumpf", avec ce programme comme shell.
3- J'ai créé une clé avec "ssh-keygen -t rsa -b 1024" avec, tant qu'à faire, un mot de passe non-vide.
4- J'ai créé le fichier /home/schtroumpf/.ssh/authorized_keys, avec une seule ligne :
5- Je peux alors me connecter avec ssh -L 9999:192.168.5.12:5900 -P -i /cygdrive/c/.ssh/id_rsa -l schtroumpf adresse-IP-du-serveur
Est-ce correct ? Y a-t-il un trou que je n'aurais pas vu ? J'ai l'impression que ça suffit pour m'assurer que l'utilisateur en question ne pourra rien faire d'autre qu'accéder à sa machine en VNC, mais j'aimerais avoir confirmation. Merci d'avance...
[*] Le source :
#include <stdio.h> #include <unistd.h>
int main() { for (int i0; i>0; --i) { printf ("%d seconde%sn", i, ((i>1)?"s":"")); sleep (1); } }
En gros, il affiche "120 secondes" "119 secondes" etc., et n'accepte aucune entrée.
Pascal Cabaud
F. Senault wrote:
-3- dans $HOME/.ssh/authorized_keys, interdire l'ouverture de shell avec 'no-pty'. On peut aussi :
Le no-pty interdit l'allocation d'un pty (comme son nom l'indique !), mais n'empêche pas une commande du goût ssh -T hote /bin/sh , il me semble ?
/bin/sh non, /bin/ls oui, je viens de tester.
Peut-être utiliser command='/bin/cat' et forcer son shell à /bin/cat ?
En effet. En fait, ce que j'ai omis de preciser, c'est que j'utilise toujours un command=... avec.
-- Pascal Cabaud
F. Senault wrote:
-3- dans $HOME/.ssh/authorized_keys, interdire l'ouverture de shell avec
'no-pty'. On peut aussi :
Le no-pty interdit l'allocation d'un pty (comme son nom l'indique !),
mais n'empêche pas une commande du goût ssh -T hote /bin/sh , il me
semble ?
/bin/sh non, /bin/ls oui, je viens de tester.
Peut-être utiliser command='/bin/cat' et forcer son shell à /bin/cat ?
En effet. En fait, ce que j'ai omis de preciser, c'est que j'utilise
toujours un command=... avec.