Skip to content

un terminal web : Ajaxterm

   

Toutes les personnes ayant laissé tourner un serveur ssh sur son port par défaut sur Internet vous le diront, les logs ne sont pas très beau à voir :-)

Il y a un nombre de tentatives de connexion assez impressionant réalisé par des programmes automatisés. Une solution élégante que j’ai trouvé est l’installation d’ajaxterm qui permet d’accéder à un terminal à partir de son serveur web et ce sans installer aucune partie cliente sur son poste(il y a un indice sur la technologie utilisée dans le nom du logiciel ;-).

Installation d’Ajaxterm

Voilà un des points que j’adore dans ce logiciel, on peut difficilement faire une installation plus simple.

Ces pré-requis sont juste que python 2.3 au moins soit installer. C’est le cas sur la plupart des distributions linux.

Les commandes ci-dessous sont réalisés sur une distribution Ubuntu.

Il suffit de le télécharger sur le site qweb. La dernière version est la 0.10. Ensuite on le décompresse dans un répertoire de travail :

tar -zxvf Ajaxterm-0.10.tar.gz
Il suffit ensuite de le lancer en background
cd Ajaxterm-0.10
./ajaxterm.py -d

j’admet que la démonstration ci-dessus est la version rapide. Le logiciel permet une installation propre en lançant configure qui permet de spécifier l’endroit où l’on désire l’installer et le port d’écoute.

Par défaut, il écoute sur le port 8022 sur localhost uniquement.

# ./configure
Configuring prefix= /usr/local port= 8022
# make install
install -d "/usr/local/bin"
install -d "/usr/local/share/ajaxterm"
install ajaxterm.bin "/usr/local/bin/ajaxterm"
install ajaxterm.initd "/etc/init.d/ajaxterm"
install -m 644 ajaxterm.css ajaxterm.html ajaxterm.js qweb.py sarissa.js sarissa
_dhtml.js "/usr/local/share/ajaxterm"
install -m 755 ajaxterm.py "/usr/local/share/ajaxterm"
gzip --best -c ajaxterm.1 > ajaxterm.1.gz
install -d "/usr/local/share/man/man1"
install ajaxterm.1.gz "/usr/local/share/man/man1"

Quelques distributions linux le proposent même en package(debian SID au moins).

configuration d’apache 2

Comme conseillé par l’auteur du logiciel, il vaut mieux utiliser Apache en reverse proxy plutot que de mettre le logiciel en accès direct sur le web.

Il est nécessaire que le module proxy d’Apache soit chargé. La manière de le faire dépend beaucoup de la distribution mais en gros il suffit en général d’avoir les lignes suivantes quelque part dans le fichier de configuration :

LoadModule proxy_module /usr/lib/apache2/modules/mod_proxy.so
LoadModule proxy_http_module /usr/lib/apache2/modules/mod_proxy_http.so

Sous Ubuntu, il suffit d’utiliser la commande a2enmod :

a2enmod proxy

Ensuite, on commence par interdir le Forward Proxy.Le Forward Proxy consiste à envoyer des requètes au serveur Apache pour qu’il interroge lui-même un autre site et envoie le résultat. C’est une technique permettant de bypasser un certains nombre de proxy filtrant surtout couplé à du ssl. Par contre, mal configuré cela transforme le serveur web en relais spam. On positionne donc la directive ProxyRequests à Off.

 ProxyRequests Off

Il suffit ensuite d’activer le Reverse proxy pour l’url qui nous intéresse. Ici on va rendre accessible le terminal à partir de l’url suivante : http://monsite/ajaxterm

 ProxyPass /ajaxterm/ http://localhost:8022/
 ProxyPassReverse /ajaxterm/ http://localhost:8022/

On peut aussi (et il est d’ailleurs vivement conseillé de le faire) sécuriser l’accès à l’url par un système d’authentification. On peut gérer l’accès de l’ensemble des redirections proxy en utilisant la balise Proxy.

sécurisation de l’accès

On peut sécuriser les données avec une authentification par mot de passe classique généré avec la commande htpasswd. Mais je préfère proposer l’authentification par LDAP que j’utilise. L’exemble me semble plus intéressant.

 AuthType Basic
 AuthName "Krystalia Users Only"
 AuthLDAPURL ldap://localhost/dc=krystalia,dc=net?uid?sub
 AuthLDAPGroupAttribute member
 Require group cn=web,ou=groupes,dc=krystalia,dc=net
 Require valid-user
 Order deny,allow
 Allow from all

Les Directives intéressantes sont :

  • AuthLDAPURL : ce champ se découpe en trois sections séparées par ?. La première partie correspond à l’uri du site (ldap://localhost/dc=krystalia,dc=net). La seconde correspond au champ sur lequel la comparaison s’effectuera (ici uid). Le dernier au scope de la recherche. sub indique qu’il recherche aussi dans les sous-arborescences.

  • Require group : indique à quel groupe LDAP l’utilisateur doit appartenir. Ici, il s’agit du groupe web. On spécifie le groupe par son distinguished name.

  • AuthLDAPGroupAttribute : précise de vérifier l’appartenance de l’utilisateur au groupe en se basant sur le champ membre du groupe. exemples

Voici un aperçu de l’aspect par défaut d’ajaxterm vue par firefox

image_missing

Top fonctionne très bien sous Ajaxterm et fait toujours son petit effet lors d’une démo :-)

Et ici on peut voir que mutt fonctionne aussi.

le mot de la fin

J’espère vous avoir fait apprécier Ajaxterm comme moyen de prise à distance. C’est un peu plus original qu’un banal serveur ssh ;-) Plus sérieusement, cela démontre bien les limitations des firewalls classiques. Le protocole http est capable d’encapsuler de plus en plus d’applications différentes et une fois encrypté par ssl les firewalls deviennent relativement inutiles. Par contre, les proxys filtrants ont de l’avenir à mon avis ;-)