relecture + compléments
This commit is contained in:
Gregory Colpart
parent
888da04f6d
commit
50b533dd90
521
HowtoOpenSSH.md
521
HowtoOpenSSH.md
|
|
@ -6,7 +6,9 @@ title: Howto OpenSSH
|
|||
* Documentation : <https://www.openssh.com/manual.html>
|
||||
|
||||
[OpenSSH](https://www.openssh.com/) est l'implémentation la plus répandue du protocole SSH permettant de se connecter sur une machine à travers le réseau de manière sécurisée.
|
||||
OpenSSH fait partie du projet [OpenBSD](HowtoOpenBSD) et permet de nombreuses fonctionnalités : SFTP, gestion de clés, tunnels, VPN, etc.
|
||||
OpenSSH est développé par le projet [OpenBSD](HowtoOpenBSD), il
|
||||
|
||||
fait partie du projet [OpenBSD](HowtoOpenBSD) et permet de nombreuses fonctionnalités : SFTP, gestion de clés, tunnels, VPN, etc.
|
||||
|
||||
Ce protocole existe en plusieurs
|
||||
versions et nous utilisons uniquement la version 2. La version 1
|
||||
|
|
@ -16,30 +18,53 @@ comporte des failles de sécurité et ne doit plus être utilisée.
|
|||
|
||||
### Debian
|
||||
|
||||
On peut installer la partie client et la partie serveur indépendamment :
|
||||
On peut installer les parties client et serveur indépendamment :
|
||||
|
||||
~~~
|
||||
# apt install openssh-client
|
||||
# ssh -V
|
||||
OpenSSH_7.4p1 Debian-10+deb9u1, OpenSSL 1.0.2l 25 May 2017
|
||||
|
||||
# apt install openssh-server
|
||||
# nc localhost 22
|
||||
SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u1
|
||||
|
||||
# systemctl status ssh
|
||||
● ssh.service - OpenBSD Secure Shell server
|
||||
Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
|
||||
Main PID: 1715 (sshd)
|
||||
Tasks: 1 (limit: 4915)
|
||||
CGroup: /system.slice/ssh.service
|
||||
└─1715 /usr/sbin/sshd -D
|
||||
~~~
|
||||
|
||||
### OpenBSD
|
||||
|
||||
OpenSSH étant développé au sein d'OpenBSD, la partie cliente et la
|
||||
partie serveur sont incluses dans la base. L'activation de la partie
|
||||
serveur dépend du choix qui a été fait lors de l'installation.
|
||||
Les parties client et serveur sont incluses dans la base OpenBSD.
|
||||
|
||||
## Configuration SSH
|
||||
~~~
|
||||
$ ssh -V
|
||||
OpenSSH_7.5, LibreSSL 2.5.2
|
||||
~~~
|
||||
|
||||
### Configuration minimale
|
||||
La partie serveur est activée par défaut, sauf mention contraire à l'installation.
|
||||
|
||||
~~~
|
||||
# grep -r sshd /etc/rc.conf*
|
||||
/etc/rc.conf:sshd_flags=
|
||||
/etc/rc.conf.local:sshd_flags=NO
|
||||
|
||||
# rcctl enable sshd
|
||||
~~~
|
||||
|
||||
|
||||
## Configuration
|
||||
|
||||
### Configuration sshd_config
|
||||
|
||||
<http://man.openbsd.org/sshd_config>
|
||||
|
||||
Fichiers de configuration :
|
||||
|
||||
~~~
|
||||
/etc/ssh
|
||||
├── moduli
|
||||
|
|
@ -57,7 +82,7 @@ La configuration de base qu'on utilise (les options commentées sont
|
|||
les valeurs par défaut).
|
||||
|
||||
~~~
|
||||
# $OpenBSD: sshd_config,v 1.100 2016/08/15 12:32:04 naddy Exp $
|
||||
# $OpenBSD: sshd_config,v 1.100 2016/08/15 12:32:04 naddy Exp $
|
||||
|
||||
# This is the sshd server system-wide configuration file. See
|
||||
# sshd_config(5) for more information.
|
||||
|
|
@ -88,7 +113,7 @@ LogLevel VERBOSE
|
|||
# Authentication:
|
||||
|
||||
#LoginGraceTime 2m
|
||||
#PermitRootLogin without-password
|
||||
PermitRootLogin no
|
||||
#StrictModes yes
|
||||
#MaxAuthTries 6
|
||||
#MaxSessions 10
|
||||
|
|
@ -96,7 +121,7 @@ LogLevel VERBOSE
|
|||
#PubkeyAuthentication yes
|
||||
|
||||
# Expect .ssh/authorized_keys2 to be disregarded by default in future.
|
||||
#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2
|
||||
#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2
|
||||
|
||||
#AuthorizedPrincipalsFile none
|
||||
|
||||
|
|
@ -172,16 +197,16 @@ PrintMotd no
|
|||
#AcceptEnv LANG LC_*
|
||||
|
||||
# override default of no subsystems
|
||||
Subsystem sftp /usr/lib/openssh/sftp-server
|
||||
Subsystem sftp /usr/lib/openssh/sftp-server -l INFO
|
||||
|
||||
# Example of overriding settings on a per-user basis
|
||||
#Match User anoncvs
|
||||
# X11Forwarding no
|
||||
# AllowTcpForwarding no
|
||||
# PermitTTY no
|
||||
# ForceCommand cvs server
|
||||
# X11Forwarding no
|
||||
# AllowTcpForwarding no
|
||||
# PermitTTY no
|
||||
# ForceCommand cvs server
|
||||
|
||||
AllowUsers johndoe janedoe alice bob
|
||||
AllowUsers jdoe alice bob
|
||||
|
||||
Match Address 192.0.2.42
|
||||
PasswordAuthentication yes
|
||||
|
|
@ -191,34 +216,88 @@ Match Group adm
|
|||
PasswordAuthentication no
|
||||
~~~
|
||||
|
||||
> **Note** : Les clés DSA sont dépréciées depuis Stretch.
|
||||
### Configuration ssh_config
|
||||
|
||||
### Log verbeux pour SFTP
|
||||
<http://man.openbsd.org/ssh_config>
|
||||
|
||||
Pour augmenter la verbosité du sous-système sftp-server, notamment loguer les commandes SFTP, il suffit de passer l'option -l à l'appel de sftp-server dans `sshd_config` :
|
||||
On peut configurer la partie client via le fichier `~/.ssh/config`.
|
||||
|
||||
On peut ainsi passer certaines options générales :
|
||||
|
||||
~~~
|
||||
Subsystem sftp /usr/libexec/openssh/sftp-server -l INFO
|
||||
UseRoaming no
|
||||
User jdoe
|
||||
IdentityFile ~/.ssh/id_ed25519
|
||||
IdentityFile ~/.ssh/id_rsa
|
||||
~~~
|
||||
|
||||
## SFTP chroot
|
||||
|
||||
Voici un ensemble de commandes pouvant être utilisé pour mettre en place un accès SFTP pour un ou plusieurs utilisateurs, qui n'auront accès qu'à une vue limitée de l'arborescence du système :
|
||||
On peut aussi passer des options spécifiques à chaque serveur distant sur lequel on va se connecter.
|
||||
On définit ainsi des *alias* (utilisables ensuite via `ssh`) et des options correspondantes :
|
||||
|
||||
~~~
|
||||
# Répertoire dans lequel SSHD va se chrooter
|
||||
mkdir /home/sftp
|
||||
chmod 755 /home/sftp
|
||||
Host foo ssh.example.com
|
||||
Hostname ssh.example.com
|
||||
Port 2222
|
||||
User john
|
||||
|
||||
# Les utilisateurs du groupe sftp (ici account1) disposeront de l'accès SFTP restreint
|
||||
groupadd sftp
|
||||
useradd -g sftp -d /account1 account1
|
||||
mkdir /home/sftp/account1/
|
||||
chown account1:sftp /home/sftp/account1/
|
||||
chmod 700 /home/sftp/account1/
|
||||
Host sql.example.com
|
||||
IdentityFile ~/.ssh/id_bastion_ed25519
|
||||
ProxyCommand ssh bastion.example.com -W %h:%p
|
||||
|
||||
Host nfs.example.com
|
||||
ProxyCommand ssh -W bastion.example.com:2222 john@192.0.2.111
|
||||
|
||||
Host switch42
|
||||
User admin
|
||||
HostName 192.0.2.150
|
||||
ProxyCommand sh -c "nc -w1 %h %p 2>/dev/null || ssh bastion.example.com -W %h:%p"
|
||||
KexAlgorithms diffie-hellman-group1-sha1
|
||||
~~~
|
||||
|
||||
Dans le fichier `/etc/ssh/sshd_config` :
|
||||
|
||||
## SCP
|
||||
|
||||
Le protocole SCP (Secure Copy) est basé sur SSH, il permet de transférer des fichiers entre deux machines distantes de façon sécurisée.
|
||||
|
||||
Utilisation simple :
|
||||
|
||||
~~~
|
||||
$ scp /foo/FICHIER ssh.example.com:/bar/
|
||||
~~~
|
||||
|
||||
Pour envoyer un répertoire, on utilisera l'option `-r` :
|
||||
|
||||
~~~
|
||||
$ scp -r /foo/ ssh.example.com:/bar/
|
||||
~~~
|
||||
|
||||
Options utiles pour `scp` :
|
||||
|
||||
* `-P 2222` : utilise le port 2222 pour le serveur distant (malheureusement différent de `ssh`…)
|
||||
* `-q` : mode silencieux
|
||||
* `-C` : active la compression
|
||||
* `-i identity_file` : utilise une clé SSH spécifique
|
||||
|
||||
|
||||
## SFTP
|
||||
|
||||
Le protocole SFTP correspond au **SSH File Transfer Protocol** : c'est une extension du protocole SSH qui permet non seulement de transférer des fichiers (comme [SCP](HowtoOpenSSH#scp)) mais aussi d'avoir des fonctionnalités plus avancées (listing de répertoire, suppression de fichiers, etc.) similaire au vieux protocole FTP.
|
||||
|
||||
### chroot SFTP
|
||||
|
||||
On peut restreindre un accès SFTP dans un répertoire, les utilisateurs n'auront accès qu'à une vue limitée de l'arborescence du système.
|
||||
|
||||
Pour mettre en place un chroot SFTP, on crée un répertoire `/home/sftp` et un groupe `sftp` :
|
||||
|
||||
~~~
|
||||
# mkdir /home/sftp
|
||||
# chown root:sftp /home/sftp
|
||||
# chmod 750 /home/sftp
|
||||
|
||||
# groupadd sftp
|
||||
~~~
|
||||
|
||||
et on configure via `/etc/ssh/sshd_config` :
|
||||
|
||||
~~~
|
||||
Subsystem sftp internal-sftp
|
||||
|
|
@ -230,45 +309,43 @@ Match group sftp
|
|||
ForceCommand internal-sftp
|
||||
~~~
|
||||
|
||||
On peut ensuite créer un utilisateur restreint :
|
||||
|
||||
~~~
|
||||
# useradd -g sftp -d /jdoe jdoe
|
||||
# mkdir /home/sftp/jdoe/
|
||||
# chown jdoe:sftp /home/sftp/jdoe/
|
||||
# chmod 700 /home/sftp/jdoe/
|
||||
~~~
|
||||
|
||||
### SFTP Only
|
||||
|
||||
Mettre shell `/usr/lib/sftp-server` pour l'utilisateur et s'assurer que ce shell est bien présent dans `/etc/shells`
|
||||
On peut restreindre un utilisateur au protocole SFTP.
|
||||
Il faut s'assurer que `/usr/lib/sftp-server` soit un shell valide et lui définir comme shell par défaut :
|
||||
|
||||
~~~
|
||||
# usermod -s /usr/lib/sftp-server userna
|
||||
# echo '/usr/lib/stfp-server' >> /etc/shells
|
||||
# usermod -s /usr/lib/sftp-server userna
|
||||
~~~
|
||||
|
||||
## Clé ssh
|
||||
|
||||
Il y a plusieurs types de clé, avec suivant les algorithmes, des
|
||||
tailles de clés variables ou non. L'algorithme à préférer est
|
||||
*ed25519* mais il faut faire attention sur quelle machine la clé va
|
||||
être utilisée car les très vieilles versions d'OpenSSH ne le
|
||||
supportent pas. C'est notamment le cas sur Debian Wheezy. Dans ce cas là on
|
||||
préférera l'algorithme *rsa*.
|
||||
## Clé SSH
|
||||
|
||||
Dans le cas de *ed25519*, la taille de la clé est fixe. Pour *rsa*,
|
||||
2048 est la taille minimale, 4096 est recommandée.
|
||||
Il y a plusieurs types de clé, avec suivant les algorithmes, des tailles de clés variables ou non.
|
||||
L'algorithme que nous conseillons est *ed25519* mais attention, ce n'est pas supporté sur des anciennes machines (Debian 7 par exemple) où il faudrait utiliser l'algorithme *RSA* (on conseille alors d'utiliser une taille de clé de 4096).
|
||||
|
||||
**Il est important de mettre un mot de passe pour protéger sa clé privée.**
|
||||
|
||||
On peut aussi utiliser l'option `-a NOMBRE` pour spécifier le nombre d'itérations
|
||||
de l'algorithme de dérivation de clé qui protège la clé privée avec le mot de
|
||||
passe utilisé. Cela protège la clé privée contre le brute-force du mot de passe.
|
||||
Mais attention, plus ce nombre est grand, plus le déchiffrement de la clé est ralenti.
|
||||
Un bon compromis est *100* en nombre d'itérations.
|
||||
Pour générer une clé SSH *ed25519* :
|
||||
|
||||
~~~
|
||||
$ ssh-keygen -t ed25519 -a 100
|
||||
Generating public/private ed25519 key pair.
|
||||
Enter file in which to save the key (/home/user/.ssh/id_ed25519):
|
||||
Enter file in which to save the key (/home/jdoe/.ssh/id_ed25519):
|
||||
Enter passphrase (empty for no passphrase):
|
||||
Enter same passphrase again:
|
||||
Your identification has been saved in /home/user/.ssh/id_ed25519.
|
||||
Your public key has been saved in /home/user/.ssh/id_ed25519.pub.
|
||||
Your identification has been saved in /home/jdoe/.ssh/id_ed25519.
|
||||
Your public key has been saved in /home/jdoe/.ssh/id_ed25519.pub.
|
||||
The key fingerprint is:
|
||||
SHA256:7tdFlczm4VJkEl4yM08O4VOPkGQiU1YR8kKuLsm9v84 user@example.com
|
||||
SHA256:7tdFlczm4VJkEl4yM08O4VOPkGQiU1YR8kKuLsm9v84 jdoe@example.com
|
||||
The key's randomart image is:
|
||||
+--[ED25519 256]--+
|
||||
| o.*oB&**.|
|
||||
|
|
@ -283,23 +360,20 @@ The key's randomart image is:
|
|||
+----[SHA256]-----+
|
||||
~~~
|
||||
|
||||
Dans le cas de *rsa*, on précise la taille. On donne aussi [l'argument
|
||||
`-o`](http://man.openbsd.org/ssh-keygen#o) afin que la clé privée
|
||||
utilise le nouveau format qui est à la fois
|
||||
[standard](https://tools.ietf.org/html/rfc4716) et qui est plus
|
||||
résistant aux attaques par brute-force. Cet argument n'est pas
|
||||
nécessaire avec *ed25519* car il est par défaut.
|
||||
> *Note* : l'option -a 100` spécifie le nombre d'itérations de l'algorithme de dérivation de clé qui protège la clé privée avec la passphrase utilisée. Cela protège la clé privée contre le brute-force de la passphrase. Mais attention, plus ce nombre est grand, plus le déchiffrement de la clé est ralenti. Un bon compromis est *100* en nombre d'itérations.
|
||||
|
||||
Pour générer une clé SSH *RSA* :
|
||||
|
||||
~~~
|
||||
$ ssh-keygen -o -t rsa -b 4096 -a 100
|
||||
Generating public/private rsa key pair.
|
||||
Enter file in which to save the key (/home/user/.ssh/id_rsa):
|
||||
Enter file in which to save the key (/home/jdoe/.ssh/id_rsa):
|
||||
Enter passphrase (empty for no passphrase):
|
||||
Enter same passphrase again:
|
||||
Your identification has been saved in /home/user/.ssh/id_rsa.
|
||||
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
|
||||
Your identification has been saved in /home/jdoe/.ssh/id_rsa.
|
||||
Your public key has been saved in /home/jdoe/.ssh/id_rsa.pub.
|
||||
The key fingerprint is:
|
||||
SHA256:9tGKNLEbiUyAbhShJ7rncBpn/ydCXZHtJkdIsUoW2TM user@example.com
|
||||
SHA256:9tGKNLEbiUyAbhShJ7rncBpn/ydCXZHtJkdIsUoW2TM jdoe@example.com
|
||||
The key's randomart image is:
|
||||
+---[RSA 4096]----+
|
||||
| o+. .+o= |
|
||||
|
|
@ -314,144 +388,262 @@ The key's randomart image is:
|
|||
+----[SHA256]-----+
|
||||
~~~
|
||||
|
||||
### .ssh/config
|
||||
> *Note* : dans le cas de *RSA*, on utilise [l'argument`-o`](http://man.openbsd.org/ssh-keygen#o) afin que la clé privée utilise le nouveau format qui est à la fois [standard](https://tools.ietf.org/html/rfc4716) et plus résistant aux attaques par brute-force.
|
||||
|
||||
Il est possible de configurer des sortes d'*alias* pour son
|
||||
utilisateur unix via le fichier `~/.ssh/config`
|
||||
### authorized_keys
|
||||
|
||||
Un exemple plutôt complet (on n'a pas besoin forcément de décrire tout
|
||||
ça) sans être exhaustif :
|
||||
Pour autoriser une connexion avec une clé SSH, il faut la placer dans le fichier `~/.ssh/authorized_keys` et ajuster les droits :
|
||||
|
||||
~~~
|
||||
Host www00
|
||||
Hostname www00.example.com
|
||||
Port 2222
|
||||
User johndoe
|
||||
IdentityFile ~/.ssh/id_ed25519
|
||||
ProxyCommand ssh bastion -W %h:%p
|
||||
$ ssh ssh.example.com mkdir -p ~/.ssh
|
||||
$ ssh ssh.example.com chmod 700 ~/.ssh
|
||||
$ scp ~/.ssh/id_ed25519.pub ssh.example.com:.ssh/authorized_keys
|
||||
$ ssh ssh.example.com chmod 600 ~/.ssh/authorized_keys
|
||||
~~~
|
||||
|
||||
### Agent SSH
|
||||
|
||||
Il est très important (comprendre vital) de protéger sa clé ssh avec
|
||||
un mot de passe lors de sa création. Taper son mot de passe à chaque
|
||||
connexion peut-être pesant, on peut donc passer par l'agent ssh qui va
|
||||
le retenir en mémoire (de la même manière que sudo par exemple).
|
||||
|
||||
Pour l'utiliser il convient de rajouter dans son fichier `~/.profile`
|
||||
(ou équivalent) la ligne :
|
||||
Pour faire cela de façon plus simple, on peut utiliser le script `ssh-copy-id` :
|
||||
|
||||
~~~
|
||||
eval $(ssh-agent) 1> /dev/null
|
||||
$ ssh-copy-id ssh.example.com
|
||||
~~~
|
||||
|
||||
Ensuite pour rajouter la clé dans un agent il suffit de taper la
|
||||
commande
|
||||
> *Note* : pour préciser un port alternatif, on peut utiliser l'option `-p NN` depuis Debian 8. En Debian 7, il faut utiliser `ssh-copy-id "-pNN ssh.example.com"`
|
||||
|
||||
~~~
|
||||
$ ssh-add /home/user/.ssh/id_secure
|
||||
~~~
|
||||
|
||||
Néanmoins, contrairement à sudo où l'accès est temporaire, dans le cas
|
||||
présent l'agent garde les clés de manière illimitée ce qui n'est pas
|
||||
forcément bon. On pourra donc utiliser l'option
|
||||
[-t](http://man.openbsd.org/ssh-agent#t) pour spécifier une durée.
|
||||
|
||||
|
||||
On peut lire dans des tutoriels d'utiliser l'option -A de ssh(1) pour
|
||||
se connecter à des machines via une autre machine. Cependant cela
|
||||
permet à l'utilisateur *root* de la machine sur laquelle vous mettez
|
||||
votre agent de se connecter, en utilisant vos clés, aux machines
|
||||
auxquelles vous avez accès. On privilégiera donc d'utiliser l'option
|
||||
-J de ssh(1) pour faire un rebond.
|
||||
|
||||
> **Note** : Il existe d'autres implémentations de l'agent SSH, tel que gpg-agent qui gère aussi les clés SSH.
|
||||
|
||||
## Restriction de l'accès d'une clé ssh
|
||||
|
||||
Pour autoriser une clé SSH en limitant les accès via `.ssh/authorized_keys` :
|
||||
On peut mettre des restrictions d'accès via le fichier `.ssh/authorized_keys`, par exemple :
|
||||
|
||||
~~~
|
||||
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa XXXXX commentaires
|
||||
~~~
|
||||
|
||||
## VPN over SSH
|
||||
### Agent SSH
|
||||
|
||||
Côté serveur SSH :
|
||||
Il est important de protéger une clé SSH utilisée par humain par une passphrase.
|
||||
Pour éviter de taper sa passphrase à chaque utilisation, on peut utiliser un *agent SSH* qui va la retenir en mémoire.
|
||||
|
||||
- Ajouter "PermitTunnel yes" dans la config ssh
|
||||
- sysctl -w net.ipv4.ip_forward=1
|
||||
- iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
|
||||
En général, un agent SSH est lancé par son Window Manager.
|
||||
Sinon, on peut le lancer automatiquement via son `~/.profile` :
|
||||
|
||||
Puis se connecter de root vers root :
|
||||
~~~
|
||||
eval $(ssh-agent) 1> /dev/null
|
||||
~~~
|
||||
|
||||
Une fois lancé, l'agent ouvre une socket Unix dans `$TMPDIR/ssh-XXXXXXXXXX/agent.PPID` et la rend disponible via les variables d'environnement suivantes :
|
||||
|
||||
~~~
|
||||
SSH_AUTH_SOCK=/tmp/ssh-IklIVmCGvWgT/agent.1151
|
||||
SSH_AGENT_PID=1198
|
||||
~~~
|
||||
|
||||
On peut alors lancer la commande `ssh-add` qui va nous demander notre passphrase et la transmettre à l'agent SSH :
|
||||
|
||||
~~~
|
||||
$ ssh-add -t 36000
|
||||
Enter passphrase for /home/jdoe/.ssh/id_ed25519:
|
||||
Identity added: /home/jdoe/.ssh/id_ed25519 (/home/jdoe/.ssh/id_ed25519)
|
||||
~~~
|
||||
|
||||
> *Note* : l'option [-t](http://man.openbsd.org/ssh-agent#t) permet de limiter à 10h le temps où l'agent va conserver la passphrase en mémoire. Si l'option n'est pas utilisée, ce temps sera infini, ce que l'on déconseille en général.
|
||||
|
||||
On peut également utiliser l'outil [keychain](https://www.funtoo.org/Keychain) qui facilite l'utilisation d'un agent SSH (et d'un agent GPG).
|
||||
Il va notamment lancer les agents si ils ne sont pas encore lancés, et transmettre plusieurs clés SSH si besoin.
|
||||
|
||||
~~~
|
||||
$ keychain id_ed25519 id_rsa --timeout 600
|
||||
|
||||
* keychain 2.7.1 ~ http://www.funtoo.org
|
||||
* Starting ssh-agent...
|
||||
* Starting gpg-agent...
|
||||
* Adding 2 ssh key(s): /home/jdoe/.ssh/id_ed25519 /home/jdoe/.ssh/id_rsa
|
||||
Enter passphrase for /home/jdoe/.ssh/id_ed25519:
|
||||
* ssh-add: Identities added: /home/jdoe/.ssh/id_ed25519 /home/jdoe/.ssh/id_rsa (life=600m)
|
||||
~~~
|
||||
|
||||
> *Note* : on pourra bien sûr lancer *keychain* via son `~/.profile`
|
||||
|
||||
Enfin, il existe d'autres implémentations d'agent SSH, notamment `gpg-agent`.
|
||||
|
||||
|
||||
## Tunnel SSH
|
||||
|
||||
Un tunnel SSH permet d'accéder à une ressource distante via une connexion SSH.
|
||||
Cela s'utilise classiquement pour accéder à un service distant non accessible directement.
|
||||
|
||||
### Tunnel SSH vers un service
|
||||
|
||||
Exemple simple : on veut accéder à un service MySQL accessible en local sur un serveur distant.
|
||||
On lance la commande suivante :
|
||||
|
||||
~~~
|
||||
$ ssh -L 3306:127.0.0.1:3306 ssh.example.com
|
||||
~~~
|
||||
|
||||
Et l'on pourra accéder au service MySQL sur sa propre machine via 127.0.0.1 port 3306.
|
||||
|
||||
Si le service MySQL est sur une 3ème machine (accessible depuis le serveur distant), il suffit de préciser son IP avec l'option `-L` :
|
||||
|
||||
~~~
|
||||
$ ssh -L 3306:192.0.2.33:3306 ssh.example.com
|
||||
~~~
|
||||
|
||||
On peut bien sûr utiliser un port différent pour sa propre machine, par exemple 8306 :
|
||||
|
||||
~~~
|
||||
$ ssh -L 8306:192.0.2.33:3306 ssh.example.com
|
||||
~~~
|
||||
|
||||
De même, si l'on veut se « binder » sur une autre IP que 127.0.0.1 sur sa propre machine, on peut le préciser avec l'option `-L` :
|
||||
|
||||
~~~
|
||||
$ ssh -L 127.0.0.33:8306:192.0.2.33:3306 ssh.example.com
|
||||
~~~
|
||||
|
||||
Enfin il faut noter que si l'on veut utiliser un port local inférieur à 1024, il faudra lancer la commande en "root" :
|
||||
|
||||
~~~
|
||||
# ssh -L 443:127.0.0.1:443 ssh.example.com
|
||||
~~~
|
||||
|
||||
### Proxy SOCKS via SSH
|
||||
|
||||
On peut lancer un proxy SOCKS passant par un serveur distant ainsi :
|
||||
|
||||
~~~
|
||||
$ ssh -D 6789 ssh.example.com
|
||||
~~~
|
||||
|
||||
Il reste ensuite à configurer le logiciel qui va utiliser ce proxy SOCKS (4a ou 5) avec l'adresse 127.0.0.1 et le port 6789.
|
||||
C'est ainsi pratique avec un navigateur où l'ensemble du trafic vers le web passera ainsi par le serveur distant.
|
||||
|
||||
|
||||
## Astuces
|
||||
|
||||
### Séquences d'échappement SSH
|
||||
|
||||
<https://lonesysadmin.net/2011/11/08/ssh-escape-sequences-aka-kill-dead-ssh-sessions/amp/>
|
||||
|
||||
On peut utiliser des combinaisons de touches spéciales via une connexion SSH pour intéragir sur la connexion en cours.
|
||||
|
||||
En tapant `Entrée + ~ + ?` on obtient la liste des séquences possibles :
|
||||
|
||||
~~~
|
||||
Supported escape sequences:
|
||||
~. - terminate connection (and any multiplexed sessions)
|
||||
~B - send a BREAK to the remote system
|
||||
~C - open a command line
|
||||
~R - request rekey
|
||||
~V/v - decrease/increase verbosity (LogLevel)
|
||||
~^Z - suspend ssh
|
||||
~# - list forwarded connections
|
||||
~& - background ssh (when waiting for connections to terminate)
|
||||
~? - this message
|
||||
~~ - send the escape character by typing it twice
|
||||
(Note that escapes are only recognized immediately after newline.)
|
||||
~~~
|
||||
|
||||
Voici les séquences les plus utiles :
|
||||
|
||||
* `Entrée + ~ + .` : forcer à terminer la connexion SSH en cours (utile en cas de perte de connexion…)
|
||||
* `Entrée + ~ + v` : diminue la verbosité, par exemple quand on s'est connecté avec `ssh -vvv`
|
||||
|
||||
### Connexion SSH par rebond
|
||||
|
||||
Il se peut qu'on doive passer par une machine pour se connecter en SSH à une machine cible (c'est le principe d'un [bastion](https://fr.wikipedia.org/wiki/Bastion_(informatique))).
|
||||
|
||||
On peut ainsi se connecter avec `-o ProxyCommand` :
|
||||
|
||||
ssh -o ProxyCommand="ssh -W cible.example.com:22 bastion.example.com" cible.example.com
|
||||
|
||||
Dans les versions récentes d'OpenSSH (notamment sur Debian 9) il existe une méthode plus simple :
|
||||
|
||||
~~~
|
||||
$ ssh -J bastion.example.com cible.example.com
|
||||
~~~
|
||||
|
||||
> *Note* : il ne faut pas utiliser l'option `-A` pour rebondir car elle est dangereuse, à moins que vous ne voulez vraiment faire du [Agent forwarding](HowtoOpenSSH#agent-forwarding)
|
||||
|
||||
### Agent forwarding
|
||||
|
||||
Si vous voulez utiliser une [clé SSH](HowtoOpenSSH#cle-SSH) locale depuis un serveur distant, vous pouvez utiliser l'option `-A` :
|
||||
|
||||
~~~
|
||||
$ ssh -A ssh.example.com
|
||||
$ env | grep ^SSH_A
|
||||
SSH_AUTH_SOCK=/tmp/ssh-sUSruIwyCa/agent.3265
|
||||
~~~
|
||||
|
||||
> *Note* : attention, cette option doit être utilisée en connaissance de cause car l'utilisateur *root* sur la machine *ssh.example.com* aura accès à vos clés et donc aux machines distantes auxquelles vous avez accès avec vos clés.
|
||||
|
||||
### VPN over SSH
|
||||
|
||||
On peut utiliser OpenSSH comme VPN !
|
||||
Côté serveur, vous devez :
|
||||
|
||||
- Ajouter `PermitTunnel yes`
|
||||
- Autoriser l'IP Forwarding : `sysctl -w net.ipv4.ip_forward=1`
|
||||
- Si besoin, mettre une règle de NAT, par exemple sous Linux : `iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE`
|
||||
|
||||
Pour lancer le connexion VPN, on fera :
|
||||
|
||||
~~~
|
||||
# ssh -w 42:42 ssh.example.com
|
||||
~~~
|
||||
|
||||
On a ensuite un périphérique "tun42" utilisable des 2 côtés à configurer.
|
||||
On a ensuite un périphérique `tun42` utilisable des 2 côtés à configurer.
|
||||
|
||||
Serveur SSH : `ifconfig tun42 172.17.18.2/24`
|
||||
En local : `ifconfig tun42 172.17.18.1/24`
|
||||
- Côté serveur SSH : `ifconfig tun42 172.17.18.2/24`
|
||||
- Côté client SSH : `ifconfig tun42 172.17.18.1/24`
|
||||
|
||||
On peut alors router au niveau IP :
|
||||
On peut alors enfin configurer le routage au niveau client, par exemple sous Linux :
|
||||
|
||||
~~~
|
||||
# ip route add 8.8.8.8/32 via 172.17.18.2 dev tun42`
|
||||
~~~
|
||||
|
||||
## Connexion SSH par rebond
|
||||
### UserKnownHostsFile
|
||||
|
||||
Il se peut qu'on doive passer par une machine pour se connecter à une
|
||||
machine cible (c'est le principe d'un
|
||||
[bastion](https://fr.wikipedia.org/wiki/Bastion_(informatique))) :
|
||||
OpenSSH se sert du fichier `~/.ssh/known_hosts` pour retenir le fingerprint de chaque connexion effectuée.
|
||||
Cela lui permet de détecter un changement des clés du serveur, notamment une tentative d'usurpation d'un serveur :
|
||||
|
||||
~~~
|
||||
$ ssh -J bastion machine-cible
|
||||
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
|
||||
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
|
||||
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
|
||||
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
|
||||
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
|
||||
It is also possible that a host key has just been changed.
|
||||
~~~
|
||||
|
||||
À noter que cela nécessite une version récente d'OpenSSH (celle
|
||||
présente dans Stretch est ok, mais pas celle de Jessie)
|
||||
|
||||
### Tunnel SSH
|
||||
|
||||
#### Pour une ressource donnée
|
||||
|
||||
Si on veut accéder via la machine 192.0.2.4 à un service https hébergé sur
|
||||
192.0.2.5 mais que seule la machine 192.0.2.6 y accède on peut lancer
|
||||
la commande :
|
||||
Si besoin, on peut supprimer la ligne concernée dans `~/.ssh/known_hosts` via la commande :
|
||||
|
||||
~~~
|
||||
$ ssh -L 192.0.2.4:9000:192.0.2.5:443 192.0.2.6
|
||||
$ ssh-keygen -f "~/.ssh/known_hosts" -R ssh.example.com
|
||||
~~~
|
||||
|
||||
On peut ensuite faire pointer son navigateur sur
|
||||
https://192.0.2.4:9000.
|
||||
|
||||
#### Pour tout le trafic web
|
||||
|
||||
On lance la commande
|
||||
On peut également désactiver cette vérification en utilisant un fichier alternatif :
|
||||
|
||||
~~~
|
||||
$ ssh -D 6789 proxy
|
||||
$ ssh -o UserKnownHostsFile=/dev/null ssh.example.com
|
||||
~~~
|
||||
|
||||
Puis on configure son navigateur pour utiliser un proxy SOCKS (4a ou 5) avec
|
||||
comme adresse 127.0.0.1 et port 6789.
|
||||
### ControlMaster
|
||||
|
||||
OpenSSH peut permettre de réutiliser une connexion en cours pour d'autres connexions via l'option `ControlMaster`.
|
||||
Si l'on veut activer ce comportement, on pourra ajouter dans `~/.ssh/config` :
|
||||
|
||||
## Astuces
|
||||
~~~
|
||||
ControlMaster auto
|
||||
ControlPath ~/.ssh/ssh_control_%h_%p_%r
|
||||
~~~
|
||||
|
||||
### Séquences d'échappement
|
||||
### SSHFS
|
||||
|
||||
On peut les utiliser pour communiquer avec le client
|
||||
ssh dans le terminal. La séquence la plus connue permet de tuer une
|
||||
session qui ne répondait plus (perte de connexion internet, problème
|
||||
sur le serveur ou autre). Il faut taper sur la touche entrée puis sur
|
||||
`~` et `.`.
|
||||
[SSHFS](https://github.com/libfuse/sshfs) permet de créer des montages via une connexion SSH :
|
||||
|
||||
D'autres séquences d'échappement sont possibles, voir
|
||||
[cet article](https://lonesysadmin.net/2011/11/08/ssh-escape-sequences-aka-kill-dead-ssh-sessions/amp/).
|
||||
~~~
|
||||
# apt install sshfs
|
||||
$ sshfs ssh.example.com:/foo/bar /mnt
|
||||
$ fusermount -u /mnt/ssh
|
||||
~~~
|
||||
|
||||
|
||||
## FAQ
|
||||
|
|
@ -501,4 +693,23 @@ Pour redémarrer :
|
|||
# start-stop-daemon --start --quiet --pidfile /var/run/sshd.pid --exec /usr/sbin/sshd
|
||||
~~~
|
||||
|
||||
### Peut-on encore utiliser une clé SSH DSA ?
|
||||
|
||||
Les clés SSH avec l'algorithme DSA sont dépréciées depuis Stretch.
|
||||
|
||||
### Limitation du temps de connexion via SSH
|
||||
|
||||
On peut limiter le temps d'une connexion SSH inactive en utilisant la variable d'environnement *TMOUT*.
|
||||
On peut provoquer une déconnexion automatique au bout d'1h d'activité en positionnant :
|
||||
|
||||
~~~
|
||||
export TMOUT=3600
|
||||
~~~
|
||||
|
||||
À l'inverse, si l'on veut éviter une déconnexion automatique quand cette variable est positionnée, on peut la supprimer ou l'augmenter :
|
||||
|
||||
~~~
|
||||
$ unset TMOUT
|
||||
$ export TMOUT=999999
|
||||
~~~
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue