mirroir readonly du Gitit wiki.evolix.org (attention, ne rien commiter/merger sur ce dépôt) https://wiki.evolix.org
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

920 lines
30 KiB

3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
  1. ---
  2. categories: openbsd sysadmin
  3. title: Howto OpenSSH
  4. ...
  5. * Documentation : <https://www.openssh.com/manual.html>
  6. [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.
  7. OpenSSH est développé par le projet [OpenBSD](HowtoOpenBSD) avec une grande attention sur la sécurité. Il offre de nombreuses fonctionnalités : SCP, SFTP, clés SSH, tunnels, VPN, etc.
  8. ## Installation
  9. ### Debian
  10. On peut installer les parties client et serveur indépendamment :
  11. ~~~
  12. # apt install openssh-client
  13. # ssh -V
  14. OpenSSH_7.4p1 Debian-10+deb9u1, OpenSSL 1.0.2l 25 May 2017
  15. # apt install openssh-server
  16. # nc localhost 22
  17. SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u1
  18. # systemctl status ssh
  19. ● ssh.service - OpenBSD Secure Shell server
  20. Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
  21. Main PID: 1715 (sshd)
  22. Tasks: 1 (limit: 4915)
  23. CGroup: /system.slice/ssh.service
  24. └─1715 /usr/sbin/sshd -D
  25. ~~~
  26. ### OpenBSD
  27. Les parties client et serveur sont incluses dans la base OpenBSD.
  28. ~~~
  29. $ ssh -V
  30. OpenSSH_7.5, LibreSSL 2.5.2
  31. ~~~
  32. La partie serveur est activée par défaut, sauf mention contraire à l'installation.
  33. ~~~
  34. # grep -r sshd /etc/rc.conf*
  35. /etc/rc.conf:sshd_flags=
  36. /etc/rc.conf.local:sshd_flags=NO
  37. # rcctl enable sshd
  38. ~~~
  39. ## Configuration
  40. ### Configuration sshd_config
  41. <http://man.openbsd.org/sshd_config>
  42. Fichiers de configuration :
  43. ~~~
  44. /etc/ssh
  45. ├── moduli
  46. ├── ssh_config
  47. ├── sshd_config
  48. ├── ssh_host_ecdsa_key
  49. ├── ssh_host_ecdsa_key.pub
  50. ├── ssh_host_ed25519_key
  51. ├── ssh_host_ed25519_key.pub
  52. ├── ssh_host_rsa_key
  53. └── ssh_host_rsa_key.pub
  54. ~~~
  55. La configuration de base que nous utilisons en général (les options commentées sont les valeurs par défaut).
  56. ~~~
  57. # $OpenBSD: sshd_config,v 1.100 2016/08/15 12:32:04 naddy Exp $
  58. # This is the sshd server system-wide configuration file. See
  59. # sshd_config(5) for more information.
  60. # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin
  61. # The strategy used for options in the default sshd_config shipped with
  62. # OpenSSH is to specify options with their default value where
  63. # possible, but leave them commented. Uncommented options override the
  64. # default value.
  65. Port 22
  66. Port 2200
  67. #AddressFamily any
  68. #ListenAddress 0.0.0.0
  69. #ListenAddress ::
  70. #HostKey /etc/ssh/ssh_host_rsa_key
  71. #HostKey /etc/ssh/ssh_host_ecdsa_key
  72. #HostKey /etc/ssh/ssh_host_ed25519_key
  73. # Ciphers and keying
  74. #RekeyLimit default none
  75. # Logging
  76. #SyslogFacility AUTH
  77. LogLevel VERBOSE
  78. # Authentication:
  79. #LoginGraceTime 2m
  80. PermitRootLogin no
  81. #StrictModes yes
  82. #MaxAuthTries 6
  83. #MaxSessions 10
  84. #PubkeyAuthentication yes
  85. # Expect .ssh/authorized_keys2 to be disregarded by default in future.
  86. #AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2
  87. #AuthorizedPrincipalsFile none
  88. #AuthorizedKeysCommand none
  89. #AuthorizedKeysCommandUser nobody
  90. # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
  91. #HostbasedAuthentication no
  92. # Change to yes if you don't trust ~/.ssh/known_hosts for
  93. # HostbasedAuthentication
  94. #IgnoreUserKnownHosts no
  95. # Don't read the user's ~/.rhosts and ~/.shosts files
  96. #IgnoreRhosts yes
  97. # To disable tunneled clear text passwords, change to no here!
  98. #PasswordAuthentication yes
  99. #PermitEmptyPasswords no
  100. # Change to yes to enable challenge-response passwords (beware issues with
  101. # some PAM modules and threads)
  102. ChallengeResponseAuthentication no
  103. # Kerberos options
  104. #KerberosAuthentication no
  105. #KerberosOrLocalPasswd yes
  106. #KerberosTicketCleanup yes
  107. #KerberosGetAFSToken no
  108. # GSSAPI options
  109. #GSSAPIAuthentication no
  110. #GSSAPICleanupCredentials yes
  111. #GSSAPIStrictAcceptorCheck yes
  112. #GSSAPIKeyExchange no
  113. # Set this to 'yes' to enable PAM authentication, account processing,
  114. # and session processing. If this is enabled, PAM authentication will
  115. # be allowed through the ChallengeResponseAuthentication and
  116. # PasswordAuthentication. Depending on your PAM configuration,
  117. # PAM authentication via ChallengeResponseAuthentication may bypass
  118. # the setting of "PermitRootLogin without-password".
  119. # If you just want the PAM account and session checks to run without
  120. # PAM authentication, then enable this but set PasswordAuthentication
  121. # and ChallengeResponseAuthentication to 'no'.
  122. UsePAM yes
  123. #AllowAgentForwarding yes
  124. #AllowTcpForwarding yes
  125. #GatewayPorts no
  126. X11Forwarding yes
  127. #X11DisplayOffset 10
  128. #X11UseLocalhost yes
  129. #PermitTTY yes
  130. PrintMotd no
  131. #PrintLastLog yes
  132. #TCPKeepAlive yes
  133. #UseLogin no
  134. #UsePrivilegeSeparation sandbox
  135. #PermitUserEnvironment no
  136. #Compression delayed
  137. #ClientAliveInterval 0
  138. #ClientAliveCountMax 3
  139. #UseDNS no
  140. #PidFile /var/run/sshd.pid
  141. #MaxStartups 10:30:100
  142. #PermitTunnel no
  143. #ChrootDirectory none
  144. #VersionAddendum none
  145. # no default banner path
  146. #Banner none
  147. # Allow client to pass locale environment variables
  148. #AcceptEnv LANG LC_*
  149. # override default of no subsystems
  150. Subsystem sftp /usr/lib/openssh/sftp-server -l INFO
  151. # Example of overriding settings on a per-user basis
  152. #Match User anoncvs
  153. # X11Forwarding no
  154. # AllowTcpForwarding no
  155. # PermitTTY no
  156. # ForceCommand cvs server
  157. AllowUsers jdoe alice bob
  158. Match Address 192.0.2.42
  159. PasswordAuthentication yes
  160. Match User alice bob
  161. PasswordAuthentication no
  162. Match Group adm
  163. PasswordAuthentication no
  164. ~~~
  165. ### Configuration ssh_config
  166. <http://man.openbsd.org/ssh_config>
  167. On peut configurer la partie client via le fichier `~/.ssh/config`.
  168. On peut ainsi passer certaines options générales :
  169. ~~~
  170. UseRoaming no
  171. User jdoe
  172. IdentityFile ~/.ssh/id_ed25519
  173. IdentityFile ~/.ssh/id_rsa
  174. ~~~
  175. On peut aussi passer des options spécifiques à chaque serveur distant sur lequel on va se connecter.
  176. On définit ainsi des *alias* (utilisables ensuite via `ssh`) et des options correspondantes :
  177. ~~~
  178. Host foo ssh.example.com
  179. Hostname ssh.example.com
  180. Port 2222
  181. User john
  182. Host sql.example.com
  183. IdentityFile ~/.ssh/id_bastion_ed25519
  184. ProxyCommand ssh bastion.example.com -W %h:%p
  185. StrictHostKeyChecking no
  186. UserKnownHostsFile /dev/null
  187. Host nfs.example.com
  188. ProxyCommand ssh -W bastion.example.com:2222 john@192.0.2.111
  189. Host switch42
  190. User admin
  191. HostName 192.0.2.150
  192. ProxyCommand sh -c "nc -w1 %h %p 2>/dev/null || ssh bastion.example.com -W %h:%p"
  193. KexAlgorithms diffie-hellman-group1-sha1
  194. ~~~
  195. Pour les cas simples d'utilisation de `ProxyCommand`, il est possible d'utiliser `ProxyJump [user@]host[:port]` (équivalent à l'option `-J` en ligne de commande :
  196. ~~~
  197. Host private.example.com
  198. ProxyJump bastion.example.com
  199. ~~~
  200. ## SCP
  201. 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.
  202. Utilisation simple :
  203. ~~~
  204. $ scp /foo/FICHIER ssh.example.com:/bar/
  205. ~~~
  206. Pour envoyer un répertoire, on utilisera l'option `-r` :
  207. ~~~
  208. $ scp -r /foo/ ssh.example.com:/bar/
  209. ~~~
  210. Options utiles pour `scp` :
  211. * `-P 2222` : utilise le port 2222 pour le serveur distant (malheureusement différent de `ssh`…)
  212. * `-q` : mode silencieux
  213. * `-C` : active la compression
  214. * `-i identity_file` : utilise une clé SSH spécifique
  215. ## SFTP
  216. 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 :
  217. ~~~
  218. $ sftp ssh.example.com
  219. Connected to ssh.example.com.
  220. sftp> ls
  221. sftp> lls
  222. sftp> pwd
  223. sftp> get FICHIER
  224. sftp> put FICHIER
  225. sftp> bye
  226. ~~~
  227. ### chroot SFTP
  228. 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.
  229. Pour mettre en place un chroot SFTP, on crée un répertoire `/home/sftp` et un groupe `sftp` :
  230. ~~~
  231. # mkdir /home/sftp
  232. # chown root:sftp /home/sftp
  233. # chmod 750 /home/sftp
  234. # groupadd sftp
  235. ~~~
  236. et on configure via `/etc/ssh/sshd_config` :
  237. ~~~
  238. Subsystem sftp internal-sftp
  239. Match group sftp
  240. ChrootDirectory /home/sftp
  241. X11Forwarding no
  242. AllowTcpForwarding no
  243. ForceCommand internal-sftp
  244. ~~~
  245. On peut ensuite créer un utilisateur restreint :
  246. ~~~
  247. # useradd -g sftp -d /jdoe jdoe
  248. # mkdir /home/sftp/jdoe/
  249. # chown jdoe:sftp /home/sftp/jdoe/
  250. # chmod 700 /home/sftp/jdoe/
  251. ~~~
  252. ### SFTP Only
  253. On peut restreindre un utilisateur au protocole SFTP.
  254. Il faut s'assurer que `/usr/lib/sftp-server` soit un shell valide et lui définir comme shell par défaut :
  255. ~~~
  256. # echo '/usr/lib/stfp-server' >> /etc/shells
  257. # usermod -s /usr/lib/sftp-server userna
  258. ~~~
  259. ## Clé SSH
  260. Il y a plusieurs types de clé, avec suivant les algorithmes, des tailles de clés variables ou non.
  261. L'algorithme que nous conseillons est *ed25519* mais attention, ce n'est pas supporté sur des anciennes machines (Debian 7 par exemple) où il faut utiliser l'algorithme *RSA* (on conseille alors d'utiliser une taille de clé de 4096).
  262. Attention, lors de la génération de votre paire de clés, si vous ne conservez pas le nom et l'emplacement par défaut ( qui est sous la forme `~/.ssh/id_{rsa,ed25519}`) alors la clé ne sera pas utilisée par le client SSH. Il faudra alors lui indiquer de l'utiliser de manière explicite avec avec l'argument *-i* pour spécifier la clé privée, ou le définir dans le [fichier de configuration de SSH](#configuration-ssh_config),
  263. Pour générer une clé SSH *ed25519* :
  264. ~~~
  265. $ ssh-keygen -t ed25519 -a 100
  266. Generating public/private ed25519 key pair.
  267. Enter file in which to save the key (/home/jdoe/.ssh/id_ed25519):
  268. Enter passphrase (empty for no passphrase):
  269. Enter same passphrase again:
  270. Your identification has been saved in /home/jdoe/.ssh/id_ed25519.
  271. Your public key has been saved in /home/jdoe/.ssh/id_ed25519.pub.
  272. The key fingerprint is:
  273. SHA256:7tdFlczm4VJkEl4yM08O4VOPkGQiU1YR8kKuLsm9v84 jdoe@example.com
  274. The key's randomart image is:
  275. +--[ED25519 256]--+
  276. | o.*oB&**.|
  277. | * =+.#Oo|
  278. | o .+*+o|
  279. | . . .oo |
  280. | S .. |
  281. | . = . |
  282. | + + . . |
  283. | o o. . |
  284. | o+E. |
  285. +----[SHA256]-----+
  286. ~~~
  287. > *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.
  288. Pour générer une clé SSH *RSA* :
  289. ~~~
  290. $ ssh-keygen -o -t rsa -b 4096 -a 100
  291. Generating public/private rsa key pair.
  292. Enter file in which to save the key (/home/jdoe/.ssh/id_rsa):
  293. Enter passphrase (empty for no passphrase):
  294. Enter same passphrase again:
  295. Your identification has been saved in /home/jdoe/.ssh/id_rsa.
  296. Your public key has been saved in /home/jdoe/.ssh/id_rsa.pub.
  297. The key fingerprint is:
  298. SHA256:9tGKNLEbiUyAbhShJ7rncBpn/ydCXZHtJkdIsUoW2TM jdoe@example.com
  299. The key's randomart image is:
  300. +---[RSA 4096]----+
  301. | o+. .+o= |
  302. | .o ...E.o |
  303. |oo. + o* |
  304. |.oo = oo++. |
  305. |.. .+.S+. . |
  306. | . . .o * o |
  307. |+ =. o o |
  308. | X .. . . |
  309. |. . .o.o |
  310. +----[SHA256]-----+
  311. ~~~
  312. > *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.
  313. ### authorized_keys
  314. Pour autoriser une connexion avec une clé SSH, il faut la placer dans le fichier `~/.ssh/authorized_keys` et ajuster les droits :
  315. ~~~
  316. $ ssh ssh.example.com mkdir -p ~/.ssh
  317. $ ssh ssh.example.com chmod 700 ~/.ssh
  318. $ scp ~/.ssh/id_ed25519.pub ssh.example.com:.ssh/authorized_keys
  319. $ ssh ssh.example.com chmod 600 ~/.ssh/authorized_keys
  320. ~~~
  321. Pour faire cela de façon plus simple, on peut utiliser le script `ssh-copy-id` :
  322. ~~~
  323. $ ssh-copy-id ssh.example.com
  324. ~~~
  325. > *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"`
  326. On peut mettre des restrictions d'accès via le fichier `.ssh/authorized_keys`, par exemple :
  327. ~~~
  328. no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa XXXXX commentaires
  329. ~~~
  330. ### Agent SSH
  331. Il est important de protéger une clé SSH utilisée par un humain par une passphrase.
  332. Pour éviter de saisir sa passphrase à chaque utilisation, on peut utiliser un *agent SSH* qui va retenir la clé SSH en mémoire.
  333. En général, un agent SSH est lancé par son Window Manager.
  334. Sinon, on peut le lancer automatiquement via son `~/.profile` :
  335. ~~~{.bash}
  336. eval $(ssh-agent) 1> /dev/null
  337. ~~~
  338. 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 :
  339. ~~~{.bash}
  340. SSH_AUTH_SOCK=/tmp/ssh-IklIVmCGvWgT/agent.1151
  341. SSH_AGENT_PID=1198
  342. ~~~
  343. On peut alors lancer la commande `ssh-add` qui va nous demander notre passphrase pour transmettre la clé à l'agent SSH :
  344. ~~~
  345. $ ssh-add -t 36000
  346. Enter passphrase for /home/jdoe/.ssh/id_ed25519:
  347. Identity added: /home/jdoe/.ssh/id_ed25519 (/home/jdoe/.ssh/id_ed25519)
  348. ~~~
  349. > *Note* : l'option [-t](http://man.openbsd.org/ssh-agent#t) permet de limiter à 10h (36 000 secondes) 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.
  350. Sous Gnome, si vous utilisez `gnome-keyring-ssh` il se peut que vous ayez l'erreur `Could not add identity` pour votre clé id_ed25519. Il faut alors appliquer le correctif suivant :
  351. ~~~
  352. mkdir -p ~/.config/autostart
  353. cp /etc/xdg/autostart/gnome-keyring-ssh.desktop ~/.config/autostart/
  354. echo "X-GNOME-Autostart-enabled=false" >> ~/.config/autostart/gnome-keyring-ssh.desktop
  355. ~~~
  356. 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).
  357. Il va notamment lancer les agents si ils ne sont pas encore lancés, et transmettre plusieurs clés SSH si besoin.
  358. ~~~
  359. $ keychain id_ed25519 id_rsa --timeout 600
  360. * keychain 2.7.1 ~ http://www.funtoo.org
  361. * Starting ssh-agent...
  362. * Starting gpg-agent...
  363. * Adding 2 ssh key(s): /home/jdoe/.ssh/id_ed25519 /home/jdoe/.ssh/id_rsa
  364. Enter passphrase for /home/jdoe/.ssh/id_ed25519:
  365. * ssh-add: Identities added: /home/jdoe/.ssh/id_ed25519 /home/jdoe/.ssh/id_rsa (life=600m)
  366. ~~~
  367. > *Note* : on pourra bien sûr lancer *keychain* via son `~/.profile`
  368. Enfin, il existe d'autres implémentations d'agent SSH, comme le `gpg-agent` qui permet notamment l'utilisation de token USB pour sécuriser ses clés (Voir [HowtoGPG](HowtoGPG#agent-gpg)).
  369. ## Tunnel SSH
  370. Un tunnel SSH permet d'accéder à une ressource distante via une connexion SSH.
  371. Cela s'utilise classiquement pour accéder à un service distant non accessible directement.
  372. ### Tunnel SSH vers un service
  373. Exemple simple : on veut accéder à un service MySQL accessible en local sur un serveur distant.
  374. On lance la commande suivante :
  375. ~~~
  376. $ ssh -L 3306:127.0.0.1:3306 ssh.example.com
  377. ~~~
  378. Et l'on pourra accéder au service MySQL sur sa propre machine via 127.0.0.1 sur le port 3306.
  379. 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` :
  380. ~~~
  381. $ ssh -L 3306:192.0.2.33:3306 ssh.example.com
  382. ~~~
  383. On peut bien sûr utiliser un port différent pour sa propre machine, par exemple 8306 :
  384. ~~~
  385. $ ssh -L 8306:192.0.2.33:3306 ssh.example.com
  386. ~~~
  387. 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` :
  388. ~~~
  389. $ ssh -L 127.0.0.33:8306:192.0.2.33:3306 ssh.example.com
  390. ~~~
  391. Enfin il faut noter que si l'on veut utiliser un port local inférieur à 1024, il faudra lancer la commande en "root" :
  392. ~~~
  393. # ssh -L 443:127.0.0.1:443 ssh.example.com
  394. ~~~
  395. ### Tunnel SSH inverse
  396. Si l'on est derrière une connexion NAT par exemple, on peut ouvrir un tunnel pour permettre une connexion distante depuis une machine accessible en SSH :
  397. ~~~
  398. $ ssh -R 22000:127.0.0.1:22 ssh.example.com
  399. ~~~
  400. Depuis *ssh.example.com* on peut ainsi accéder à la machine derrière le NAT via `ssh -p22000 127.0.0.1`.
  401. ### Proxy SOCKS via SSH
  402. On peut lancer un proxy SOCKS passant par un serveur distant ainsi :
  403. ~~~
  404. $ ssh -D 6789 ssh.example.com
  405. ~~~
  406. 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.
  407. C'est ainsi pratique avec un navigateur où l'ensemble du trafic vers le web passera ainsi par le serveur distant.
  408. ## Astuces
  409. ### Loguer/exécuter script avant chaque connexions SSH
  410. Grâce au fichier placé dans ~~~/etc/ssh/sshrc~~~, juste avant toutes connexions ssh (rsync, sftp, ssh, ...), le contenu sera exécuté avant la session ssh ouverte.
  411. ### Séquences d'échappement SSH
  412. <https://lonesysadmin.net/2011/11/08/ssh-escape-sequences-aka-kill-dead-ssh-sessions/>
  413. On peut utiliser des combinaisons de touches spéciales via une connexion SSH pour intéragir avec la connexion en cours.
  414. En tapant `Entrée + ~ + ?` on obtient la liste des séquences possibles :
  415. ~~~
  416. Supported escape sequences:
  417. ~. - terminate connection (and any multiplexed sessions)
  418. ~B - send a BREAK to the remote system
  419. ~C - open a command line
  420. ~R - request rekey
  421. ~V/v - decrease/increase verbosity (LogLevel)
  422. ~^Z - suspend ssh
  423. ~# - list forwarded connections
  424. ~& - background ssh (when waiting for connections to terminate)
  425. ~? - this message
  426. ~~ - send the escape character by typing it twice
  427. (Note that escapes are only recognized immediately after newline.)
  428. ~~~
  429. Voici les séquences les plus utiles :
  430. * `Entrée + ~ + .` : forcer à terminer la connexion SSH en cours (utile en cas de perte de connexion…)
  431. * `Entrée + ~ + v` : diminue la verbosité, par exemple quand on s'est connecté avec `ssh -vvv`
  432. Quelques exemples de manipulations possibles (en anglais) : <https://omecha.info/blog/ssh-escape-commands-for-fun-and-profit.html>
  433. ### Connexion SSH par rebond
  434. 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))).
  435. On peut ainsi se connecter avec `-o ProxyCommand` :
  436. ssh -o ProxyCommand="ssh -W cible.example.com:22 bastion.example.com" cible.example.com
  437. Dans les versions récentes d'OpenSSH (notamment sur Debian 9) il existe une méthode plus simple :
  438. ~~~
  439. $ ssh -J bastion.example.com cible.example.com
  440. ~~~
  441. > *Note* : il ne faut pas utiliser l'option `-A` pour rebondir car elle est dangereuse, à moins que vous ne vouliez vraiment faire du [Agent forwarding](HowtoOpenSSH#agent-forwarding)
  442. ### Agent forwarding
  443. Si vous voulez utiliser une [clé SSH](HowtoOpenSSH#cle-SSH) locale depuis un serveur distant, vous pouvez utiliser l'option `-A` qui va rendre votre agent local accessible depuis le serveur distant :
  444. ~~~
  445. $ ssh -A ssh.example.com
  446. $ env | grep ^SSH_A
  447. SSH_AUTH_SOCK=/tmp/ssh-sUSruIwyCa/agent.3265
  448. ~~~
  449. > *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.
  450. On peut également ajouter les clés SSH présentes sur un serveur distant en faisant :
  451. ~~~
  452. $ ssh ssh.example.com -t -A ssh-add
  453. ~~~
  454. ### VPN over SSH
  455. On peut utiliser OpenSSH comme VPN !
  456. Côté serveur, vous devez :
  457. - Ajouter `PermitTunnel yes`
  458. - Autoriser l'IP Forwarding : `sysctl -w net.ipv4.ip_forward=1`
  459. - Si besoin, mettre une règle de NAT, par exemple sous Linux : `iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE`
  460. Pour lancer la connexion VPN, on fera :
  461. ~~~
  462. # ssh -w 42:42 ssh.example.com
  463. ~~~
  464. On a ensuite un périphérique `tun42` utilisable, à configurer des 2 côtés.
  465. - Côté serveur SSH : `ifconfig tun42 172.17.18.2/24`
  466. - Côté client SSH : `ifconfig tun42 172.17.18.1/24`
  467. On peut alors enfin configurer le routage au niveau client, par exemple sous Linux :
  468. ~~~
  469. # ip route add 8.8.8.8/32 via 172.17.18.2 dev tun42`
  470. ~~~
  471. ### UserKnownHostsFile
  472. OpenSSH se sert du fichier `~/.ssh/known_hosts` pour retenir l'empreinte (_fingerprint_) de chaque connexion effectuée.
  473. Cela lui permet de détecter un changement des clés du serveur, notamment une tentative d'usurpation d'un serveur :
  474. ~~~
  475. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  476. @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
  477. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  478. IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
  479. Someone could be eavesdropping on you right now (man-in-the-middle attack)!
  480. It is also possible that a host key has just been changed.
  481. ~~~
  482. On peut accepter automatiquement la clé à la première connexion ainsi :
  483. ~~~
  484. $ ssh -o "StrictHostKeyChecking=accept-new" ssh.example.com
  485. ~~~
  486. Si besoin, on peut supprimer la ligne concernée dans `~/.ssh/known_hosts` via une commande du type :
  487. ~~~
  488. $ ssh-keygen -f "~/.ssh/known_hosts" -R ssh.example.com
  489. $ ssh-keygen -f "~/.ssh/known_hosts" -R [ssh.example.com]:2222
  490. ~~~
  491. On peut également désactiver cette vérification en utilisant un fichier alternatif :
  492. ~~~
  493. $ ssh -o UserKnownHostsFile=/dev/null ssh.example.com
  494. ~~~
  495. On peut également générer à l'avance les fingerpints dans un fichier `~/.ssh/known_hosts2` (utilisé par défaut).
  496. Pour générer les fingerprints, on peut utiliser la commande `ssh-keyscan` :
  497. ~~~
  498. $ ssh-keyscan ssh.example.com
  499. ssh.example.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC2nP2WzQ8hkZDiEq5+QSGFhTB7SYfRa7/IG0gMOIoCDXH8b3sfsBUUEL8ZSFaWgNKskUnpgg/fqAhvnDLOPskr3OGXRfrCR68fCqn5H1zBrHB1kpdjPW9ezUe1xoY3hGp6LITANHWpZie1wBjYAzaBO70hNAo4JMCQvZXDsQdyws2DRSuYtiAoG/ZY0+t2VZh3MJLcofv1wNo43M+aHJR2xWmQSE7cWjMlcw/QOmsWJBv1+Kb/nK2Q7buX/byvY8ySu5ydATnyEinzbutZXc/t/FioOtWMeqh6NlD3aPGIpUTmf8ow+c1QwZWOC3T2GWyTD5KVmAZSm77lWkpYFcd1
  500. ssh.example.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBsUneE642qr/kzKwJcKl9Cgog/kgCqRLZwZs4J7RRt8
  501. ~~~
  502. Puis on crée un fichier contenant :
  503. ~~~
  504. example-ssh,ssh.example.com,192.0.2.42 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC2nP2WzQ8hkZDiEq5+QSGFhTB7SYfRa7/IG0gMOIoCDXH8b3sfsBUUEL8ZSFaWgNKskUnpgg/fqAhvnDLOPskr3OGXRfrCR68fCqn5H1zBrHB1kpdjPW9ezUe1xoY3hGp6LITANHWpZie1wBjYAzaBO70hNAo4JMCQvZXDsQdyws2DRSuYtiAoG/ZY0+t2VZh3MJLcofv1wNo43M+aHJR2xWmQSE7cWjMlcw/QOmsWJBv1+Kb/nK2Q7buX/byvY8ySu5ydATnyEinzbutZXc/t/FioOtWMeqh6NlD3aPGIpUTmf8ow+c1QwZWOC3T2GWyTD5KVmAZSm77lWkpYFcd1
  505. example-ssh,ssh.example.com,192.0.2.42 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBsUneE642qr/kzKwJcKl9Cgog/kgCqRLZwZs4J7RRt8
  506. ~~~
  507. Ce fichier contenant les fingerprints peut aussi être placé dans `/etc/ssh/ssh_known_hosts` ou `/etc/ssh/ssh_known_hosts2` et sera ainsi utilisé par défaut par tous les utilisateurs d'une machine.
  508. Une autre technique pour vérifier un fingerprint est d'avoir des enregistrements DNS SSHFP.
  509. On peut les générer à l'aide de la commande `ssh-keygen` :
  510. ~~~
  511. $ ssh-keygen -r ssh.example.com
  512. ssh.example.com IN SSHFP 1 1 b0db7dbfe0775199662453c9d6eace6f993b9fdc
  513. ssh.example.com IN SSHFP 1 2 13e60f2c4d2848aea91c420b783273afe6c23efd23818ab220f167a53a0be886
  514. ssh.example.com IN SSHFP 2 1 c2ea7d50f05af4cabc8e6add3491a08654127f83
  515. ssh.example.com IN SSHFP 2 2 1222b6f7ad0d3447a31e3cba1af2eaf8aab7316570b63cc3eccdd4d865fee474
  516. ssh.example.com IN SSHFP 3 1 d93dbd0af9c7fd456b3fa4e9094ede031791da84
  517. ssh.example.com IN SSHFP 3 2 3b885c365ae3cebab6dea63b3eb697d2060d9da906e129011841d665a4ccfe4f
  518. ssh.example.com IN SSHFP 4 1 39d521c3d4b6f672149c1cc053014c9ebdfd4727
  519. ssh.example.com IN SSHFP 4 2 0f28d1764793b519c9c74bfb7c6d0dc9b980bdf22c68d1e324d19247d8cbe161
  520. ~~~
  521. On peut ainsi vérifier à la connexion :
  522. ~~~
  523. $ ssh -o "VerifyHostKeyDNS ask" ssh.example.com
  524. The authenticity of host 'ssh.example.com (192.0.2.42)' can't be established.
  525. ED25519 key fingerprint is SHA256:sln94vzrKSsTezPvT6pyO/Glavvl7/Ao8Wcd46BeRb0.
  526. Matching host key fingerprint found in DNS.
  527. Are you sure you want to continue connecting (yes/no)?
  528. ~~~
  529. ### ControlMaster
  530. OpenSSH peut permettre de réutiliser une connexion en cours pour d'autres connexions via l'option `ControlMaster`.
  531. Si l'on veut activer ce comportement, on pourra ajouter dans `~/.ssh/config` :
  532. ~~~
  533. ControlMaster auto
  534. ControlPath ~/.ssh/ssh_control_%h_%p_%r
  535. ~~~
  536. ### SSHFS
  537. [SSHFS](https://github.com/libfuse/sshfs) permet de créer des montages via une connexion SSH :
  538. ~~~
  539. # apt install sshfs
  540. $ sshfs ssh.example.com:/foo/bar /mnt
  541. $ fusermount -u /mnt/ssh
  542. ~~~
  543. ### X Forwarding
  544. SSH peut créer automatiquement un tunnel et gérer la variable $DISPLAY pour afficher en local les applications graphiques distantes.
  545. Côté serveur, il faut la présence du package `xauth` et l'option `X11Forwarding yes` dans la configuration SSH.
  546. On peut alors lancer :
  547. ~~~
  548. $ ssh -X ssh.example.com
  549. $ xlogo
  550. ~~~
  551. ### mosh
  552. <https://mosh.org/>
  553. En cas de connexion réseau avec une latence réseau élevée ou instable (perte de paquets), on peut utiliser **mosh** qui vient se positionner après une connexion SSH en utilisant un port UDP dédiée à une session/utilisateur. Il gère aussi le roaming, c'est-à-dire que l'adresse IP source n'est pas importante pour garder la connexion (bascule ADSL vers LTE par exemple) et que la connexion peut être suspendue plusieurs heures sans problème (appareil en veille, coupure réseau…).
  554. ~~~
  555. # apt install mosh
  556. ~~~
  557. Pour se connecter basiquement (port SSH 22, utilisateur actuel). Il suffit grosso-modo de remplacer la commande ssh par mosh.
  558. ~~~
  559. $ mosh server
  560. ~~~
  561. Un exemple plus avancé.
  562. ~~~
  563. $ mosh --ssh "ssh -p2222 -l user" server
  564. ~~~
  565. Mosh va ouvrir une connexion ssh, puis la quitter pour basculer en UDP sur un port négocié (plage 60001:60999 par défaut).
  566. On peut tout à fait avoir la connexion SSH restreinte par un pare-feu (par exemple il faudra utiliser un VPN pour la connexion SSH), mais avoir la plage de ports UDP publiques.
  567. ## FAQ
  568. ### Obtenir l'empreinte de la clé publique du serveur
  569. ~~~
  570. $ ssh-keygen -lf /etc/ssh/clé.pub
  571. ~~~
  572. ### Regénérer les clés du serveur
  573. #### Sous Debian :
  574. ~~~
  575. # rm -i /etc/ssh/ssh_host_*
  576. # dpkg-reconfigure openssh-server
  577. Creating SSH2 RSA key; this may take some time ...
  578. Creating SSH2 DSA key; this may take some time ...
  579. Restarting OpenBSD Secure Shell server: sshd.
  580. ~~~
  581. #### Sous OpenBSD :
  582. ~~~
  583. # rm -i /etc/ssh/ssh_host_*
  584. # ssh-keygen -A
  585. ssh-keygen: generating new host keys: RSA DSA ECDSA ED25519
  586. ~~~
  587. À noter que c'est fait à chaque boot (via */etc/rc*), si les clés
  588. n'existent pas donc une autre solution est de supprimer les clés et de
  589. rebooter.
  590. ### reload/restart le démon ssh sur Debian sans passer par le script d'init
  591. Pour reload :
  592. ~~~
  593. # start-stop-daemon --stop --signal 1 --quiet --oknodo --pidfile /var/run/sshd.pid --exec /usr/sbin/sshd
  594. ~~~
  595. Pour redémarrer :
  596. ~~~
  597. # start-stop-daemon --stop --quiet --oknodo --retry 30 --pidfile /var/run/sshd.pid
  598. # start-stop-daemon --start --quiet --pidfile /var/run/sshd.pid --exec /usr/sbin/sshd
  599. ~~~
  600. ### Peut-on encore utiliser une clé SSH DSA ?
  601. Les clés SSH avec l'algorithme DSA sont dépréciées depuis Stretch.
  602. ### Limitation du temps de connexion via SSH
  603. On peut limiter le temps d'une connexion SSH inactive en utilisant la variable d'environnement *TMOUT*.
  604. On peut provoquer une déconnexion automatique au bout d'1h d'activité en positionnant :
  605. ~~~{.bash}
  606. export TMOUT=3600
  607. ~~~
  608. À l'inverse, si l'on veut éviter une déconnexion automatique quand cette variable est positionnée, on peut la supprimer ou l'augmenter :
  609. ~~~
  610. $ unset TMOUT
  611. $ export TMOUT=999999
  612. ~~~
  613. ### Comment lister les clés SSH en mémoire d'un agent SSH ?
  614. On peut utiliser la commande `ssh-add -l` :
  615. ~~~
  616. $ ssh-add -l
  617. 256 71:fd:ba:ef:aa:94:27:14:05:d8:b6:db:28:e4:65:c2 /home/jdoe/.ssh/id_ed25519 (ED25519)
  618. 2048 2b:c8:ae:c0:d3:25:93:83:d4:41:4d:21:1e:80:2f:f4 rsa w/o comment (RSA)
  619. ~~~
  620. À noter que l'on peut forcer un agent SSH à oublier les clés SSH à l'aide d'une des deux commandes suivantes :
  621. ~~~
  622. $ ssh-add -D
  623. All identities removed.
  624. $ keychain --clear
  625. * ssh-agent: All identities removed.
  626. * gpg-agent: All identities removed.
  627. ~~~
  628. On peut aussi verrouiller temporairement son agent SSH via :
  629. ~~~
  630. $ ssh-add -x
  631. Enter lock password:
  632. Again:
  633. Agent locked.
  634. $ ssh-add -l
  635. The agent has no identities.
  636. $ ssh-add -X
  637. Enter lock password:
  638. Agent unlocked.
  639. ~~~
  640. ### Ouvrir un tunnel, en passant par un bastion
  641. Voici un exemple pour exposer localement un service VNC sur le port 5901 qui est accessible uniquement localement sur le port 5906 d'un serveur VNC, qui lui même n'est accessible que par un bastion :
  642. ~~~
  643. ssh -J bastion.example.com -L 5906:127.0.0.1:5901 vnc-server.example.com
  644. ~~~
  645. ### Comment protéger un serveur SSH des attaques ?
  646. Voici plusieurs méthodes pour protéger son serveur SSH (qui peuvent se cumuler)
  647. - ne pas ouvrir son port SSH à l'extérieur à l'exception de certaines adresses IP
  648. - modifier le port d'écoute de son serveur SSH pour diminuer un peu les attaques automatiques (`Port 2200` dans *sshd_config*)
  649. - utiliser du Port Knocking pour camoufler son port SSH
  650. - ne pas autoriser les connexions SSH avec un mot de passe (`PasswordAuthentication no` dans *sshd_config*)
  651. - configurer [Fail2Ban](HowtoFail2Ban) pour bannir les adresses IP qui se trompent de mot de passe
  652. ### Que ce passe t'il quand sshd_config contient à la fois AllowUsers et AllowGroups ?
  653. C'est authorisé par sshd donc `sshd -t` ne sortira pas d'erreur ! Au niveau de la connexion, la page man de sshd_config(5) dit:
  654. > The allow/deny directives are processed in the following order: DenyUsers, AllowUsers, DenyGroups, and finally AllowGroups.
  655. Cela signifie en réalité que lors d'une tentative de connexion SSH, la logique suivante est suivi:
  656. > Dans le cas où l'une de ces options n'est pas défini, on saute la ligne correspondante.
  657. - si l'utilisateur tentant de ce connecté **est listé** dans `DenyUsers` alors il ne peut pas se connecter, sinon continuer,
  658. - si l'utilisateur tentant de ce connecté **n'est pas listé** dans `AllowUsers` alors il ne peut pas se connecter, sinon continuer,
  659. - si l'utilisateur **appartient à un groupe listé** dans `DenyGroups` alors il ne peut pas se connecter, sinon continuer,
  660. - si l'utilisateur **n'appartient pas à un groupe listé** dans `AllowGroups` alors il ne peut pas se connecter, sinon continuer,
  661. - l'utilisateur peut se connecté.
  662. Donc pour résumé : Si `AllowUsers` et `AllowGroups` sont définis dans sshd_config alors il faut que l'utilisateur soit **à la fois** dans `AllowUsers` **et** `AllowGroups` pour pouvoir se connecter par SSH.