Titi exécute sous Mandriva les serveurs sshd et x11vnc. Nous avons échangé
nos clefs et je me connecte en ssh sans difficulté depuis mon domicile,
éloigné du sien. Les choses se gâtent quand je tente de me connecter avec
vnc, mon client vncviewer étant celui de tightvnc :
$ vncviewer -encodings 'copyrect tight hextile' -via titi@79.94.190.xxx
127.0.0.1:0
Enter passphrase for key '/home/geo/.ssh/id_dsa':
Connected to RFB server, using protocol version 3.8
Performing standard VNC authentication
Et ça s'arrête là. Je m'attendrais à être invité à saisir le mot de passe
que je connais parfaitement mais non, pas la moindre invite. Je peux taper
du texte, ça n'a aucun effet. En ssh, je peux vérifier qu'un processus
x11vnc est toujours vivant chez titi. Quelqu'un a une idée ?
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
moi-meme
Le Sat, 09 Apr 2011 23:07:30 +0200, geo cherchetout a écrit :
Titi exécute sous Mandriva les serveurs sshd et x11vnc. Nous avons échangé nos clefs et je me connecte en ssh sans difficulté depuis mon domicile, éloigné du sien. Les choses se gâtent quand je tente de me connecter avec vnc, mon client vncviewer étant celui de tightvnc :
Presque HS : puisque ta liaison en ssh marche tu peux essayer sshfs pour monter le système de fichier distant ou ssh -Y pour faire une connection X (avec des problèmes de sécurité à analyser).
Le Sat, 09 Apr 2011 23:07:30 +0200, geo cherchetout a écrit :
Titi exécute sous Mandriva les serveurs sshd et x11vnc. Nous avons
échangé nos clefs et je me connecte en ssh sans difficulté depuis mon
domicile, éloigné du sien. Les choses se gâtent quand je tente de me
connecter avec vnc, mon client vncviewer étant celui de tightvnc :
Presque HS :
puisque ta liaison en ssh marche tu peux essayer sshfs pour monter le
système de fichier distant ou ssh -Y pour faire une connection X (avec
des problèmes de sécurité à analyser).
Le Sat, 09 Apr 2011 23:07:30 +0200, geo cherchetout a écrit :
Titi exécute sous Mandriva les serveurs sshd et x11vnc. Nous avons échangé nos clefs et je me connecte en ssh sans difficulté depuis mon domicile, éloigné du sien. Les choses se gâtent quand je tente de me connecter avec vnc, mon client vncviewer étant celui de tightvnc :
Presque HS : puisque ta liaison en ssh marche tu peux essayer sshfs pour monter le système de fichier distant ou ssh -Y pour faire une connection X (avec des problèmes de sécurité à analyser).
geo cherchetout
Le 09/04/2011 23:07, *geo cherchetout* a écrit :
$ vncviewer -encodings 'copyrect tight hextile' -via 127.0.0.1:0 Enter passphrase for key '/home/geo/.ssh/id_dsa': Connected to RFB server, using protocol version 3.8 Performing standard VNC authentication
Et ça s'arrête là.
Naturellement, chez titi, x11vnc est lancé avec l'option -usepw. Par acquit de conscience, il a remplacé cette option par -nopw mais le problème subsiste. La seule différence est que je reste en suspend sur « No authentication required » au lieu de « Performing standard VNC authentication ».
Le 09/04/2011 23:07, *geo cherchetout* a écrit :
$ vncviewer -encodings 'copyrect tight hextile' -via titi@79.94.190.xxx
127.0.0.1:0
Enter passphrase for key '/home/geo/.ssh/id_dsa':
Connected to RFB server, using protocol version 3.8
Performing standard VNC authentication
Et ça s'arrête là.
Naturellement, chez titi, x11vnc est lancé avec l'option -usepw. Par acquit
de conscience, il a remplacé cette option par -nopw mais le problème
subsiste. La seule différence est que je reste en suspend sur « No
authentication required » au lieu de « Performing standard VNC authentication ».
$ vncviewer -encodings 'copyrect tight hextile' -via 127.0.0.1:0 Enter passphrase for key '/home/geo/.ssh/id_dsa': Connected to RFB server, using protocol version 3.8 Performing standard VNC authentication
Et ça s'arrête là.
Naturellement, chez titi, x11vnc est lancé avec l'option -usepw. Par acquit de conscience, il a remplacé cette option par -nopw mais le problème subsiste. La seule différence est que je reste en suspend sur « No authentication required » au lieu de « Performing standard VNC authentication ».
geo cherchetout
Le 10/04/2011 09:32, *moi-meme* a écrit fort à propos :
Presque HS : puisque ta liaison en ssh marche tu peux essayer sshfs pour monter le système de fichier distant
Pas très utile pour aider Titi dans son apprentissage. (Entre nuls, faut bien s'entraider ;-))
ou ssh -Y pour faire une connection X (avec des problèmes de sécurité à analyser).
Ce que j'essaie de faire me semble présenter un maximum de sécurité puisque, si je comprends bien, toutes les données échangées le sont à travers une connexion ssh initiée par ma commande. De plus, ça marchait parfaitement alors que l'ordinateur de Titi était dans mon réseau local et que seul son port ssh était ouvert. Aujourd'hui sa configuration n'a pas changé et le port ssh est « naté » dans sa neufbox en faveur de son pc. Y'a sûrement juste un tout petit quelque chose qui cloche là-dedans, j'y retourne immédiatement.
Le 10/04/2011 09:32, *moi-meme* a écrit fort à propos :
Presque HS : puisque ta liaison en ssh marche tu peux essayer sshfs pour
monter le système de fichier distant
Pas très utile pour aider Titi dans son apprentissage. (Entre nuls, faut
bien s'entraider ;-))
ou ssh -Y pour faire une connection X (avec des problèmes de sécurité à
analyser).
Ce que j'essaie de faire me semble présenter un maximum de sécurité puisque,
si je comprends bien, toutes les données échangées le sont à travers une
connexion ssh initiée par ma commande. De plus, ça marchait parfaitement
alors que l'ordinateur de Titi était dans mon réseau local et que seul son
port ssh était ouvert. Aujourd'hui sa configuration n'a pas changé et le
port ssh est « naté » dans sa neufbox en faveur de son pc.
Y'a sûrement juste un tout petit quelque chose qui cloche là-dedans, j'y
retourne immédiatement.
Le 10/04/2011 09:32, *moi-meme* a écrit fort à propos :
Presque HS : puisque ta liaison en ssh marche tu peux essayer sshfs pour monter le système de fichier distant
Pas très utile pour aider Titi dans son apprentissage. (Entre nuls, faut bien s'entraider ;-))
ou ssh -Y pour faire une connection X (avec des problèmes de sécurité à analyser).
Ce que j'essaie de faire me semble présenter un maximum de sécurité puisque, si je comprends bien, toutes les données échangées le sont à travers une connexion ssh initiée par ma commande. De plus, ça marchait parfaitement alors que l'ordinateur de Titi était dans mon réseau local et que seul son port ssh était ouvert. Aujourd'hui sa configuration n'a pas changé et le port ssh est « naté » dans sa neufbox en faveur de son pc. Y'a sûrement juste un tout petit quelque chose qui cloche là-dedans, j'y retourne immédiatement.
geo cherchetout
Le 20/04/2011 15:22, *geo cherchetout* a écrit :
De plus, ça marchait parfaitement alors que l'ordinateur de Titi était dans mon réseau local et que seul son port ssh était ouvert. Aujourd'hui sa configuration n'a pas changé et le port ssh est « naté » dans sa neufbox en faveur de son pc.
Problème résolu : Dans les neufbox il n'existe pas de règles de NAT préfabriquées pour telle ou telle application, on crée chaque règle à la main et il est facile de se tromper. Par exemple en créant une règle pour le seul protocole TCP au lieu de TCP + UDP...
Le 20/04/2011 15:22, *geo cherchetout* a écrit :
De plus, ça marchait parfaitement alors que l'ordinateur de Titi était
dans mon réseau local et que seul son port ssh était ouvert. Aujourd'hui
sa configuration n'a pas changé et le port ssh est « naté » dans sa
neufbox en faveur de son pc.
Problème résolu : Dans les neufbox il n'existe pas de règles de NAT
préfabriquées pour telle ou telle application, on crée chaque règle à la
main et il est facile de se tromper. Par exemple en créant une règle pour le
seul protocole TCP au lieu de TCP + UDP...
De plus, ça marchait parfaitement alors que l'ordinateur de Titi était dans mon réseau local et que seul son port ssh était ouvert. Aujourd'hui sa configuration n'a pas changé et le port ssh est « naté » dans sa neufbox en faveur de son pc.
Problème résolu : Dans les neufbox il n'existe pas de règles de NAT préfabriquées pour telle ou telle application, on crée chaque règle à la main et il est facile de se tromper. Par exemple en créant une règle pour le seul protocole TCP au lieu de TCP + UDP...