SSH

Installation

# Installer le serveur et le client pacman -S openssh

Serveur

# redémarrer le service systemctl restart sshd # Historique des connexions cat /var/log/auth.log

Configuration

/etc/ssh/sshd_config

# Connexion de root (défaut: prohibit-password) # bans all interactive authentication methods, allowing only public-key, hostbased and GSSAPI authentication # ‘prohibit-password’ is a less-ambiguous synonym of ‘without-password’ PermitRootLogin prohibit-password # autorise la connexion de root PermitRootLogin yes # interdit la connexion de root PermitRootLogin no # désactiver l'authentification par login et password (défaut: yes) PasswordAuthentication no # ask password to the user (défaut: ?) ChallengeResponseAuthentication no # Pluggable Authentication Module (défaut: no) UsePAM no # liste les utilisateurs autorisés à se connecter, tous les autres sont interdit AllowUsers user1 user2@192.168.x.y # user1 from anywhere # user2 only from 192.168.x.y # liste les utilisateurs non-autorisés à se connecter DenyUsers user1 user2

Pour que les modifications soient prises en compte il faut redémarrer le serveur SSH

Client

Linux

ssh login@remote-host -p port 'remote command' # par défaut le port 22 est utilisé # plusieurs commandes (Here Documents) ssh login@remote-host /bin/bash << EOF pwd ls -al EOF # tunnel SSH # entrée localhost:9999 # sortie remote-host:5900 ssh -C -NL 9999:localhost:5900 login@remote-host # -C : compréssion des données, util pour les connexions à faible débit # -N : ne pas éxécuter de commande sur le poste distant

Pour avoir des couleurs dans la console, il faut configurer le fichier .bashrc de l'hôte

Pour quitter le terminal en laissant une commande tourner, utiliser disown

Pseudo-terminal will not be allocated because stdin is not a terminal. Use ssh -T to disable pseudo-tty allocation.

Windows

Cygwin

Installer openssh

PuTTY

Coller	clique-droit ou Shift+Ins ou Ctrl+clique-droit+Paste
Private key	Connection → SSH → Auth
Home / End	Connection → Data → Terminal Details → Terminal-type string = linux

Utilisez l'installeur qui contient tous les binaires utiles.

pscp

# copie d'un fichier distant vers le poste local pscp user@host:/remote/path/file.txt C:\folder # copie d'un fichier local vers le poste distant pscp C:\folder\file.txt user@host:/remote/path/folder # pour une authentification avec une clé pscp -i C:\path\id_rsa.ppk user@host:/remote/path/file.txt C:\folder # utiliser pageant pour ne pas avoir à entrer la passphrase à chaque fois

Authentification avec une clé SSH

Problème avec les caractères accentués.

SFTP

Filezilla

Copie de fichiers et de dossiers

rsync

# téléchargement du fichier-distant, puis suppression du fichier sur le serveur rsync --remove-source-files compte-distant@serveur-ssh:/chemin/serveur/ssh/fichier-distant /chemin/local rsync -avz --delete-after /chemin/dossier user@remote-host:/chemin/dossier/

rsync doit être installé sur le client et le serveur.

Utilisation de rsync avec sudo: Si rsync est utilisé avec sudo, c'est le compte root local qui va tenter de se connecter au serveur ssh. Dans le cas d'une utilisation avec clé ssh, le compte root ne peut pas débloquer de passphrase, car les passphrases sont stockées dans gnome-keyring qui se déverrouille à la connexion au Desktop Manager. Dans ce cas il est facilitant de ne pas utiliser de passphrase afin de se connecter directement.

SCP

Copie de fichiers vers le serveur SSH

# envoie du fichier-local vers le serveur scp fichier-local compte-distant@serveur-ssh:/chemin/serveur/ssh # téléchargement du fichier-distant scp compte-distant@serveur-ssh:/chemin/serveur/ssh/fichier-distant /chemin/local

fingerprint

À la première connexion à un serveur, l'empreinte (fingerprint) de la clé RSA du serveur est affichée afin de vérifier que le serveur auquel on se connecte est bien celui que l'on croit.

# afficher l'empreinte de la clé RSA du serveur depuis le serveur ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub

SSHKeys

Permet une authentification sans mot de passe.
Ajouter la clé publique du client dans les clé autorisées du serveur.

