Lorsque je suis en déplacement j'ai parfois besoin d'utiliser un hot
spot wifi qui en étant libre d'accès est sans aucune clef de connexion.
Le risque d'interception de données et donc assez élevé, par conséquent
je me suis dit que si je pouvais passer par un passerelle distante
(proxy ?) sécurisée installée à la maison je pourrai ainsi diminuer ou
éliminer le risque.
Je souhaite savoir quelles solutions existent sous linux ?
J'ai vu un produit qui s'appel "sme server", est-ce la solution ?
localhost sshd[1662] error: connect_to 127.0.0.1 port 80 failed
qui correspondent à des tentatives de connexion avec Opera configuré avec le proxy sur 127.0.0.1 sur la machine qui fonctionne avec PuTTY et un tunnel qui écoute sur un port précis et redirige vers la connexion SSH sur 127.0.0.1:80
Ai-je merdé ?
Merci
J'ai contourné le problème en configurant le tunnel ssh avec PuTTY avec comme port non pas 80 mais le port de squid qui est 3128. Du coup, ça marche.
Par contre sur un autre pc avec linux et la commande ssh -ND 8887 -p 22 , c'est la page blanche sur le navigateur, pourtant correctement configuré.
A+
norm a exposé le 13/11/2010 :
Voilà, dans auth.log il y a des
localhost sshd[1662] error: connect_to 127.0.0.1 port 80 failed
qui correspondent à des tentatives de connexion avec Opera configuré avec le
proxy sur 127.0.0.1 sur la machine qui fonctionne avec PuTTY et un tunnel qui
écoute sur un port précis et redirige vers la connexion SSH sur 127.0.0.1:80
Ai-je merdé ?
Merci
J'ai contourné le problème en configurant le tunnel ssh avec PuTTY avec
comme port non pas 80 mais le port de squid qui est 3128. Du coup, ça
marche.
Par contre sur un autre pc avec linux et la commande ssh -ND 8887 -p 22
root@adresse, c'est la page blanche sur le navigateur, pourtant
correctement configuré.
localhost sshd[1662] error: connect_to 127.0.0.1 port 80 failed
qui correspondent à des tentatives de connexion avec Opera configuré avec le proxy sur 127.0.0.1 sur la machine qui fonctionne avec PuTTY et un tunnel qui écoute sur un port précis et redirige vers la connexion SSH sur 127.0.0.1:80
Ai-je merdé ?
Merci
J'ai contourné le problème en configurant le tunnel ssh avec PuTTY avec comme port non pas 80 mais le port de squid qui est 3128. Du coup, ça marche.
Par contre sur un autre pc avec linux et la commande ssh -ND 8887 -p 22 , c'est la page blanche sur le navigateur, pourtant correctement configuré.
A+
Aeris
norm wrote:
Par contre sur un autre pc avec linux et la commande ssh -ND 8887 -p 22 , c'est la page blanche sur le navigateur, pourtant correctement configuré.
Cette commande lance un proxy SOCKS et non pas un proxy HTTP comme celui de Squid. Il faut donc bien penser à cocher la case "Proxy SOCKS" dans la configuration du navigateur.
norm wrote:
Par contre sur un autre pc avec linux et la commande ssh -ND 8887 -p 22
root@adresse, c'est la page blanche sur le navigateur, pourtant
correctement configuré.
Cette commande lance un proxy SOCKS et non pas un proxy HTTP comme celui de
Squid.
Il faut donc bien penser à cocher la case "Proxy SOCKS" dans la
configuration du navigateur.
Par contre sur un autre pc avec linux et la commande ssh -ND 8887 -p 22 , c'est la page blanche sur le navigateur, pourtant correctement configuré.
Cette commande lance un proxy SOCKS et non pas un proxy HTTP comme celui de Squid. Il faut donc bien penser à cocher la case "Proxy SOCKS" dans la configuration du navigateur.
norm
Aeris avait écrit le 13/11/2010 :
norm wrote:
Par contre sur un autre pc avec linux et la commande ssh -ND 8887 -p 22 , c'est la page blanche sur le navigateur, pourtant correctement configuré.
Cette commande lance un proxy SOCKS et non pas un proxy HTTP comme celui de Squid. Il faut donc bien penser à cocher la case "Proxy SOCKS" dans la configuration du navigateur.
Effectivement, j'avais renseigné HTTP & également Proxy SOCKS. En ne laissant que SOCKS Host, ça marche. Et c'est bien plus rapide qu'en passant par squid, vu que le pc qui heberge le serveur ssh et squid et très très ancien.
Merci.
Aeris avait écrit le 13/11/2010 :
norm wrote:
Par contre sur un autre pc avec linux et la commande ssh -ND 8887 -p 22
root@adresse, c'est la page blanche sur le navigateur, pourtant
correctement configuré.
Cette commande lance un proxy SOCKS et non pas un proxy HTTP comme celui de
Squid.
Il faut donc bien penser à cocher la case "Proxy SOCKS" dans la
configuration du navigateur.
Effectivement, j'avais renseigné HTTP & également Proxy SOCKS. En ne
laissant que SOCKS Host, ça marche. Et c'est bien plus rapide qu'en
passant par squid, vu que le pc qui heberge le serveur ssh et squid et
très très ancien.
Par contre sur un autre pc avec linux et la commande ssh -ND 8887 -p 22 , c'est la page blanche sur le navigateur, pourtant correctement configuré.
Cette commande lance un proxy SOCKS et non pas un proxy HTTP comme celui de Squid. Il faut donc bien penser à cocher la case "Proxy SOCKS" dans la configuration du navigateur.
Effectivement, j'avais renseigné HTTP & également Proxy SOCKS. En ne laissant que SOCKS Host, ça marche. Et c'est bien plus rapide qu'en passant par squid, vu que le pc qui heberge le serveur ssh et squid et très très ancien.
Merci.
norm
Emmanuel Florac a formulé la demande :
Même pas besoin de squid :
ssh -ND 8887 -p 22
Ensuite tu déclares localhost:8887 comme proxy SOCKS et le tour est joué.
Question cryptage, cette façon de se connecter fonctionne avec un échange de clefs ? Est-ce suffisamment sécurisé ?
Emmanuel Florac a formulé la demande :
Même pas besoin de squid :
ssh -ND 8887 -p 22 toto@adresse
Ensuite tu déclares localhost:8887 comme proxy SOCKS et le tour est joué.
Question cryptage, cette façon de se connecter fonctionne avec un
échange de clefs ?
Est-ce suffisamment sécurisé ?
Ensuite tu déclares localhost:8887 comme proxy SOCKS et le tour est joué.
Question cryptage, cette façon de se connecter fonctionne avec un échange de clefs ? Est-ce suffisamment sécurisé ?
Aeris
norm wrote:
Question cryptage, cette façon de se connecter fonctionne avec un échange de clefs ? Est-ce suffisamment sécurisé ?
ssh, y'a difficilement plus sécurisé et si ta clef est suffisament long (> 1024 bits) avec les connexions par mot de passe désactivées, y'a très peu de risques de se faire bruteforcer
norm wrote:
Question cryptage, cette façon de se connecter fonctionne avec un
échange de clefs ?
Est-ce suffisamment sécurisé ?
ssh, y'a difficilement plus sécurisé
et si ta clef est suffisament long (> 1024 bits) avec les connexions par mot
de passe désactivées, y'a très peu de risques de se faire bruteforcer
Question cryptage, cette façon de se connecter fonctionne avec un échange de clefs ? Est-ce suffisamment sécurisé ?
ssh, y'a difficilement plus sécurisé et si ta clef est suffisament long (> 1024 bits) avec les connexions par mot de passe désactivées, y'a très peu de risques de se faire bruteforcer
norm
Il se trouve que Aeris a formulé :
ssh, y'a difficilement plus sécurisé et si ta clef est suffisament long (> 1024 bits) avec les connexions par mot de passe désactivées, y'a très peu de risques de se faire bruteforcer
Ok mais avec connexion par mot de passe, comme proposé par Emmanuel et le famous ssh -ND 8887 -p 22 ? A quel niveau se situe la protection ?
Il se trouve que Aeris a formulé :
ssh, y'a difficilement plus sécurisé
et si ta clef est suffisament long (> 1024 bits) avec les connexions par mot
de passe désactivées, y'a très peu de risques de se faire bruteforcer
Ok mais avec connexion par mot de passe, comme proposé par Emmanuel et
le famous ssh -ND 8887 -p 22 toto@adresse ? A quel niveau se situe la
protection ?
ssh, y'a difficilement plus sécurisé et si ta clef est suffisament long (> 1024 bits) avec les connexions par mot de passe désactivées, y'a très peu de risques de se faire bruteforcer
Ok mais avec connexion par mot de passe, comme proposé par Emmanuel et le famous ssh -ND 8887 -p 22 ? A quel niveau se situe la protection ?
Aeris
norm wrote:
Ok mais avec connexion par mot de passe, comme proposé par Emmanuel et le famous ssh -ND 8887 -p 22 ? A quel niveau se situe la protection ?
Tout ce qui passe par le tunnel ssh est automatiquement crypté par le client, transmis sur le réseau (de manière sécurisée donc) et décrypté par le serveur. Tous est sécurisé par défaut.
Et il vaut mieux privilégier les connexions par clef privée et désactiver complètement les connexions par mot de passe, question de sécurité (pas de bruteforce, dictionnaires innefficace, …)
norm wrote:
Ok mais avec connexion par mot de passe, comme proposé par Emmanuel et
le famous ssh -ND 8887 -p 22 toto@adresse ? A quel niveau se situe la
protection ?
Tout ce qui passe par le tunnel ssh est automatiquement crypté par le
client, transmis sur le réseau (de manière sécurisée donc) et décrypté par
le serveur.
Tous est sécurisé par défaut.
Et il vaut mieux privilégier les connexions par clef privée et désactiver
complètement les connexions par mot de passe, question de sécurité (pas de
bruteforce, dictionnaires innefficace, …)
Ok mais avec connexion par mot de passe, comme proposé par Emmanuel et le famous ssh -ND 8887 -p 22 ? A quel niveau se situe la protection ?
Tout ce qui passe par le tunnel ssh est automatiquement crypté par le client, transmis sur le réseau (de manière sécurisée donc) et décrypté par le serveur. Tous est sécurisé par défaut.
Et il vaut mieux privilégier les connexions par clef privée et désactiver complètement les connexions par mot de passe, question de sécurité (pas de bruteforce, dictionnaires innefficace, …)
Emmanuel Florac
Le Sat, 13 Nov 2010 21:36:17 +0100, norm a écrit:
Ok mais avec connexion par mot de passe, comme proposé par Emmanuel et le famous ssh -ND 8887 -p 22 ? A quel niveau se situe la protection ?
J'ai bien dit d'utiliser une clef et pas un mot de passe. Par précaution tu peux aussi autoriser seulement un ou deux utilisateurs dans la config du serveur ssh.
-- On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. Charles Babbage
Le Sat, 13 Nov 2010 21:36:17 +0100, norm a écrit:
Ok mais avec connexion par mot de passe, comme proposé par Emmanuel et
le famous ssh -ND 8887 -p 22 toto@adresse ? A quel niveau se situe la
protection ?
J'ai bien dit d'utiliser une clef et pas un mot de passe. Par précaution
tu peux aussi autoriser seulement un ou deux utilisateurs dans la config
du serveur ssh.
--
On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into
the machine wrong figures, will the right answers come out?' I am not
able rightly to apprehend the kind of confusion of ideas that could
provoke such a question.
Charles Babbage
Ok mais avec connexion par mot de passe, comme proposé par Emmanuel et le famous ssh -ND 8887 -p 22 ? A quel niveau se situe la protection ?
J'ai bien dit d'utiliser une clef et pas un mot de passe. Par précaution tu peux aussi autoriser seulement un ou deux utilisateurs dans la config du serveur ssh.
-- On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. Charles Babbage
Fabien LE LEZ
On Sat, 13 Nov 2010 20:21:51 +0100, Aeris :
ssh, y'a difficilement plus sécurisé
Il arrive qu'il soit sécurisé, effectivement.
Chez Debian, la sécurité a été très faible pendant quelques années, si je me souviens bien.
On Sat, 13 Nov 2010 20:21:51 +0100, Aeris <aeris@imirhil.fr>:
ssh, y'a difficilement plus sécurisé
Il arrive qu'il soit sécurisé, effectivement.
Chez Debian, la sécurité a été très faible pendant quelques années, si
je me souviens bien.
