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.

Pour accéder via un navigateur

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.

Pour accéder via réseau

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