wiki/HowtoSSH.md

249 lines
6.2 KiB
Markdown
Raw Normal View History

2017-10-19 17:47:17 +02:00
categories: OpenBSD sysadmin
title: Howto SSH
...
* Documentation : <https://www.openssh.com/manual.html>
SSH est un protocol réseau permettant de se connecter sur une machine
à travers le réseau de manière sécurisée. Nous utilisons
l'implémentation la plus répandue : OpenSSH. Ce protocol existe en
plusieurs versions et nous utilisons uniquement la version 2. La
version 1 comporte des failles de sécurité et ne doit plus être utilisée.
2016-12-29 11:25:39 +01:00
# Howto SSH : Secure SHell
## Installation
### Debian
~~~
# apt install openssh-server
~~~
### 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.
## Configuration SSH
2017-10-20 20:47:43 +02:00
### Configuration minimale
TODO
### Log verbeux pour SFTP
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 :
~~~
Subsystem sftp /usr/libexec/openssh/sftp-server -l INFO
~~~
### SFTP chroot
Voici un ensemble de commandes pouvant être utilisées 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 :
~~~
# Répertoire dans lequel SSHD va se chrooter
mkdir /home/sftp
chmod 755 /home/sftp
# 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/
~~~
Dans le fichier /etc/ssh/sshd_config :
~~~
Subsystem sftp internal-sftp
Match group sftp
ChrootDirectory /home/sftp
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
~~~
### SFTP Only
Mettre shell /usr/lib/sftp-server pour l'utilisateur et s'assurer que ce shell est bien présent dans /etc/shells
~~~
# usermod -s /usr/lib/sftp-server userna
# echo '/usr/lib/stfp-server' >> /etc/shells
~~~
2016-12-29 11:25:39 +01:00
## Administration SSH
2017-10-20 20:58:02 +02:00
### .ssh/config
Il est possible de configurer des sortes d'*alias* pour son
utilisateur unix via le fichier ~/.ssh/config
Un exemple plutôt complet (on n'a pas besoin forcément de décrire tout
ça) sans être exhaustif :
~~~
Host www00
Hostname www00.example.com
Port 2222
User johndoe
2017-10-20 21:14:10 +02:00
IdentityFile ~/.ssh/id_ed25519
2017-10-20 20:58:02 +02:00
ProxyCommand ssh bastion -W %h:%p
~~~
2017-10-20 21:12:10 +02:00
### 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
retenir en mémoire le mot de passe (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 :
~~~
eval $(ssh-agent) 1> /dev/null
~~~
Ensuite pour rajouter la clé dans un agent il suffit de taper la
commande
~~~
$ 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é 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
2017-10-20 21:14:50 +02:00
se connecter à des machines via une autre machine. Cependant cela donne
2017-10-20 21:12:10 +02:00
accès aux utilisateurs root la machine sur laquelle vous mettez votre
agent de se connecter, en utilisant vos clés, à d'autres machines. On
privilègera donc d'utiliser l'option -J de ssh(1) pour faire un rebond.
2017-10-19 19:35:14 +02:00
### Obtenir l'empreinte de la clé publique du serveur
2017-01-03 11:20:35 +01:00
2016-12-29 11:25:39 +01:00
~~~
2017-10-19 17:53:21 +02:00
$ ssh-keygen -lf /etc/ssh/clé.pub
2016-12-29 11:25:39 +01:00
~~~
2017-10-19 19:35:14 +02:00
### Regénérer les clés du serveur
2017-01-03 11:20:35 +01:00
2017-10-19 17:53:21 +02:00
Sous Debian :
2017-01-03 11:20:35 +01:00
2016-12-29 11:25:39 +01:00
~~~
# mv /etc/ssh/{moduli,*key*} /tmp/ssh/
# dpkg-reconfigure openssh-server
Creating SSH2 RSA key; this may take some time ...
Creating SSH2 DSA key; this may take some time ...
Restarting OpenBSD Secure Shell server: sshd.
~~~
2017-10-19 17:55:23 +02:00
Sous OpenBSD :
~~~
# rm -i /etc/ssh/ssh_host_*
2017-10-19 17:55:23 +02:00
# ssh -A
ssh-keygen: generating new host keys: RSA DSA ECDSA ED25519
~~~
2017-10-19 19:52:53 +02:00
À noter que c'est fait à chaque boot (via */etc/rc*), si les clés
n'existent pas donc une autre solution est de supprimer les clés et de
rebooter.
2017-10-19 17:55:23 +02:00
### reload/restart le démon ssh sur Debian sans passer par le script d'init
Pour reload :
~~~
# start-stop-daemon --stop --signal 1 --quiet --oknodo --pidfile /var/run/sshd.pid --exec /usr/sbin/sshd
~~~
Pour redémarrer :
~~~
# start-stop-daemon --stop --quiet --oknodo --retry 30 --pidfile /var/run/sshd.pid
# start-stop-daemon --start --quiet --pidfile /var/run/sshd.pid --exec /usr/sbin/sshd
~~~
2017-10-19 17:56:06 +02:00
## Restriction de l'accès d'une clé ssh
2016-12-29 11:25:39 +01:00
Pour autoriser une clé SSH en limitant les accès via _.ssh/authorized_keys_ :
~~~
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa XXXXX commentaires
~~~
### VPN over SSH
2016-12-29 11:25:39 +01:00
Côté serveur SSH :
- Ajouter "PermitTunnel yes" dans la config ssh
- sysctl -w net.ipv4.ip_forward=1
- iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Puis se connecter de root vers root :
~~~
# ssh -w 42:42 ssh.example.com
~~~
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
On peut alors router au niveau IP :
ip route add 8.8.8.8/32 via 172.17.18.2 dev tun42
2017-10-19 18:00:22 +02:00
## Connexion SSH par rebond
Il se peut qu'on doive passer par une machine pour se connecter à une
machine cible (c'est le principe d'un
2017-10-19 18:02:32 +02:00
[bastion](https://fr.wikipedia.org/wiki/Bastion_(informatique))) :
2017-10-19 18:00:22 +02:00
~~~
$ ssh -J bastion machine-cible
~~~
À noter que cela nécessite une versione récente d'OpenSSH (celle
2017-10-20 20:50:01 +02:00
présente dans Stretch est ok, mais pas celle de Jessie)
2017-10-19 18:00:22 +02:00
### Tunnel SSH
#### Pour une ressource donnée
Si on veut accéder de 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 :
~~~
$ ssh -L 192.0.2.4:9000:192.0.2.5:443 192.0.2.6
~~~
On peut ensuite faire pointer son navigateur sur
https://192.0.2.4:9000.
#### Pour tout le trafic web
2017-10-19 19:50:28 +02:00
On lance la commande
~~~
$ ssh -D 6789 proxy
~~~
Puis on configure son navigateur pour utiliser un proxy SOCKS (4a ou 5) avec
comme adresse 127.0.0.1 et port 6789.