Ceci est une ancienne révision du document !
SSH
-i <cle_privee>: permet de préciser avec quelle clé privée on souhaite s'authentifier-v: mode verbose-o: préciser des options (un-opar option)-L: forward un port local vers un port sur une machine distant:ssh -L <adresselocale>:<portlocal>:<adressedistante>:<portdistant>-F: indique quel fichierssh/configutiliser.-F /dev/nullcorrespond à n'utiliser aucun fichier de configuration.
Si l'adresse locale est 127.0.0.1, seule la machine locale pour l'utiliser, si on met 0.0.0.0, tous les ordinateurs pourront se connecter à ce port.
Le dossier .ssh doit avoir les permissions 700.
ssh-keygen -t ed25519 -a 100 -C "Comment"
Options
UserKnownHostsFile=/dev/null: le fichier known_hosts est /dev/null, utile pour ne pas sauvegarder la clé publique du serveur SSHStrictHostKeyChecking=no: ne pas demander la confirmation d'ajout de la nouvelle clé (ajouter un espace après leno!)PreferredAuthentications=password: passer directement à la méthode d'authentification par mot de passe, sans essayer les clés privée du dossier.sshForwardAgent=yes: les clés SSH du client suivent dans les connexions distantes (utile pour faire des connexions SSH imbriquées)
Créer un tunnel de port-forwarding
A – B – C
B va transmettre les données d'un port qu'il expose vers un port de C. C recevra les données que A envoie à B.
ssh -N -R <port de B>:<adresse IP locale de C>:<port de C> <IP de B>
Utiliser un serveur de rebond
On peut se servir de cette commande pour connecter l'ordinateur C à un serveur de rebond B lorsque C n'est pas accessible depuis l'extérieur d'un réseau.
Sur la machine C:
ssh -NTR 2222:localhost:22 user@serveur-rebond-b
Ainsi le port 22 de C sera accessible localement depuis le serveur de rebond B par le port 2222.
Il faut s'assurer sur le serveur de rebond B que AllowTcpForwarding yes soit présent dans le fichier /etc/ssh/sshd_config et que le port 2222 ne soit pas bloqué par un parefeu.
Pour accéder à la machine C depuis le serveur B:
ssh -p 2222 user-c@localhost
Tunnel pour faire passer le trafic d'un port par SSH
ssh -NL <local port>:localhost:<remote port> remote_host
Tunnel de port dynamique
Si seule la machine A peut accéder à la machine B et qu'on a une connexion à la machine A :
ssh -ND 8080 A
Cela crée un proxy socks qui écoute sur le port 8080 de la machine local. On peut ensuite configurer Firefox (about:profiles pour le faire uniquement dans un profil spécifique) pour utiliser ce proxy (proxy SOCKSv5 sur 127.0.0.1:8080).
Paramètres
-N: n'ouvre pas de shell distant pour saisir des commandes, reste bloqué, utile pour forwarder un port
Transférer sa clé publique vers un serveur
ssh-copy-id [-i clé] [user@]hostname
Le mot de passe du compte distant est demandé.
Agent SSH
Ajouter une clé à l'agent SSH:
ssh-add ~/.ssh/id_rsa
Lister les clés connues par l'agent SSH:
ssh-add -l # ou -L
Supprimer toutes les clés connues de l'agent:
ssh-add -D
Automatiquement charger les clés SSH dans l'agent (Source):
- ~/.ssh/config
AddKeysToAgent yes
Réévaluer l'agent, si les commandes comme ssh-add ne parviennent pas à se connecter à l'agent SSH, mais que la commande ssh-agent renvoie quelque chose de cohérent, il peut être nécessaire de saisir la commande suivante:
eval "$(ssh-agent)"
Effacer les clés de l'agent SSH (Source):
sudo pkill -9 gnome-keyring-daemon eval $(ssh-agent) ssh-add -l # ne renvoie rien
Empêcher OpenSSH de donner son OS
Valable uniquement sur Debian.
- /etc/ssh/sshd_config
DebianBanner no
Monter un système de fichier SSHFS
Installer le paquet sshfs.
Montage:
sshfs host:[folder] [mounpoint]
Démontage:
fusermount -u [mountpoint]
X Forwarding
Utiliser ssh -X.
Si une erreur du style x11 forwarding request failed on channel 0 apparaît, essayer la configuration suivante:
- /etc/sshd/sshd_config
X11Forwarding yes X11UseLocalhost no
Fichier ssh/config
La configuration est documentée dans la page de man de ssh_config.
- ~/.ssh/config
ForwardAgent yes # transmet les clés SSH du client, pour qu'elles soient disponibles dans la session SSH Host alias # permet de faire ssh alias HostName real.fqdn.foo IdentityFile ~/.ssh/key_rsa User login ForwardX11 yes
Pour forcer l'utilisation de l'IPv4 :
AddressFamily inet
Fichier authorized_keys
Sa syntaxe est documentée dans la page de man de sshd.
Chaque clé dans le fichier peut être précédée d'instructions pour limiter l'utilisation de la clé. Par exemple :
restrict,from=“10.0.0.1”,command=“<une commande>” <clé>empêche l'utilisation de toutes les fonctionnalités de SSH, permet l'utilisation de la clé seulement depuis le client 10.0.0.1 et exécute la commande spécifiée une fois l'authentification réussierestrict,port-forwarding<clé>empêche l'utilisation de toutes les fonctionnalités, ne permet que le port-forwarding (pour faire du ProxyJump, par exemple).
ProxyJump
Pour passer à travers (plusieurs) serveur(s) de rebond avant d'atteindre le serveur cible :
Host rpi-a
ProxyJump rpi-b
HostName 10.0.0.3
IdentityFile ~/.ssh/rpi_ed25519
Port 3233
Passe par rpi-b pour se connecter à rpi-a. Les autres paramètres fournis seront utilisés pour la connexion SSH que fera rpi-b vers rpi-a (l'adresse 10.0.0.3 n'a de sens que sur rpi-b, par exemple ici). Toute la configuration relative à la connexion à rpi-b est dans l'entrée dédiée à rpi-b dans le fichier de configuration.
Tuer une session SSH bloquée
Enchaîner les touches Entrée, ~ et ..
Tester la configuration serveur
sshd -t
Si l'erreur Missing privilege separation directory: /run/sshd apparaît:
mkdir -p /run/sshd
Changer le port d'écoute
Changer dans le fichier /etc/ssh/sshd_config. Si SystemD est utilisé, il faut aussi modifier le service qui définit la socket (source) :
systemctl edit ssh.socket
Puis y mettre :
[Socket] ListenStream= ListenStream=3233
