Journal Un émulateur de terminal en AJAX...

Posté par  (site web personnel) .
Étiquettes : aucune
0
29
mai
2006
Sûrement il vous est déjà arrivé de vouloir vous connecter à votre machine Linux depuis un ordinateur au boulot/université/cybercafé/etc... et vous rendre compte que celui-ci se trouve derrière un proxy qui n'autorise que l'HTTP/HTTPS... impossible d'utiliser votre accès SSH dans ces conditions...

Pire encore, l'ordi sous Zindoz est tout bridé et n'autorise aucun bidouillage/installation de logiciels... vous n'avez acces qu'à un pauvre navigateur...

Tout n'est pas perdu ! J'ai trouvé le petit programme ultime : AjaxTerm ! Comme son nom l'indique il s'agit ni plus ni moins d'un émulateur de terminal en Ajax... et ecrit en Python en plus..!

C'est totalement redoutable tellement c'est simple et ca marche. Il suffit de lancer le script, et hop, directement de n'importe ou dans le monde on peut acceder a un terminal de sa machine directement depuis le navigateur, sans aucune installation nécessaire... Excellentissime et ultra pratique...

Bien sur, comme le site l'indique, le mieux reste de se générer un certificat SSL et d'utiliser ajaxterm en HTTPs... et c'est parfait et "secure" :).

