OpenSSH

Se connecter sur une machine derrière une passerelle

Avec des raccourcis

Config client (~/.ssh/config):

Host monclient-hote1
  ProxyCommand ssh root@passerelle.monclient.com $SSH_PROXY_FLAGS nc -w60 hote1 22
Host monclient-hote2
  ProxyCommand ssh root@passerelle.monclient.com $SSH_PROXY_FLAGS nc -w60 hote2 22

Variante avec la nouvelle option -W de ssh (-W IP:PORT connecte l'entree stdin du client ssh vers l'IP et le PORT spécifié).

Host monclient-hote1
   HostKeyAlias monclient-hote1
   ProxyCommand ssh -W hote-1:22 root@passerelle.monclient.com

Pour accéder à la machine:

ssh moi@monclient-hote1

Variante: si le réseau distant dispose d'un domaine local, on peut simplifier:

Host hote1.monclient.local
  ProxyCommand ssh root@passerelle.monclient.com $SSH_PROXY_FLAGS nc %h %p

Pour accéder à la machine:

ssh moi@hote1.monclient.local

En partageant ssh-agent

Autre solution moins sécurisée:

ssh moi@monclient-hote1 -A
ssh moi@hote1

Moins sécurisée, parce que -A partage le gestionnaire de clefs (ssh-agent) avec hôte distant, et son administrateur peut alors accéder à votre clef. À ne faire que sur des machines que vous administrez seul.

En réutilisant la connexion déjà établie

Modifier votre .ssh/config pour y ajouter les 2 lignes suivantes:

ControlMaster auto
ControlPath   /home/user/.ssh/sock/%h_%p_%r

Imaginons que vous faites un ssh sur une machine, si vous faites un 2ème ssh "normal", le client _et_ le serveur vont se retartiner toute les calculs permettant l'établissement d'un nouveau tunnel tout neuf. Sur une machine un peu encombrée au niveau processeur/mémoire ça se sent. Avec cette méthode, la réutilisation du tunnel rend le login beaucoup plus court: (on évite les calculs d'authentifications supplémentaire), ça revient quasiment au temps et aux ressources nécessaire qu'il faut à la machine distante pour engendrer un nouveau shell.

Si pour une raison ou pour une autre vous avez besoin d'une nouvelle connexion, utilisez le paramètre "-M":

ssh -M <user>@<host>

cela force l'établissement d'une connexion "master" en d'autre terme indépendante des connexions déjà existantes.

pour automatiser des commandes

Pousser des commandes et/ou un script

cat mon_script_bash | ssh <user>@<host> bash

cat << EOF | ssh <user>@<host> bash
commande1
commande2
...
commandN
EOF

même idée pour pousser un groupe de commande à une date/heure précise:

cat << EOF | ssh <user>@<host> at -m [date/heure cf: man at]
commande1
commande2
...
commandN
EOF

Note ça marche aussi sans ssh pour la machine locale.

"Tirer" un script

ssh <user>@<host> cat mon_script_bash | bash

pour partager des fichiers

• voir rsync
• voir sshfs

Pour accéder au réseau distant

par transport de connexion TCP

Surcharge d'entête:

ethernet/IP/TCP/SSH/TCP-transporté

On peut demander a la connexion de transporter un flux TCP:

• à l'établissement de la connexion avec
  • (connexion locale vers distant) -L<port-local>:<machine-distante>:<port-distant>
  • (connexion distante vers locale) -R<port-distant>:<machine-locale>:<port-local>
• pendant la connexion en tapant:

   <retour chariot>~

  puis le

  -L.../-R...

  comme au dessus

On peut mettre en place un proxy SOCKS (connexion locale vers distant):

ssh moi@monclient-hote1 -D9000

Configurer ensuite votre navigateur, dans ses propriétés réseau, pour utiliser un proxy SOCKS sur localhost:9000. Attention: les DNS ne sont pas impactés par ce proxy.

Vous pouvez ensuite accéder aux services internes de monclient à partir de votre navigateur de manière transparente.

Niveau IP (tun)

avec les nouvelles options (-w) de ssh:

• Pour: permet l'accès générique à un plus grand nombre de machine (pas qu'en Socks)
• Contre:
  • surcharge d'entête (overhead):

     ethernet/IP/TCP/SSH/IP-transportée/TCP-transporté 

  • par nature pas adapté au trafic type UDP (voix) pour lequel un OpenVPN sera mieux armé.

Côté serveur (/etc/ssh/sshd_config): ajoutez

PermitTunnel yes

Côté client faites (en tant que root) un

# ssh -w 0:0 root@serveur

cela va créer une interface tun0 sur le client et sur le serveur. Attribuez une IP différente mais dans la même plage au client et au serveur (et accessoirement dans une plage non utilisée, ni par le client ni par le serveur). Ex.

• Côté serveur:

  ifconfig tun0 172.16.21.254/24

• Côté client:

  ifconfig tun0 172.16.21.253/24

Depuis le client, vous pouvez maintenant pinguer le serveur:

ping 172.16.21.254

Le routage standard s'applique (ip_forward, iptables)

Niveau ethernet (tap)

• Pour:
  • accès niveau ethernet (arp etc.)
  • très pratique dans le contexte de machine virtuelles (xen, kvm, lxc) se raccrochant à un bridge pour établir des maquettes.
• Contre:
  • un maximum de surcharge d'entête (overhead):

     ethernet/IP/TCP/SSH/ethernet-transporté/IP-transportée/TCP-transporté 

  • par nature pas adapté au trafic type UDP (voix) pour lequel un OpenVPN sera mieux armé.

Comme au dessus avec côté client:

# ssh -w 0:0 -o Tunnel=ethernet root@serveur

Cela crée une paire de "tap0" au lieu des "tun0". Au niveau fonctionnement IP, cela réagit de la même façon: (ifconfig tap0...) Mais une tap0 peut être inclue dans un bridge:

Admettons qu'on ait côté serveur:

# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.002215aad64b       no              eth0

on inclut l'interface tap0 dans le bridge (toujours côté serveur):

brctl addif br0 tap0
ifconfig tap0 up

on ne configure pas d'adresse IP côté serveur (c'est celle du bridge br0 qui sera utilisée).

Côté client on configure