La saisie d'une passphrase lors de la génération de la clé privée nécessitera par la suite de lancer un ssh-agent et d'entrée cette passphrase pour déverrouiller la clé privée.

# génération des clés privée et publique depuis le client # Ed25519 : most recommended public-key algorithm available today ssh-keygen -t ed25519 -C "$(whoami)@$(hostname)-$(date -I)" # RSA ssh-keygen -o -b 4096 -C "$(whoami)@$(hostname)-$(date -I)" # clé privée: ~/.ssh/id_rsa # clé publique: ~/.ssh/id_rsa.pub # -b 4096 passez le chiffrement à 4096 bits au lieu des 3072 par défaut # -o encode your private key in a new, more secure format # -C commentaire # envoyer la clé publique depuis le client au serveur ssh-copy-id <username>@<ssh-server> # <username> correspond au compte du serveur SSH avec lequel on souhaite être connecté (ex: root) # méthode manuelle mkdir ~/.ssh chmod 700 ~/.ssh # ajouter le contenu du fichier id_rsa.pub au fichier authorized_keys chmod 600 ~/.ssh/authorized_keys

La commande ssh-copy-id ajoute le contenu du fichier ~/.ssh/id_rsa.pub au fichier serveur <userhome>/.ssh/authorized_keys Le fichier <userhome>/.ssh/authorized_keys peut ainsi contenir plusieurs clés autorisant différent utilisateurs.

Désactiver l'authentification par mots de passe une fois l'authentification par clés activée.

Supprimer la passphrase

openssl rsa -in ~/.ssh/id_rsa -out ~/.ssh/id_rsa_new mv ~/.ssh/id_rsa ~/.ssh/id_rsa_with_passphrase mv ~/.ssh/id_rsa_new ~/.ssh/id_rsa

Restrictions dans la clé publique

~/.ssh/authorized_keys

from="192.168.0.1,192.168.0.*?,*.example.com", command="/bin/pwd", ,no-port-forwarding,no-x11-forwarding,no-agent-forwarding ssh-rsa AA...== comment-client-user@client-hostname

SSH agents

Permet de mettre en cache la clé privée déchiffrée avec la passphrase et ainsi ne la demander que la première fois.

# lancer l'agent eval $(ssh-agent) # ajouter la clé privée, la passphrase sera demandée si la clé privée est chiffrée ssh-add ~/.ssh/id_rsa # lister les clés chargées ssh-add -L # décharger toutes les clés ssh-add -D # lancer l'agent s'il n'est pas déjà lancer et ajouter la clé (~/.ssh/id_rsa) eval $(keychain --eval id_rsa)

Terminal Linux

Ce problème ne semble plus d'actualité et cette solution créé le problème suivant: Terminal gives the message "discover_other_daemon: 1"

La variable SSH_AUTH_SOCK n'est pas initialisée.

~/.zshenv

# Initialiser SSH_AUTH_SOCK à l'ouverture du terminal if [ -n "$DESKTOP_SESSION" ];then eval $(gnome-keyring-daemon --start) export SSH_AUTH_SOCK fi

SSHKeys avec PuTTY

Générer les clés

• Lancer PuTTYgen
• Générer une clé privé et publique (RSA ou SSH-2 RSA, 4096 bits)
• Entrer une passphrase (512)
• Sauvegarder la clé publique %HOMEPATH%\ssh\id_rsa.pub et la clé privée %HOMEPATH%\ssh\id_rsa.ppk via les 2 boutons Save

Autoriser la clé publique sur le serveur SSH

• PuTTYgen → copier "Public key for pasting into OpenSSH authorized_keys file"
• Serveur SSH → coller la clé publique dans le fichier ~/.ssh/authorized_keys
• Vérifier que ce fichier n'est accessible que par l'utilisateur chmod 600

Ajouter la clé privée à la session PuTTY

• Session → Créer ou charger une session
• Connection → SSH → Auth → spécifiez le chemin vers la clé privée
• Session → Sauvegarder la session

Auto-login: utilisateur par défaut

• Session → Créer ou charger une session
• Connexion → Data → Auto-login username
• Session → Sauvegarder la session

Pageant

• lancer pageant
• double-cliquer sur l’icône pageant dans la barre des icônes
• Add key → sélectionner la clé privée