Le site : http://antony.lesuisse.org/qweb/trac/wiki/AjaxTerm

  • # "secure"

    Posté par  . Évalué à 2.

    sûr ?

    ­La faculté de citer est un substitut commode à l'intelligence -- Somerset Maugham

    • [^] # Re: "secure"

      Posté par  (site web personnel) . Évalué à 9.

      En https, configuré pour n'accepter que ton certificat, c'est pas mal, oui.

      Maintenant, le problème de ces solutions "VPN-like" (et je met ssh dedans) c'est qu'on ouvre un pont entre deux réseaux qui n'étaient pas faits pour travailler ensemble à la base. Donc c'est un bon moyen pour les virus de passer et de s'étendre : en gros, si une machine est compromise, il est relativement aisé de compromettre l'autre. Tu as donc intérêt à être sûr de tes deux machines.

      Sans compter que tu outrepasse la politique de sécurité de ton entreprise et que suivant comment elles sont, tu peux te retrouver à la porte pour avoir fait un truc pareil.

      • [^] # Re: "secure"

        Posté par  . Évalué à 7.

        je pense que la question portait plus sur le barbarisme/anglicisme que sur le côté sécurité...

        en même temps ta réponse est bonne, donc je "pertinentise" !

      • [^] # Re: "secure"

        Posté par  (site web personnel) . Évalué à 7.

        Se faire virer?? l'entreprise n'autorise pas le port 22 sur son proxy mais autorise le http et https. Toi, utilisateur lambda, tu utilise une connexion https pour te connecteur sur ton propre serveur web, qui celà dit en passant est un serveur public comme un autre. En quoi est ce illégal vis à vis de la charte de l'entreprise?
        Si on te permets de surfer en https, je ne pense pas qu'on puisse te virer au motif que tu le fait pour te connecter sur un serveur si peu différent de n'importe quel autre... A ce moment là autant te virer dès que tu visite n'importe site web en ajax, ou n'importe quel webmail (le principe dans la théorie est le meme, appli tournant sur un serveur web permettant de te connecter sur le port pop ou imap de la-dite machine).

        Bref, j'y crois pas trop.

        • [^] # Re: "secure"

          Posté par  . Évalué à 4.

          En quoi est ce illégal vis à vis de la charte de l'entreprise?


          Si la charte de ton entreprise dit un truc du genre "l'accès internet sur les postes de l'entreprise est réservé à un usage strictement professionnel", ben je suis pas sur que te connecter a ta box pour faire de l'IRC, lire tes mails | logs, lancer tes aptitude upgrade |emerge world ou mater un divx avec aaxine rentre dans cette catégorie.

          A ce moment là autant te virer dès que tu visite n'importe site web en ajax, ou n'importe quel webmail


          J'ai bossé dans une centre de recherche français à la sécurité paranoïaque ou l'usage d'un webmail depuis le réseau interne était strictement interdit.

          • [^] # Re: "secure"

            Posté par  . Évalué à 6.

            Mater un divx avec aaxine en passant par une console ajax, voila qui mérite d'être essayé... Mais pas nécessairement depuis le boulot :-P

          • [^] # Re: "secure"

            Posté par  (site web personnel) . Évalué à 2.

            Si la charte de ton entreprise dit un truc du genre "l'accès internet sur les postes de l'entreprise est réservé à un usage strictement professionnel", ben je suis pas sur que te connecter a ta box pour faire de l'IRC, lire tes mails | logs, lancer tes aptitude upgrade |emerge world ou mater un divx avec aaxine rentre dans cette catégorie.


            Ce n'est pas si simple.

            La jurisprudence sur ce sujet est clair. A partir du moment ou un outil technique est fourni aux salariés, l'usage privé est toléré, et ne peux en aucun cas être motif de licenciement. Sauf si ça nuit de manière avéré à ton travail. C'est la même chose pour le téléphone ou pour la messagerie électronique.

            Maintenant, détourner l'usage d'un outil de manière illicite, en mettant en danger la sécurité de l'entreprise, peut être considéré comme une faute grave et alors entrainer un licenciement. Mais il va falloir le prouver et argumenter.

            • [^] # Re: "secure"

              Posté par  . Évalué à 2.

              Il me semble que c'est le coté "utilisation urgente et ponctuelle" qui est tolérée de facto. Ensuite la charte informatique est la pour dicter ce qui est (ou non) toléré par l'entreprise, et celles qu'il m'a été donné de lire stipulent justement qu'elles respectent la loi et permettent les utilisations ponctuelles et urgentes.

              Par exemple l'entreprise ne pourra pas te mettre a la porte si tu passe des coups de fil privés parceque ton gosse est malade, t'es à découvert et t'appelle ton banquier, ... c'est le caractère de nécéssité qui prévaut.
              Si le but c'est de travailler sur des affaires personnelles depuis le boulot en se loggant sur ta machine de la maison, ... faudra prouver le "ponctuel" et "urgent" :-)

              • [^] # Re: "secure"

                Posté par  . Évalué à 1.

                Moi je pense que tu ne peux être viré pour ça (usage privé) sauf si il y a un tord avéré pour l'entreprise (genre introduction d'un virus).
                Par contre là où je bosse, c'est plus simple, ils ne te virent pas, ils te retirent l'accès internet.

        • [^] # Re: "secure"

          Posté par  . Évalué à 0.

          Si on te permets de surfer en https


          Mais comme on ne nous permet pas de surfer, meme en https...

          En general, internet est accessible en tant qu'outil de travail. Se connecter chez soi n'est a priori pas pour le travail. Et si c'etait quand meme pour le travail, l'employeur doit permettre une connexion directe entre le boulot et chez soi. Pas besoin d'ajaxterm dans ce cas. Et si l'employeur refuse, bah c'est simple, vous vous passez de l'outil, et l'employeur assume la perte de temps et la baisse de qualite de votre boulot. On n'a pas rien sans rien.

          Enfin, en "surfant" avec ajaxterm, vous risquez de vous faire remarquer surtout parce que vous passez du temps dessus au lieu de bosser pour l'employeur. C'est pas bien du tout.
          De plus, ajaxterm est un intermediaire entre deux reseaux, qui insere donc des failles dans les protections du systeme d'information de l'entreprise. Si un probleme survenait dans ce systeme d'information, vous et votre ajaxterm seriez probablement reperes et la, c'est a la discretion de l'employeur...

          Le bonjour chez vous,
          Yves

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 7.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: "secure"

          Posté par  (site web personnel) . Évalué à 2.

          > Par ailleurs, AjaxTerm n'a strictement rien à voir avec un VPN : là on parle de
          > HTTP (non connecté par définition), d'échange de sortie d'écran et de saisies
          > clavier. De là à dire que ça correspond à un VPN du style SSH ...

          ... il n'y a qu'un pas !

          Techniquement, c'est compliqué à implémenter, mais théoriquement, ça ne pose pas de difficulté. Tu écris un programme, disons A, qui se comporte comme un navigateur du point de vue du serveur AjaxTerm, mais non interactif. A envoie quelques commandes pour lancer un demon B sur le serveur qui fait tourner AjaxTerm (genre "wget http://mon-site.com/mon-troyen; ./mon-troyen"). Le petit démon B en question peut être un sshd à peine modifié, pour recevoir ses ordres dans stdin et envoyer les données par stdout. Ton programme A se comporte alors comme un client ssh, et B comme le serveur ssh, et tu peux implémenter tout ce que tu faisais avec ssh à travers ton AjaxTerm (avec des performances lamentables, mais bon), y compris le forward de port.

          Bref, tu peux très bien implémenter un VPN over AjaxTerm.

          Par contre, si la machine avec AjaxTerm est compromise, à priori, ça ne lui donne aucun moyen de compromettre le client.

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 3.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: "secure"

              Posté par  (site web personnel) . Évalué à 1.

              > c'est ton programme A qui peut l'être.

              Là, on parle de sécurité. Le programme A, ça peut très bien être un virus ou n'importe quoi que tu ne controles pas.

              > D'ailleurs ton programme A peut directement se connecter sur ta machine distante sans AjaxTerm

              Ben, là, il est question de contourner les politiques de sécurité, les VPN, toussa, donc, non, le programme A, il ne peut pas se connecter directement.

              (hint: google, firewall, proxy, et revient en parler un peu après si tu veux).

        • [^] # Re: "secure"

          Posté par  (site web personnel) . Évalué à -3.

          > Par ailleurs, AjaxTerm n'a strictement rien à voir avec un VPN : là on parle de
          > HTTP (non connecté par définition), d'échange de sortie d'écran et de saisies
          > clavier. De là à dire que ça correspond à un VPN du style SSH ...

          ... il n'y a qu'un pas !

          Techniquement, c'est compliqué à implémenter, mais théoriquement, ça ne pose pas de difficulté. Tu écris un programme, disons A, qui se comporte comme un navigateur du point de vue du serveur AjaxTerm, mais non interactif. A envoie quelques commandes pour lancer un demon B sur le serveur qui fait tourner AjaxTerm (genre "wget http://mon-site.com/mon-troyen; ./mon-troyen"). Le petit démon B en question peut être un sshd à peine modifié, pour recevoir ses ordres dans stdin et envoyer les données par stdout. Ton programme A se comporte alors comme un client ssh, et B comme le serveur ssh, et tu peux implémenter tout ce que tu faisais avec ssh à travers ton AjaxTerm (avec des performances lamentables, mais bon), y compris le forward de port.

          Bref, tu peux très bien implémenter un VPN over AjaxTerm.

          Par contre, si la machine avec AjaxTerm est compromise, à priori, ça ne lui donne aucun moyen de compromettre le client.

  • # Y'a aussi anyterm...

    Posté par  (site web personnel) . Évalué à 9.

    ...qui est un module d'apache qu'il le fait bien aussi. Pareil il s'appuie sur de l'AJAX.

    http://anyterm.org/

    Le plus a mon avis c'est de pouvoir continuer à avoir un site web normal sur le port 80 et anyterm sans rentrer dans une configuration trop sioux d'apache.

  • # sslexplorer ?

    Posté par  . Évalué à 4.

    Il existe aussi sslexplorer (http://sourceforge.net/projects/sslexplorer/) dans le même esprit.

  • # Mais on peut faire plus que du ssh avec

    Posté par  (site web personnel) . Évalué à 4.

    J'ai aussi découvert le soft sute à un poste sur un blog ( http://nawer.freecontrib.org/index.php?2006/05/24/203-ajaxte(...) ), et franchement, il est bien plus facile à installer et à packager que mod_anyterm ( la preuve, j'ai fait le paquet pour mandriva cooker le soir même ).

    Ce dernier m'a posé des problémes de compilation, d'abord vis à vis de mon serveur en amd64 ( réglé avec la version 1.1 ), puis, vis à vis de apache 2.2, ce qui le rends peu pratique pour moi.
    C'est en cours de résolution d'aprés ce que j'ai compris, j'ai que à attendre

    Mais le plus fort dans ce genre de systéme, c'est qu'on peut convertir des softs consoles en softs web. Par exemple,faire comme ce que j'ai fait, mettre un client telnet qui se connecte à un mud ( http://multimud.homeip.net/ ).

    Une interface web est bien plus simple pour ce genre de choses que de faire installer une jvm, de faire lancer une applet finalement un peu lourde pour pas grand chose, et qui de toute façon passeras peut être pas les firewalls.

    Bon, bien sur, ça reste quand même trés spécialisé, mais je suis sur qu'on peut faire des tonnes de trucs sympas avec ça.

    Convertir une vielle appli dos en appli manageable via un navigateur, un webmail basé sur mutt, etc.

  • # J'ai pas tout pige...

    Posté par  . Évalué à 0.

    Ca s'installe sur le serveur et pouf on traverse les proxys ?

    Quelqu'un peut me faire un howto (tres succint et rapide) sur le comment on installe ca ?

    /me est vraiment intersse :)

    • [^] # Re: J'ai pas tout pige...

      Posté par  . Évalué à 1.

      Bon en fait c'est tres simple :) J'ai un peu honte.

      C'est vraiment puissant et sympa. Depuis le temps que je reflechis au comment traverser le proxy...

      J'avais a une epoque mis un webmin avec le module webconsole mais c'etait pas trop ca :)

      La c'est plutot cool.

      • [^] # Re: J'ai pas tout pige...

        Posté par  (site web personnel) . Évalué à 2.

        http://www.google.com/search?q=corkscrew+ssh+https

        C'est bien plus efficace pour faire du ssh-over-https avec proxy.

        Mais c'est probablement très limite par rapport à la charte d'utilisation des moyens informatiques de ta boite.

        • [^] # Re: J'ai pas tout pige...

          Posté par  (site web personnel) . Évalué à 2.

          J'ai été voir la page de corkscrew que je trouve assez succinte... c'est quoi la différence entre corkscrew et faire tourner le démon ssh chez soi sur le port 443 ?

          • [^] # Re: J'ai pas tout pige...

            Posté par  (site web personnel) . Évalué à 2.

            C'est juste de passer à travers le proxy de ton côté, et c'est effectivement un hack relativement trivial. Mais de l'autre côté, oui, c'est un ssh qui tourne sur le port 443.

            • [^] # Re: J'ai pas tout pige...

              Posté par  (site web personnel) . Évalué à 2.

              Alors quelle est la différence entre corkscrew et un autre client ssh normal (ssh ou putty, par exemple) ?

              • [^] # Re: J'ai pas tout pige...

                Posté par  (site web personnel) . Évalué à 4.

                Si tu as un firewall entre toi et la machine cible, tu peux toujours essayer de faire un ssh, ça ne marchera pas, il sera bloqué par le firewall. Ce qu'il te faut pour passer à travers le firewall via le proxy, c'est un truc qui se connecte au proxy, et qui lui demande dans le langage des proxys de se connecter à ta machine.

                Là, l'astuce, c'est qu'il faut demander au proxy d'établir une connection HTTPS, et en HTTPS, le proxy n'a aucun contrôle sur le contenu (sinon, ça serait une attaque man-in-the-middle), donc, tu peux bien faire passer du ssh à la place du HTTP chiffré, le proxy n'y voit que du feu. Une fois la connection établie, donc, au lieu d'envoyer les paquets directement a la machine vers laquelle tu te connecte, tu les envoies au proxy, et tu recoit de lui.

                Corkscrew n'est pas un client ssh, c'est juste un tout petit programme qui fait la bidouille décrite ci-dessus, et tu configures ton OpenSSH pour utiliser corkscrew pour établir la connection. C'est en plus, pas à la place de.

  • # et en XUL ?

    Posté par  . Évalué à -2.

    ça existe pas en XUL ?
    Parce que l'AJAX c'est très lourd, ça surcharge les réseaux, et c'est pire que les raw sockets de Windows XP : ça va faire crouler Internet.

    • [^] # Re: et en XUL ?

      Posté par  . Évalué à 10.

      Y'a quelqu'un qui recherche un développeur, mais il trouve pas.

    • [^] # Re: et en XUL ?

      Posté par  (site web personnel) . Évalué à 6.

      Il dit qu'il ne voit pas le rapport.

      XUL ici viendrait remplacer la partie HTML du bidule, sans aucune modification de ce qu'il y a derrière.

      XUL ne va pas magiquement transformer le trafic HTTP utilisé pour faire passer les commandes, et qui, oui, est nécessairement très lourd avec de nombreuses requêtes, en un nouveau protocole super optimisé.

      AJAX ne veut vraiment pas dire grand chose, au final, c'est juste "requêtes HTTP faites par une commande javascript", ce qui, avec une solution où l'affichage serait basé sur du XUL, serait strictement identique.

  • # En pratique

    Posté par  . Évalué à 0.

    Il y a pas quelqu'un qui à (ou qui veux) installer ça sur son server et nous passer l'adresse pour qu'on teste ?

    • [^] # Re: En pratique

      Posté par  . Évalué à 2.

      En même temps, avec 10s de temps libre, tu télécharge le tar.gz, tu installe ça sur n'importe quel linux avec python2.3 et tu testes.

      Ca a le mérite de ne pas te limiter dans tes manipulation (tu as tes droits à toi) et de ne pas demander à quelqu'un de prendre les 10 secondes à ta place + l'heure de config pour être sur de ne pas ouvrir de backdoor à n'importe qui en leur filant un compte local sur sa machine (et encore.... une heure je suis gentil).

    • [^] # Re: En pratique

      Posté par  (site web personnel) . Évalué à 3.

      J'ai fait un tutorial puor installer ce petit truc ici : http://smhteam.info/wiki/index.linux.php5?wiki=AjaxTerm
      Pour la partie installation d'apache (il vaut mieux utiliser apache 2) il y a ça aussi : http://smhteam.info/wiki/index.linux.php5?wiki=ServeurWebAve(...)

      ça marche nickel chez moi ! Et c'est bien pratique au final :)

      • [^] # Re: En pratique

        Posté par  (site web personnel) . Évalué à 3.

        fritz_smh > héhéhé ! Au fait, juste comme ça, dans le screenshot en bas, t'as flouté ton IP dans la barre d'adresse mais pas dans la barre d'état :D !

        • [^] # Re: En pratique

          Posté par  (site web personnel) . Évalué à 1.

          ah le boulet que je fais... merci d'avoir prévenu :)

          et je re confirme, ça marche vraiment bien... pas très rapide, (loin derrière une connection ssh classique en terme de réactivité au clavier), mais c'ets du pareil au même sinon.

  • # Pour aller un poil plus loin

    Posté par  (site web personnel) . Évalué à 3.

    J'ai ecrit^Wadapté un script de demarrage pour pouvoir lancer son ajaxterm dès l'allumage de sa machine (à placer dans /etc/init.d/ et update-rc.d le tout donc)
    Si vous pouviez me dire ce que vous en pensez :)


    #!/bin/bash

    NAME=$(basename "$0")
    PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
    DAEMON=/chemin/vers/ajaxterm.py
    DESC=ajaxterm
    PORT=8000

    test -x "$DAEMON" || exit 0
    case "$1" in
    start)
    echo -n "Starting $DESC: "
    $DAEMON -p $PORT -d
    echo "$NAME lance."
    ;;
    stop)
    echo -n "Stopping $DESC: "
    kill `cat /var/run/ajaxterm.pid`
    echo "$NAME stoppe."
    ;;
    restart)
    /etc/init.d/ajaxterm stop
    /etc/init.d/ajaxterm start
    ;;
    *)
    printf "Usage: %q {start|stop|restart}\n" "$0" >&2
    exit 1
    ;;
    esac

    exit 0

  • # proxy avec filtrage d'URL

    Posté par  . Évalué à 1.

    Mon commentaire a un rapport assez lointain avec le sujet, mais, serais-je le seul a être dans une boîte qui a mis en place un proxy qui n'autorise pas l'accès à tous les URL (et en particuliers ceux en dyndns.org, considérés comme « personnal website ») ?

    Je précise que, bien entendu, le proxy est suffisamment intelligent pour bloquer les accès même si on passe une adresse IP au lieu d'un nom (j'ai testé avec webmail.free.fr).

    • [^] # Re: proxy avec filtrage d'URL

      Posté par  . Évalué à 1.

      chez nous le filtrage est aléatoire (on a pas accès au site d'ibm, mais à quelques sites entierement dédié au jeu, alors qu'ibm est un fournisseur...), le ssl est totalement bloqué, mais le dyndns marche :)

      ajaxterm c'est genial, bon après faut pas en abuser, il faut faire son travail. Sur ce ...

    • [^] # Re: proxy avec filtrage d'URL

      Posté par  . Évalué à 2.

      chez nous il n'empêche pas les accès mais trace les accès. La RH regarde ensuite le top des temps estimés de connexion, et les connexions vers des sites interdits (chez nous : webmail, météo, bourse...)

    • [^] # Re: proxy avec filtrage d'URL

      Posté par  . Évalué à 2.

      Et bien ca a mon gout c'est tres tres nul !

      Ayant deja eu a consulter une page qui etait bloquée car en dyndns, j'ai trouvé ca tres frustrant surtout quand on sait que pleins de ce genre de pages sont des pages de developpeurs (par exemple) qui mettent leurs travaux dessus (et travaux dont j'ai besoin pour mon travail).

      • [^] # Re: proxy avec filtrage d'URL

        Posté par  . Évalué à 2.

        Voyons, il est bien connu que ceux qui ont des sites personnels en dyndns.org sont au mieux des amateurs dépourvus de professionalisme, au pire des dangereux pirates, et que...

        ...oh, joie! Alors que je viens de cliquer sur ce genre de lien ( http://chezlionel.dyndns.org/modules/news/ ) dans google pour obtenir les termes exacts du message de mon proxy, je m'aperçois que ce dernier m'autorise à y accéder!

  • # Package Archlinux

    Posté par  . Évalué à 1.

    Le PKBUILD Archlinux est dispo sur http://aur.archlinux.org/.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.