Bonjour à tous,
Je n'arrive pas à trouver de solution à mon problème malgré de nombreuses requêtes google :(
Je vous explique mon problème. J'ai monté un tunnel SSH sans soucis comme décrit dans ce tutoriel => http://sicwww.epfl.ch/SIC/diode/ssh.html#tunnels
Donc je crée le tunnel entre ma machine cliente et mon serveur SSH (en utilisant Putty). J'utilise ensuite par example un VNC ou je me connecte aisément sur ma machine cibre (comme présenté dans le shéma).
Sauf que j'aimerais limité l'accès uniquement à cette machine cible. Car le problème est que si je mets comme adresse cible une autre machine dans le même réseaux, j'y accès aussi !!!
Le but final est de créer des comptes utilisateurs qui ne pourraient se connecter qu'à certaines machine cible via le tunnel SSH.
J'ai configuré le firewall linux (iptables) de manière à laisser tout passer en OUPUT et en limitant le INPUT. Même avec les traces, je ne vois pas passer le contenue du tunnel (ce qui me semble finalement normal) et donc je ne peux pas controler l'accès ou non à la machine cible finale ....
Si vous aviez une idée, cela me serait d'un grand secoure car je cherche depuis hier et ne trouve pas :( je me suis beaucoup concentré sur les iptables mais peut être qu'il faudrait que je m'oriente vers le serveur ssh en lui même ?
Merci
+
Romain
Conf du serveur SSH : CentOS 5.1 / OpenSSH_4.3p2 / iptables v1.3.5
Forum Linux.général Control des adresses cibles passant par un tunnel SSH
15
mai
2009
# iptables : filtre sur l'user qui émet le paquet
Posté par sov36 . Évalué à 2.
iptables permet d'appliquer des filtres selon l'user qui émet le paquet (peut-être même le groupe je sais plus).
Je me souviens plus de la syntaxe mais c'est dans la doc.
[^] # Re: iptables : filtre sur l'user qui émet le paquet
Posté par romain06 . Évalué à 1.
J'ai bien regardé dans la doc (http://www.linuxfr-france.org.invalid/prj/inetdoc/guides/iptables-tuto(...) mais je ne trouve pas la fonctione fitre par user. Je ne vois que des fonctions de filtrages sur différentes couches travaillant sur l'entête des paquets entrants/sortants. Je ne pense pas que l'info du user se trouve dans l'entente d'un paquet TCP/IP ??
[^] # Pas en INPUT
Posté par sov36 . Évalué à 1.
je ne pense pas que l'info du user se trouve dans l'entente d'un paquet TCP/IP ??
Non, effectivement. Par contre c'est une info dispo pour les paquets produits localement:
owner
This module attempts to match various characteristics of the packet creator, for locally generated packets. This match is only valid in the OUTPUT and POSTROUTING chains. Forwarded packets do not
have any socket associated with them. Packets from kernel threads do have a socket, but usually no owner.
[!] --uid-owner username
[!] --uid-owner userid[-userid]
Matches if the packet socket's file structure (if it has one) is owned by the given user. You may also specify a numerical UID, or an UID range.
[!] --gid-owner groupname
[!] --gid-owner groupid[-groupid]
Matches if the packet socket's file structure is owned by the given group. You may also specify a numerical GID, or a GID range.
[!] --socket-exists
Matches if the packet is associated with a socket.
# Plusieurs solutions sur le serveur
Posté par Framasky (site web personnel) . Évalué à 1.
AllowUsers luc
Ensuite il y a l'obligation d'avoir une clé enregistrée pour pouvoir se logger
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys
et on empèche de se logger si on a pas de clé mais juste un password :
PasswordAuthentication no
Encore une petite ligne que si tu l'as pas t'as autant de chance de te logger avec ta clé que de recevoir des excuses d'Albanel pour les conneries qu'elle a dites et pour la loi qu'elle a fait voter
ChallengeResponseAuthentication no
Voilà, s'il y en a qui voient des bêtises dans ce que je viens de dire, soyez critiques mais indulgents, j'ai fait mon sshd_config à partir d'un tuto, j'ai pas forcément tout bien compris.
Pis fais gaffe à bien configurer ton système de sécurisation (aka pare-feu mais ça fait plus classe) d'OpenOffice, sans ça, point de connexion ssh, tout le monde sait ça.
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Plusieurs solutions sur le serveur
Posté par cyriltom . Évalué à 1.
Regarde les options de configuration du fichier authorized_keys :
permit-open= host:port : permet uniquement l'ouverture d'un tunnel vers host:port
Voila la source : http://wiki.debian.org/fr/ssh
j'ai pas tester ...
Bon courage
[^] # Re: Plusieurs solutions sur le serveur
Posté par romain06 . Évalué à 1.
Merci pour vos réponses. La solution que tu as mis en place semble pas mal du tout. Couplé à ce qu'à rajouté cyriltom.
Juste pour bien voir si j'ai compris avant de me lancer :
/etc/ssh/sshd_config
AllowUsers user1 user2 user3 ...
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no
ChallengeResponseAuthentication no
/home/user1/.ssh/authorized_keys
permit-open= ADRESSE_CIBLE:PORT_CIBLE ssh-rsa clef-en-base64
Qu'en pensez vous ?
Merci
Romain
[^] # Solution utilisée
Posté par romain06 . Évalué à 1.
Après avoir configuré le /etc/ssh/sshd_conf sur mon serveur ssh :
AllowUsers user1
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys
PasswordAuthentication no
ChallengeResponseAuthentication no
Puis toujours sur le serveur ssh :
Ajout d'un user:
useradd -m user1
Création clé public/clé privé avec une passphrase:
ssh-keygen -t rsa -b 1024
Configuration du authorized_key:
cat id_rsa.pub >> authorized_keys
vi /home/user1/.ssh/authorized_keys
permitopen="IPCLIBLE:5900",no-pty,command="/bin/cat" ssh-rsa AAAAB3NzaC1qsAAAABIwAAAIEqsdG/kgpLSCTeBJHpnDqzqs0pTCsbB4nqlet5tUIkWCk+TiZELj5kFi2G6WnKPSY7xTI4/xX+utaFGAd5PHk5H43FCqPw1d6FDjPOBzyQVhy5sUMsvd73Gl7iuayziSnFInNgGQ5ErN9urK06SI+57yAvpaCjFS3W5TBKPc= user1
(no-pty => on ne donne pas de terminal au user, IPCIBLE:5900 => on restreind uniquement l'accès forward à une ip et un port donné)
Pour finir, sur le client en remote :
On configure putty de manière à utiliser la clé privé que l'on aura précédement adapté au format putty à l'aide de Puttygen.
=> test OK :D
Dernière chose : j'aimerais pouvoir convertir la clé privé au format putty directement sur mon serveur linux afin de la transmettre directement au user par mail .... une idée ??
Merci à tous pour votre aide
Romain
ps : sov36, merci pour la précision, du coup je vais plutôt utiliser le controle via ssh mais c'est bon à savoir :)
[^] # Re: Solution utilisée
Posté par sov36 . Évalué à 3.
installes putty sur le serveur. Tu risques juste d'avoir tout X qui debarque en dépendance. En cherchant bien tu peux peut-être bricoler le paquet pour éviter ça.
Et aussi rien à voir mais attention à pas laisser ~/.ssh/authorized_keys accessible en écriture par l'user ;)
ps : sov36, merci pour la précision, du coup je vais plutôt utiliser le controle via ssh mais c'est bon à savoir :)
De rien et pas de problème, there is more than one way to do it! ;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.