Pageant tourne en tache de fond et déverrouille la clé privée au besoin.
Pageant n'enregistre ni l'emplacement de la clé privée ni la passphrase: à la prochaine exécution il faudra recommencer
Il est possible de créer un raccourci pour que la clé privée soit ajoutée au lancement:
"C:\path\to\pageant.exe" "C:\path\to\private_key.ppk"

Désactiver les connexions avec login et mot de passe

/etc/ssh/sshd_config

Protocol 2 PasswordAuthentication no UsePAM no

# puis redemarrez le serveur SSH sudo systemctl restart sshd

Langue

Par défaut les variable LANG et LC_* ne semble pas être définit après une connexion ssh.
Pour forcer leur définition, il faut authoriser le client à envoyer ses valeurs et le serveurs à les recevoir.

/etc/ssh/ssh_config

# client Host * SendEnv LANG LC_*

/etc/ssh/sshd_config

# serveur AcceptEnv LANG LC_*

Erreurs

# debug client ssh -vvv user@host # vérifier la configuration serveur sshd -t # debug serveur sshd -Dddd

REMOTE HOST IDENTIFICATION HAS CHANGED!

Le fichier ~/.ssh/known_hosts contient une clé d'identification qui ne correspond pas à la cible.

ssh-keygen -R hostname

~/.ssh/known_hosts

Contient les identifiants des serveurs SSH connus, afin de s'assurer que le client se connecte bien au bon serveur.

# supprimer un serveur du fichier known_hosts ssh-keygen -R serveur_ssh_à_supprimer

Créer un compte pour les backup

# côté serveur useradd -r -m backup passwd backup su backup mkdir .ssh # ajout de la clé du client nano .ssh/authorized_keys # côté client # génération de la clé sans mot de passe ssh-keygen -o -b 4096 -C "$(whoami)@$(hostname)-$(date -I)" # synchroniser un dossier distant rsync -rLp --progress --delete backup@server:/remote-path/folder/ /local-path/folder

sshfs

Monter un système de fichier distant au travers d'une connexion ssh.

# installation sudo pacman -S sshfs # vérifier que le module fuse est bien chargé systemctl list-units --all | grep fuse # sys-module-fuse.device # loaded active plugged /sys/module/fuse # vérifier plutôt avec lsmod lsmod | grep fuse # charger le module fuse s'il n'a pas encore été chargé sudo modprobe fuse # montez le système de fichier distant sshfs user@host:/remote/folder /mount/point # demontez le système de fichier distant fusermount -u /mount/point

/etc/fstab

user@host:/remote/folder /mount/point fuse.sshfs noauto,x-systemd.automount,_netdev,reconnect,uid=1000,gid=1000,user 0 0

Options	Explications
noauto,x-systemd.automount	Ne pas monter au démarrage mais à la demande
_netdev	Attend que le réseau soit accessible, utile pour les systèmes de fichiers distants
uid=1000 gid=1000	Force les uid et gid du système de fichier N’accepte que la forme chiffrée
user	Autorise n'importe quel utilisateur à monter le système de fichiers
allow_other	Allow other users than the mounter (i.e. root) to access the share
default_permissions	Allow kernel to check permissions, i.e. use the actual permissions on the remote filesystem. This allows prohibiting access to everybody otherwise granted by allow_other.
idmap=user	Change le UID du système de fichier par celui de l'utilisateur courant
IdentityFile=/home/user/.ssh/id_rsa	???

Connection reset by peer

Ne pas lancer sshfs avec sudo.

Client Windows: SSHFS-Win · SSHFS for Windows

chocolatey install winfsp sshfs

• Accéder au dossier d'une machine distante: \\sshfs\user@host[\path]
• Monter le dossier root d'une machine distante dans un lecteur réseau: net use S: \\sshfs\user@host\..\..

OLD Client Windows: win-sshfs (Sshfs Manager)

sshfs-win

• Url: \\sshfs\user@host
• Network drive: \\sshfs\user@host\..\..

Ne permet pas la connexion avec une clé privée.

win-sshfs

1. installer WinSSHFS
2. lancer WinSshFS

Erreur unable to load DLL 'dokan1.dll'

1. télécharger le zip de dokan 1.0.5
2. extraire Win32\Release\dokan1.dll dans C:\Program Files (x86)\WinSshFS
3. installer dokan 1.1.0.2000

Pour la connexion avec une clé privée, utiliser pageant