Exile on Keyboard St. - Blog sur Linux et Debian

Aller au contenu | Aller au menu | Aller à la recherche

mercredi 17 mai 2017

Simplifier vos connexions ssh avec ssh_config

Pour se connecter à une machine, virtuelle ou non, en ssh, on a besoin de spécifier au moins:

  • le nom d'hôte
  • le nom d'utilisateur

et parfois aussi

  • le port d'écoute du serveur ssh
  • certaines variables d'environnement
  • ...

Et c'est parfois long.

C'est oublier que tous ces paramètres passés sur la ligne de commande peuvent aussi être définis dans un fichier pour chaque machine à laquelle on se connecte.

Ce fichier est .ssh/config et a le format suivant:

host@machine:~$ cat .ssh/config 

Host vm-test
    Hostname 192.168.0.1
    Port 2222
    User debian
    SendEnv LANG LC_* HOST_IP

Le mot clé Host définit les paramètres de connexion à l'hôte en question et chaque paramètre suit indenté par quatre espaces.

De cette façon, se connecter à cet hôte se limite à:

ssh vm-test

C'est quand même plus rapide comme cela. Et il faut admettre que la façon de déclarer les Host est simplissime.

ssh comprend énormément de paramètres dans ce fichier config, pour tous les lister:

man ssh_config

jeudi 27 avril 2017

Machine Virtuelle, réseau NAT et redirection de ports

Quand on crée une machine virtuelle avec VirtualBox, le réseau créé par défaut est de type NAT.

Avec le réseau NAT, dans lequel aucune configuration n'est nécessaire, on peut naviguer sur Internet, lire les mails et de manière générale les applications de la machine virtuelle ont accès au réseau.

Dans ce mode réseau, le moteur réseau de VirtualBox agit comme un routeur qui dirige le traffic depuis et vers la machine virtuelle sans configuration de votre part. Chaque machine virtuelle a certes accès au réseau mais pas aux autres machines virtuelles ni à la machine hôte. La machine virtuelle en mode NAT est donc comme dans un réseau privé, connectée au réseau mais invisible de l'extérieur, y compris de sa machine hôte.

On peut s'en convaincre facilement avec la commande ping depuis la machine virtuelle vers la machine hôte et inversement: la VM voit la machine hôte mais l'inverse n'est pas vrai.

Mais alors, si la machine hôte ne voit pas la machine virtuelle, comment faire par exemple pour se connecter en ssh à la machine virtuelle depuis la machine hôte ? De la même façon qu'avec un routeur: en utilisant la redirection de ports.

On va donc configurer le moteur réseau de VirtualBox pour que les connexions sur le port 2222 de la machine hôte soient redirigées sur le port 22 de la machine virtuelle comme ceci:

Capture-Regles_de_redirection_de_ports-1.png

Il ne me reste plus qu'à me connecter à la machine virtuelle comme ceci:

ssh -p 2222 debian@192.168.0.1

Vous noterez que j'ai choisi un port d'écoute d'une valeur supérieure à 1024 (2222) puisque le moteur de VirtualBox se met à l'écoute sur la machine hôte sans avoir les droits administrateurs. Utiliser un port inférieur à 1024 aurait échoué.

Si maintenant je souhaite accéder à un serveur Web démarré sur la machine virtuelle, il faut effectuer une deuxième redirection de port, et ainsi de suite.

dimanche 19 mars 2017

Transmettre une variable d'environnement à une connexion ssh

J'ai besoin pour faire des tests de connaitre l'adresse IP de l'hôte qui héberge une machine virtuelle.

Comme je me connecte à cette machine virtuelle par ssh, je vais lui transmettre cette adresse IP via une variable d'environnement.

Pour cela, j'ai besoin de spécifier le nom de la variable d'environnement coté hôte. On l'appelera HOST_IP.

Cela peut se faire de deux façons:

Dans le fichier /etc/ssh/ssh_config via la directive:

SendEnv HOST_IP

En fait on changera la ligne existante:

SendEnv LANG LC_*

en

SendEnv LANG LC_* HOST_IP

On peut aussi spécifier le nom de la variable sur la ligne de commande ssh:

ssh -o SendEnv=HOST_IP user@machine...

Pour que cela fonctionne, il faut maintenant que la machine virtuelle accepte cette variable d'environnement.

Pour cela on changera dans le fichier /etc/ssh/sshd_config de la VM la ligne:

AcceptEnv LANG LC_*

en

AcceptEnv LANG LC_* HOST_IP

Et on redémarre le serveur ssh.

samedi 8 mars 2014

Quels scripts d'initialisation utiliser sous Debian: .bash_profile ou .bashrc ?

Quand on définit des alias ou qu'on modifie le PATH sous Linux, la question de savoir dans quels scripts d'initialisation du Shell on le fait se pose souvent.

Faut t-il définir les alias dans le fichier .bash_profile de l'utilisateur ou dans le fichier .bashrc ?

Avant de répondre à cette question, il faut savoir qu'il y a deux types de Shell: les Shell de connexion (ou de login) et les autres.

Le Shell de connexion est celui qui est invoqué lorsqu'on se connecte sur la console:

  • lors de la connexion physique à une machine dépourvue d'environnement graphique,
  • ou en utilisant les raccourcis Ctrl-Alt F1, Ctrl-Alt F2 ...,
  • ou lors d'une connexion à une machine distante via ssh

et aussi si on utilise la commande bash --login.

Tous les autres Shells lançés par un Shell de connexion n'en sont donc pas. Les Anglais parlent de "non-login Shell".

Donc pour revenir aux scripts d'initialisation du Shell du répertoire courant de l'utilisateur:

  • .bash_profile est le script d'initialisation des Shells de login,
  • .bashrc est le script d'initialisation des autres Shell,

Selon l'usage des alias que l'on veut faire, on les définira dans un fichier ou dans un autre.

Mais un alias définit dans .bash_profile ne sera pas visible par un Shell lancé depuis l'environnement graphique puisque le Shell utilisé dans ce cas n'est pas un Shell de login.

Par contre sous Debian les définitions d'alias faites dans .bashrc seront utilisables non seulement dans un "non-login Shell" puisqu'ils sont définis dans le script d'initialisation de ceux-cis mais aussi par les Shells de login puisque sous Debian généralement .bashrc est appelé par .bash_profile comme suit:

# if running bash
if [ -n "$BASH_VERSION" ]; then
    # include .bashrc if it exists
    if [ -f "$HOME/.bashrc" ]; then
        . "$HOME/.bashrc"
    fi
fi

Par conséquent, la façon la plus simple de définir des alias, le PATH ou de faire d'autres réglages sous Debian consiste à le faire dans le fichier .bashrc. Sur d'autres distributions Linux, cela reste évidemment vrai tant que l'on source .bashrc depuis .bash_profile.

Enfin, il faut savoir que si le fichier .bash_profile n'existe pas alors c'est le fichier .profile qui sera recherché.

dimanche 12 janvier 2014

X11 Forwarding depuis le Raspberry Pi avec ssh

Le Raspberry Pi n'étant pas forcément connecté à un écran, il peut être pratique de rediriger l'affichage des applications X de celui-ci vers une autre machine Linux.

ssh permet de déporter l'affichage des applications graphiques d'une machine serveur vers la machine cliente qui y est connectée.

Dans cet exemple on a:

  • Un serveur, un Raspberry Pi,
  • Un client, la machine qui se connecte au Raspberry Pi

Les deux machines sont sous Linux, plus précisément Debian.

Pour pouvoir déporter l'affichage des applications X, il faut:

  • Que le démon ssh soit démarré sur le Raspberry Pi, avec le forwarding X11 activé, pour cela on positionnera la variable X11Forwarding à true dans /etc/sshd_config. Si cette variable n'était pas positionnée, il faut redémarrer le serveur pour que la modification soit prise en compte,
  • Que le serveur ssh dispose des applications permettant l'affichage distant: il s'agit du paquet xbase-clients sur Raspbian

Ensuite, depuis la machine cliente:

ssh -Y pi@raspberrypi

L'option -Y spécifie que l'on utilise le Forwarding X11 sans contrôles de sécurité, ce qui présente l'avantage d'être plus rapide que l'option classique -X, et est sans risques sur un réseau privé.

Ensuite une fois le mot de passe saisi:

pi@raspberrypi ~ $ env| grep DIS

DISPLAY=localhost:10.0

La variable DISPLAY est positionnée toute seule et on peut lancer une application graphique de manière déportée, par exemple:

midori &

ou:

lxterminal &

Enfin, on peut si la connexion s'avère lente utiliser en plus l'option -C de ssh qui permet d'activer la compression gzip des données échangées entre le client et le serveur.

- page 1 de 2