je suis utilisateur linux et j'ai l'habitude d'administrer les machines à
distance via ssh. Ma mère vient d'avoir une live box en remplacement de son
ancien modem pour pouvoir bénéficier de la téléphonie. Et je n'arrive pas à
trouver dans leur interface quelque chose de logique pour autoriser tout
bêtement l'accès ssh sur les machines du lan.
Auriez vous une page web sous la main expliquant simplement :
comment ouvrir ssh (sur un por quelconque) pour mon ip fixe sur la liveboxe
orange;
comment translater cette connexion sur le port 22 d'une machine interne
je trouve partout des configurations lan pour les postes du réseau local,
mais je n'arrive pas trouver l'info pour me connecter via internet. La
liveboxe semble ignorer l'existence de ssh... :-\
Merci de me mettre sur la voie
> Alarch a écrit :
>> bonjour,
>>
>> je suis utilisateur linux et j'ai l'habitude d'administrer les machines à
>> distance via ssh. Ma mère vient d'avoir une live box en remplacement de
>> son ancien modem pour pouvoir bénéficier de la téléphonie. Et je n'arrive
>> pas à trouver dans leur interface quelque chose de logique pour autoriser
>> tout bêtement l'accès ssh sur les machines du lan.
>>
>> Auriez vous une page web sous la main expliquant simplement :
>>
>> comment ouvrir ssh (sur un por quelconque) pour mon ip fixe sur la
>> liveboxe orange;
>>
>> comment translater cette connexion sur le port 22 d'une machine interne
>>
>> je trouve partout des configurations lan pour les postes du réseau local,
>> mais je n'arrive pas trouver l'info pour me connecter via internet. La
>> liveboxe semble ignorer l'existence de ssh... :-\
>>
>> Merci de me mettre sur la voie
> Ce n'est pas dans "serveurs LAN" (j'ai une LiveBox Sagem 1.1).
> Je ne connais pas ssh, aors je dis peut-être une c..rie.
> C'est de quel niveau comme protocole (je veux dire c'est transporté par
> TCP ou UDP, ou bien c'est du même niveau) ?
> Didier.
SSH est un protocole de prise en main d'une machine à distance, tu peux
ouvrir une session dessus comme avec telnet, sauf que c'est crypté avec des
clés asymétriques, un cryptage fort. Tes connexions passent dans un tunnel
crypté. Et c'est du pur et dur tcp. Le port traditionnel est 22 mais tu
peux bien faire écouter ton démon ssh sur le port que tu veux. Souvent on
utilise 222 ou 8222 (ça évite les scans d'une grande partie des
scriptkiddies les moins évolués). Son avantage c'est que si tu utilises les
clés dsa ou rsa tu peux te connecter sans mot de passe de façon sécurisée.
Ça n'existe pas en natif dans le monde windows, chez microsoft il faut que
tu installes cygwin pour avoir ssh (pour pouvoir te connecter à ton poste
windows en utilisant ssh). Par contre depuis windows avec un logiciel qui
s'appelle putty, tu peux te connecter à un serveur unix en ssh.
Pourquoi teamwiever ne serait -il pas sᅵcurisᅵ ?
> C'est bien d'étaler sa culture sans la moindre approche de réponse à la
> question.
> C'est un problème de redirection du port 22.
> Chercher dans la documenatation de la livebox 'NAT' , redirection de
> ports. Peut être: http://assistance.orange.fr/2800.php?dub=1
eh eh ! c'est moi qui pose la question, je répondais seulement à
l'interrogation de quelqu'un à propos de ssh. Maintenant si j'ai à revenir
sur ce forum je ferai attention si c'est ainsi que les choses sont prises.
Bien entendu c'est une question de redirection de port, c'est bien ce que je
demande non ?
> Pardon?
> Teamviewer est 100 fois plus sûr que d'ouvrir un port SSH (et surtout
> le 22...)
>
> Il n'a besoin d'aucune ouverture de port, et il ne fonctionne que si tu
> lances le client, avec un mot de passe différent à chaque fois.
Je ne connais pas teawviewer, mais il faudra m'expliquer comment on peut se
connecter sans ouvrir aucun port... à moins que la connexion sont lancée
depuis derrière la livebox.
D'autre qu'est-ce qui te permet de dire qu'une connexion ssh pourrait être
100 fois plus dangereuse qu'un autre protocole ? Ce qui est un danger
potentiel c'est d'avoir un ou des ports ouverts sur Internet, quel que soit
le protocole. Et n'avoir aucune connexion à internet est encore plus sûr.
Ensuite je n'ai jamais dit que j'utilisais le port 22, j'ai même expliqué
pourquoi il vallait mieux déporter le port pour que les scanneurs bêtes ne
s'épuisent pas en tentative de connexion. Ensuite je configure le serveur
ssh pour qu'il n'accepte que ma clé dsa et aucune autre connexion, et
refuse systématiquement toute tentative de connexion par mot de passe.
Enfin je ne suis pas là pour discuter des mérites respectifs de ssh ou autre
chose, juste pour essayer de trouver une doc sur la façon dont la livebox
écrit ses règles d'accès...
Ceci dit, Teamviewer transite par un serveur tiers.
> OK, merci à vous deux.
> Et si tu ouvre le port 22 de TCP vers ton IP dans le LAN, dans la
> LiveBox, ça ne marche pas ?
> Pour ma part, étant assez ignorant de ces points là, j'utilise
> teamviewer (c'est sans doute tout sauf sécurisé).
> Didier.
J'ai regardé la doc de teamviewer, ça vise le même but que ssh, à la
différence près qu'il faut quelqu'un à l'autre bout pour lancer un
programme client. ssh fonctionne en serveur, on peut se connecter sur une
machine sur laquelle il n'y a pas d'utilisateur humain pour lancer un
client, c'est une utilisation un peu différente, c'est plus proche des
ligiciels de prise en main de bureau.
Ils disent qu'ils utilisent un cryptage DES comme SSL donc c'est crypté ou
cryptable. Mais il semble que si tu veux pouvoir te connecter à n'importe
quel moment il faille que tu laisses tourner le client sur la machine à
laquelle tu veux te connecter, donc c'est le même problème qu'avec le
serveur ssh.
Mais justement mon problème est d'ouvrir un port vers le lan (que ce soit 22
ou un autre).
Donc tu remet ta sᅵcuritᅵ entre les mains d'une tierce personne. Si une
faille de sᅵcuritᅵ existe sur le serveur de TV (mᅵme si cette faille n'a
rien ᅵ voir avec le protocole utilisᅵ) un attaquant compromettant ce
serveur pourrait potentiellement prendre la main sur toutes les machines
connectᅵes.
>
>> D'autre qu'est-ce qui te permet de dire qu'une connexion ssh pourrait
>> ᅵtre
>> 100 fois plus dangereuse qu'un autre protocole ? Ce qui est un danger
>> potentiel c'est d'avoir un ou des ports ouverts sur Internet, quel que
>> soit
>> le protocole. Et n'avoir aucune connexion ᅵ internet est encore plus
>> sᅵr.
>
> Port ouvert= brute force possible.
> Pas de port, pas de possibilitᅵ.
>
Je ne vois pas comment on pourrait faire un bruteforce sur une connexion
ssh correctement configurᅵe. Dᅵjᅵ, si on refuse les connexions root, il
faut non seulement faire un bruteforce sur le mot de passe, mais en plus
il faut connaᅵtre ou deviner au prᅵalable le nom du compte utilisateur
(et ssh n'indique pas si c'est le login ou le mot de passe qui est
erronᅵ, augmentant de fait les combinaisons possibles). Ensuite ssh
permet de se connecter avec un ᅵchange de clᅵ RSA ou DSA (donc sans
envoi de mot de passe) voire mᅵme ᅵ l'aide d'un certificat si les
besoins de sᅵcuritᅵ sont importants.
Accessoirement, rien ne dit qu'un bruteforce ne fonctionnerait pas sur TV.
Oui Didier, il me semble que c'est bien dans serveur lan.
Nom: SSH
Activ�: Oui
Protocole: TCP
Du port: 22
Au port: 22
Adresse IP locale: @IP_serveur_ssh
Par contre �a ne fait pas de redirection. On ouvre une plage de ports
uniquement.
T'es pas sur un forum ....
> Raminagrobis a écrit :
>> Port ouvert= brute force possible.
>> Pas de port, pas de possibilité.
>>
>
> Je ne vois pas comment on pourrait faire un bruteforce sur une connexion
> ssh correctement configurée. Déjà, si on refuse les connexions root, il
> faut non seulement faire un bruteforce sur le mot de passe, mais en plus
> il faut connaître ou deviner au préalable le nom du compte utilisateur
> (et ssh n'indique pas si c'est le login ou le mot de passe qui est
> erroné, augmentant de fait les combinaisons possibles). Ensuite ssh
> permet de se connecter avec un échange de clé RSA ou DSA (donc sans
> envoi de mot de passe) voire même à l'aide d'un certificat si les
> besoins de sécurité sont importants.
>
> Accessoirement, rien ne dit qu'un bruteforce ne fonctionnerait pas sur TV.
De toute façon comment parler de sécurité et encore pire de confidentialité
quand on passe par un serveur étranger dont on ne connaît rien, dont on
n'est pas administrateur... C'est à mon sens une vraie hérésie.
J'utilise ssh depuis des années, uniquement avec des clés DSA, sans
authentification par mot de passe possible, avec un accès root bloqué, et
sur un autre port que 22. Bien entendu la sécurité absolue n'existe pas,
mais sincèrement je suis plus soucieux pour mes serveurs faisant tourner un
serveur de courrier ou même un serveur web, là les risques sont présents,
que pour l'accès en ssh. Mes clés sont protégées par une
passphrase "sérieuse", même si on me volait mes machines personne ne
pourrait les utiliser pour se connecter sur mes serveurs.
Mais chacun fait ce qu'il veut et voit midi à sa porte. Si tu as confiance
en teamviewer, pourquoi pas. Les utilisateurs de windows ont bien confiance
dans des logiciels de pare-feu, qui sont de simples applications tournant
dans l'user space, dont rien ne prouve qu'ils voient passer tous les
paquets et dont le fonctionnement est opaque. Rien que parce que netfilter
est intégré au noyau linux, que le filtrage se fait dans le kernel space,
que rien ne peut transiter par la machine sans y échapper, cela me
convainquerait d'utiliser linux comme OS d'un point de vue sécurité. Et il
en va de même pour ssh comparé à des solutions tierces opaques comme ce
teamviewer.
Ah ? Vu le ton j'avais cru...
> Raminagrobis a écrit :
>> Didier a couché sur son écran :
>>> Alarch a écrit :
>>>> Didier wrote:
>>>>
>>>>> Alarch a écrit :
>>>>>> bonjour,
>>>>>>
>>>>>> je suis utilisateur linux et j'ai l'habitude d'administrer les
>>>>>> machines à
>>> Pour ma part, étant assez ignorant de ces points là, j'utilise
>>> teamviewer (c'est sans doute tout sauf sécurisé).
>>> Didier.
>>
>> Pardon?
>> Teamviewer est 100 fois plus sûr que d'ouvrir un port SSH (et surtout le
>> 22...)
>>
>> Il n'a besoin d'aucune ouverture de port, et il ne fonctionne que si tu
>> lances le client, avec un mot de passe différent à chaque fois.
>>
>>
> Teamviewer n'utilise que des ports sortants , ce qui est sécurisant , et
> laisse l'initiative de connexion au client.
>
> Ceci dit, Teamviewer transite par un serveur tiers.
Mes "clients" sont des serveurs, qui dont par définition ont peu
d'initiative. Ou alors il faudrait que je me connecte en ssh pour lancer le
client TV ;-)
Alarch a ᅵcrit :
> GuiGui wrote:
>
>> Je ne vois pas comment on pourrait faire un bruteforce sur une connexion
>> ssh correctement configurᅵe.
On peut toujours faire un bruteforce. Qu'il ait des chances de rᅵussir,
c'est une autre affaire.
> De toute faᅵon comment parler de sᅵcuritᅵ et encore pire de confidentialitᅵ
> quand on passe par un serveur ᅵtranger dont on ne connaᅵt rien, dont on
> n'est pas administrateur... C'est ᅵ mon sens une vraie hᅵrᅵsie.
Bah, c'est une question de confiance.
> Les utilisateurs de windows ont bien confiance
> dans des logiciels de pare-feu, qui sont de simples applications tournant
> dans l'user space,
C'est sᅵr ? Il n'y a pas un "pilote" qui tourne en espace noyau, seule
l'interface utilisateur tournant en espace utilisateur ?
> Rien que parce que netfilter
> est intᅵgrᅵ au noyau linux, que le filtrage se fait dans le kernel space,
> que rien ne peut transiter par la machine sans y ᅵchapper,
Un programme peut court-circuiter netfilter en communicant directement
avec une interface rᅵseau plutᅵt que via la pile TCP/IP. C'est ce que
font les programmes clients et serveurs DHCP ou de capture de paquets
par exemple.
>> Les utilisateurs de windows ont bien confiance
>> dans des logiciels de pare-feu, qui sont de simples applications tournant
>> dans l'user space,
> C'est sûr ? Il n'y a pas un "pilote" qui tourne en espace noyau, seule
> l'interface utilisateur tournant en espace utilisateur ?
Je ne sais pas exactement, comme on n'a pas le code de ces logiciels
difficile d'avoir le fin mot de l'histoire.
> Un programme peut court-circuiter netfilter en communicant directement
> avec une interface réseau plutôt que via la pile TCP/IP. C'est ce que
> font les programmes clients et serveurs DHCP ou de capture de paquets
> par exemple.
oui on peut "écouter" les trames réseau d'une interface, c'est certain, d'où
la nécessité du cryptage des paquets réseau quand les données sont
sensibles, que je sache dhcp est un protocole client serveur, on peut très
bien bloquer dhcp par netfilter en bloquant son port, il ne cour-circuite
pas netfilter.
Mᅵme sans le code source on peut examiner les fichiers qu'ils
installent, et voir s'il y a un pilote dans le lot, comme un .sys.
>> Un programme peut court-circuiter netfilter en communicant directement
>> avec une interface rᅵseau plutᅵt que via la pile TCP/IP. C'est ce que
>> font les programmes clients et serveurs DHCP ou de capture de paquets
>> par exemple.
>
> oui on peut "ᅵcouter" les trames rᅵseau d'une interface,
Ecouter et ᅵmettre, on peut donc communiquer de faᅵon bidirectionnelle.
> que je sache dhcp est un protocole client serveur, on peut trᅵs
> bien bloquer dhcp par netfilter en bloquant son port,
Non, pas si le logiciel communique directement avec l'interface.
D'expᅵrience, c'est le cas des client et serveur DHCP d'ISC qui sont
parmi les plus utilisᅵs dans les distributions GNU/Linux.
> il ne court-circuite pas netfilter.
Si, si le logiciel communique directement avec l'interface.