User Tools

Site Tools


informatique:logiciels:ssh

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
informatique:logiciels:ssh [2020/03/30 09:59] – [Connexion SSH par rebond] pteuinformatique:logiciels:ssh [2023/09/08 09:51] (current) – [Connexion forcée par mot de passe] pteu
Line 62: Line 62:
 Dans le cas précédent, la commande ''ls'' sera lancée, puis la connexion se terminera. Dans le cas précédent, la commande ''ls'' sera lancée, puis la connexion se terminera.
  
 +=====Afficher la liste des paramètres=====
 +
 +Ceci permet d'afficher en vrac la liste des paramètres du serveur SSHd. Il faut utiliser ''-T'' (test) avec l'option ''-C user=<un_user>'', qui permet de spécifier un utilisateur pour le contexte de test (sinon on obtient l'erreur : //'Match User' in configuration but 'user' not in connection test specification//.)
 +<code bash>
 +sshd -T -C user=guest
 +</code>
 ====== Utilisation du client ====== ====== Utilisation du client ======
  
Line 93: Line 99:
  
  
 +=====Gérer des clés=====
 +
 +Pour générer une paire de clés sécurisées utiliser les valeurs par défaut :
 +<code bash>
 +$ ssh-keygen
 +</code>
 +Actuellement (en 2021) il est raisonnable d'utiliser au moins du chiffrement RSA 4096 bits (''-t rsa -b 4096''), et dans l'idéal du ED25519 (''-t ed25519'') qui utilise une variante de chiffrement par courbes elliptiques.
 +
 +Pour formater une clé publique au format RFC 4716 :
 +<code bash>
 +$ ssh-keygen -ef ~/.ssh/id_rsa -mRFC4716
 +---- BEGIN SSH2 PUBLIC KEY ----
 +Comment: "4096-bit RSA, converted by dude@technodrome from OpenSSH"
 +AAAAB3NzaC1yc2EAAAADAQABAAABAQCzU4exWqu4tsgWIJleq1AJ98cGHswD80cphWYOas
 +spBoOPgdv
 +[blabla sur quelques lignes]
 +15ukAsdfsdgg3h5f4h6dfh3fj84tK1
 +---- END SSH2 PUBLIC KEY ----
 +</code>
 +
 +Alternatives : convertir au format PEM ''-mPEM'' ou PKCS8 ''-mPKCS8''.
  
 ===== Se connecter sans mdp ===== ===== Se connecter sans mdp =====
Line 157: Line 184:
 </code> </code>
 On lance ''ssh-agent'', qui est un processus qui va saisir la passphrase à notre place ; puis on lui spécifie notre clé privée (//id_rsa//) et on saisit (une fois pour la session) notre passphrase. Tant que la session sera ouverte, ssh-agent sera en mémoire et dispensera de saisir la passphrase. On lance ''ssh-agent'', qui est un processus qui va saisir la passphrase à notre place ; puis on lui spécifie notre clé privée (//id_rsa//) et on saisit (une fois pour la session) notre passphrase. Tant que la session sera ouverte, ssh-agent sera en mémoire et dispensera de saisir la passphrase.
 +
 +====ssh-add====
 +
 +Cet outil sert à ajouter ou supprimer des identités (clés) au ssh-agent :
 +  * pour lister toutes les identités déjà chargées : ''ssh-add -l'' (fingerprints) ou ''ssh-add -L'' (clé publique).
 +  * pour ajouter une nouvelle identité : ssh-add ~/.ssh/id_rsa-perso ; si lancé sans argument, il ajoutera ce qu'il trouve parmi les fichiers existants : ''~/.ssh/id_rsa'', ''~/.ssh/id_dsa'' et ''~/.ssh/identity''.
 +  * pour supprimer une identité : ''ssh-add -d ~/.ssh/id_rsa-perso''. Pour supprimer toutes les identités : ''ssh-add -D''.
 +
 +Par défaut le client SSH va présenter toutes les identités qu'il trouvera ; pour désactiver ce comportement (et éviter tous les //failed login// qui en découlent) :
 +<code bash ~/.ssh/config>
 +IdentitiesOnly yes
 +</code>
 +Attention il faudra soit utiliser ''ssh-agent'', soit préciser l'identité en CLI avec l'option ''-i <id_file.key>'' : ''ssh -i ~/.ssh/id_rsa_example serveur''
  
   * pour plus de sécurité on peut restreindre l'utilisation des clés à une machine ou un sous-domaine en rajoutant ''from="<host>"'' en début de ligne correspondante dans le fichier //authorized_keys// :   * pour plus de sécurité on peut restreindre l'utilisation des clés à une machine ou un sous-domaine en rajoutant ''from="<host>"'' en début de ligne correspondante dans le fichier //authorized_keys// :
Line 241: Line 281:
  
 Sur le serveur SSH, dans le fichier ''/etc/ssh/sshd_config'', vérifier la présence de la directive Sur le serveur SSH, dans le fichier ''/etc/ssh/sshd_config'', vérifier la présence de la directive
-  X11Forwarding yes+<code bash> 
 +X11Forwarding yes 
 +</code>
  
 Sur le client, qui doit être muni d'un serveur X : Sur le client, qui doit être muni d'un serveur X :
-  ssh -X [-C] serveur+<code bash> 
 +ssh -X [-C] serveur 
 +</code>
 -X permet l'export display et -C (facultatif) permet d'activer la compression des données (permet un gain de bande passante au détriment de la consommation CPU). -X permet l'export display et -C (facultatif) permet d'activer la compression des données (permet un gain de bande passante au détriment de la consommation CPU).
  
Line 251: Line 295:
 Pour les postes clients sous Windows, on peut passer par l'installation de Cygwin avec un serveur X ([[http://cygwin.com/ Cygwin]] ou [[http://x.cygwin.com/ Cygwin/X]]). Pour les postes clients sous Windows, on peut passer par l'installation de Cygwin avec un serveur X ([[http://cygwin.com/ Cygwin]] ou [[http://x.cygwin.com/ Cygwin/X]]).
 Dans le cas de Cygwin/X : on le lance, on lance le serveur X Dans le cas de Cygwin/X : on le lance, on lance le serveur X
-  startxwin.sh+<code bash> 
 +startxwin.sh 
 +</code>
  
 Cela lance un xterm (et une icone dans la taskbar). Ensuite on procède comme normalement : Cela lance un xterm (et une icone dans la taskbar). Ensuite on procède comme normalement :
-  ssh -X serveur+<code bash> 
 +ssh -X serveur 
 +</code>
  
-(il parait que ça marche aussi avec putty, en activant le //X11 Forwarding//, mais ça ne marche pas chez moi : normal il n'y a pas de serveur X lancé sans Cygwin !..)+====Après un su/sudo====
  
 +Le X11 ne passe pas les ''su'' et ''sudo'' ; pour créer la continuité de l'affichage, il faut :
 +<code bash>
 +# afficher le DISPLAY avant le sudo
 +echo $DISPLAY
 + localhost:10.0
  
 +# afficher les xauth et copier la ligne qui correspond à notre DISPLAY (ici le ":10")
 +xauth list
 +[..]
 +serveur/unix:10  MIT-MAGIC-COOKIE-1  58ff4f8de36bdddb68ad47bc0e29ac4d
 +
 +# ajouter l'xauth dans la session du su/sudo
 +sudo -i
 +xauth add serveur/unix:10  MIT-MAGIC-COOKIE-1  58ff4f8de36bdddb68ad47bc0e29ac4d
 +
 +xclock&
 +</code>
 +=====Exécuter un script local sur le serveur distant=====
 +
 +Pour cela, on lance la commande bash distante, en précisant le paramètre ''-s'' qui lui demande de lire l'entrée standard. Et on envoie le script sur l'entrée standard comme n'importe quelle commande, avec ''<''.
 +<code bash>
 +ssh user@remoteserver 'bash -s' < script.sh
 +</code>
 +
 +Si le script n'est pas dans un fichier, on peut envoyer les commandes sur plusieurs lignes en usant d'un [[informatique:linux:programmation_shell#heredoc|Heredoc]] :
 +<code bash>
 +ssh user@remoteserver 'bash -s' << EOF
 +hostname
 +pwd
 +EOF
 +</code>
  
 ====== Tips ====== ====== Tips ======
Line 316: Line 394:
 Lorsqu'une connexion telnet est bloquée, on peut taper une séquence d'échappement qui permet de sortir de telnet et récupérer la main sur son terminal : ''Ctrl °'' (le ''°'' se saisit avec ''AltGr'' + '')'' ) (souvent suivi de ''quit''). Lorsqu'une connexion telnet est bloquée, on peut taper une séquence d'échappement qui permet de sortir de telnet et récupérer la main sur son terminal : ''Ctrl °'' (le ''°'' se saisit avec ''AltGr'' + '')'' ) (souvent suivi de ''quit'').
  
-La même avec le client SSH est : ''<enter>'' ''~'' ''.'' ; elle permet de quitter le client SSH et rendre la main avec le terminal.+La même avec le client SSH est : ''~.'' (''<Enter>~ + .''; elle permet de fermer la connexion et de rendre la main sur le terminal.
  
 =====Saisir un mot de passe via SSH===== =====Saisir un mot de passe via SSH=====
Line 358: Line 436:
 </code> </code>
  
 +
 +=====Connexion SSH via webproxy=====
 +
 +Pour se connecter en SSH à travers un proxy web, disons "proxy.corp" port "80" pour l'exemple, il faut ajouter l'option **ProxyCommand** à la commande de connexion : ''ssh -o "ProxyCommand=nc -X connect -x proxy.corp:80 %h %p" ssh-user@ssh-server''. Pour ne pas se fatiguer à le préciser à chaque fois, on peut l'ajouter à son ssh config :
 +<code bash ~/.ssh/config>
 +Host ssh-server
 +   ProxyCommand /bin/nc -X connect -x proxy.corp:80 %h %p
 +</code>
 +
 +Ainsi on se connectera simplement avec : ''ssh ssh-user@ssh-server''
 +
 +Depuis Windows il est plus facile d'utiliser le petit [[informatique:logiciels:putty|Putty]], en renseignant le menu Connection/Proxy (remplir le Proxy hostname et Port), il fera le taf tout seul.
  
 =====Connexion SSH par rebond===== =====Connexion SSH par rebond=====
Line 366: Line 456:
 </code> </code>
  
-Il faut éditer, sur le poste client, le fichier de config perso (''~/.ssh/config'') :+Il suffit de saisir l'option ''-J''
 +<code bash> 
 +ssh -J bastion cible 
 +</code> 
 + 
 +Sur de plus ancienne version de SSH on doit remplacer le -J par : 
 +<code bash> 
 +ssh -o ProxyCommand="ssh -W %h:%p bastion" cible 
 +</code> 
 + 
 +Et sur les plus anciennes versions de SSH on peut utiliser le trick (''-tt'' force l'allocation d'un terminal) : 
 +<code bash> 
 +ssh -tt bastion "ssh -tt cible" 
 +</code> 
 + 
 +Pour automatiser cela il faut éditer, sur le poste client, le fichier de config perso (''~/.ssh/config'') :
 <code bash ~/.ssh/config> <code bash ~/.ssh/config>
-Host serveur_cible +Host cible 
-   ProxyCommand ssh serveur_bastion -W %h:22 +   Hostname cible.domain.com 
-   User mon_login_sur_serveur +# nouvelle méthode 
-   #alternative : ProxyCommand ssh serveur_bastion nc %h 22+   ProxyJump bastion 
 +# ou:   ProxyCommand ssh bastion -W %h:%p 
 +   User login_sur_bastion 
 +   #alternative : ProxyCommand ssh bastion nc %h 22
    # on peut préciser le certificat à utiliser pour éviter le double prompt    # on peut préciser le certificat à utiliser pour éviter le double prompt
    #IdentityFile ~/.ssh/id_rsa.pub    # préciser la clé à utiliser, si pas celle par défaut    #IdentityFile ~/.ssh/id_rsa.pub    # préciser la clé à utiliser, si pas celle par défaut
    ForwardAgent yes                   # utiliser les credentials locaux sur les systèmes distants    ForwardAgent yes                   # utiliser les credentials locaux sur les systèmes distants
 </code> </code>
 +
 Pour éviter de saisir plusieurs fois son mot de passe, penser à copier sa clé dans les ''authorized_keys'' du serveur bastion avec la commande : Pour éviter de saisir plusieurs fois son mot de passe, penser à copier sa clé dans les ''authorized_keys'' du serveur bastion avec la commande :
 <code bash> <code bash>
Line 381: Line 490:
 client $ ssh-keygen client $ ssh-keygen
 [blabla OK OK] [blabla OK OK]
-# copier la clé sur le serveur +# copier la clé sur le bastion 
-client $ ssh-copy-id user@serveur_bastion+client $ ssh-copy-id user@bastion
 </code> </code>
  
 On peut enchainer plusieurs serveurs en enfilade pour se connecter sur le serveur cible : On peut enchainer plusieurs serveurs en enfilade pour se connecter sur le serveur cible :
 <code bash ~/.ssh/config> <code bash ~/.ssh/config>
-Host serveur_bastion2 +Host cible 
-   ProxyCommand ssh serveur_bastion -W %h:22 +# on sépare les serveurs intermédiaires par une virgule 
-Host serveur_cible +   ProxyJump bastion,bastion2 
-   ProxyCommand ssh serveur_bastion2 -W %h:22+
 +# ou avec l'option -W : 
 +   ProxyCommand ssh bastion2 -W %h:%p 
 +Host bastion2 
 +   ProxyCommand ssh bastion -W %h:%p
 </code> </code>
 +
 +=====Connexion SSH par rebonds via webproxy=====
 +
 +On mixe les astuces : on veut se connecter à CIBLE via un premier webproxy, puis un bastion SSH :
 +<code>
 +CLIENT ----- WEBPROXY(SOCKS 5) ----- BASTION ----- CIBLE
 +</code>
 +
 +<code bash>
 +# on défini le mode de connexino à BASTION (via WEBPROXY sur le port 3128)
 +Host BASTION
 +        Hostname BASTION.FQDN
 +        ProxyCommand /bin/nc -X connect -x WEBPROXY:3128 %h %p
 +# on défini le mode de connexion à CIBLE (via BASTION en passant la commande ProxyCommand)
 +Host CIBLE
 +        Hostname CIBLE.FQDN
 +        ProxyCommand ssh BASTION -W %h:%p
 +        ProxyJump BASTION
 +</code>
 +
 +Depuis Windows, je n'ai pas trouvé de solution avec Putty qui ne gère pas ''ProxyJump''. Il faut passer par le client OpenSSH intégré depuis Windows 10, ou via WSL (idem pour avoir le client OpenSSH), et utiliser la conf sus-citée.
 +
 +=====Unable to negotiate...=====
 +
 +Certains clients récents ne sont plus compatibles avec les paramètres négociés avec les serveurs trop vieux (ou inversement...). En effet les anciennes versions sont vulnérables à différentes failles de sécurité. C'est donc une bonne chose de désactiver par défaut la possibilité d'établir une connexion SSH si elle n'est pas sûre.
 +
 +Cependant avec certains vieux équipements, c'est soit vieux SSH soit telnet. Dans mon cas :
 +<code bash>
 +ssh admin@upgrayedd
 +Unable to negotiate with 10.0.2.240 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1
 +</code>
 +
 +Il faut donc forcer le client SSH a accepter ces protocoles:
 +<code bash>
 +ssh -o KexAlgorithms=+diffie-hellman-group1-sha1 upgrayedd
 +</code>
 +
 +Ou, plus pérenne, dans le fichier de préférences du client SSH :
 +<code bash ~/.ssh/config>
 +Host upgrayedd
 +  KexAlgorithms +diffie-hellman-group1-sha1
 +</code>
 +
 +Dans mon cas j'avais également ce paramètre qui bloquait :
 +<code bash>
 +ssh admin@upgrayedd
 +Unable to negotiate with 10.0.2.240 port 22: no matching host key type found. Their offer: ssh-dss
 +</code>
 +
 +<code bash ~/.ssh/config>
 +Host upgrayedd
 +  KexAlgorithms +diffie-hellman-group1-sha1
 +  HostKeyAlgorithms +ssh-dss
 +</code>
 +Il existe une page qui décrit les méthodes pour contourner les problèmes de compatibilité SSH : [[http://www.openssh.com/legacy.html|SSH legacy options]]
 +
 +src: https://unix.stackexchange.com/questions/340844/how-to-enable-diffie-hellman-group1-sha1-key-exchange-on-debian-8-0/340853
 +
 +
 +=====key_verify failed=====
 +
 +Les vieilles croûtes - les vieilles machines - qui utilisent des vieilles implémentations de SSH peuvent bloquer votre client SSH :
 +<code bash>
 +ssh_rsa_verify: RSA modulus too small: 512 < minimum 768 bits
 +key_verify failed for server_host_key
 +</code>
 +
 +Pour bypasser ce prérequis de sécurité (ce n'est pas conseillé mais on n'a pas toujours le choix), il faut préciser l'option ''-1'' au client SSH pour qu'il accepte de se connecter :
 +<code bash>
 +ssh -1 vieille-croute
 +</code>
 +
 +=====Connexion en arrière-plan=====
 +
 +Dans certains cas il peut être utile de lancer la connexion SSH en background, ce qui permet au terminal de rendre la main tout en conservant la connexion active. Cela se fait avec l'option ''-f'' :
 +<code bash>
 +ssh -f host xterm
 +</code>
 +
 +Pour faire une redirection de port, il faut ajouter ''-N'' pour préciser que l'on n'exécute aucune commande distante :
 +<code bash>
 +# sans -N
 +ssh -f -L 5901:127.0.0.1:5901 <host>
 + Cannot fork into background without a command to execute.
 +
 +ssh -f -N -L 5901:127.0.0.1:5901 <server>
 +</code>
 +
 +Et si l'on veut fermer la connexion après utilisation ? On ne peut pas, fallait réfléchir avant.
 +
 +Bon, en fait, il suffit de killer le process SSH qui écoute sur le port redirigé localement, sur le client :
 +<code bash>
 +kill -9 $(ss -lnpt | awk ' $4 ~ /:5901$/ {sub(/.*pid=/,"",$6); sub(/,.*$/,"",$6); print $6}')''
 +</code>
 +
 +Mais openssh permet de faire les choses proprement, de (au moins) 2 manières :
 +  - ne pas utiliser ''-N'', et lancer la commande ''sleep 60''. Cela a pour effet de maintenir le tunnel ouvert 60 secondes, et si aucune connexion ne l'utilise au bout de cette durée, de fermer le tunnel. En revanche, si une appli utilise le tunnel (par exemple un ''vncviewer127.0.0.1:5901:1''), alors le client SSH attend la fermeture de cette dernière (= la libération du tunnel) puis ferme le tunnel.
 +  - utiliser une connexion SSH en mode "master", qui permet d'utiliser un socket (fichier) de contrôle pour lui envoyer une commande de fermeture de connexion (exit) :
 +<code bash>
 +ssh -f -N -M -S <path-to-socket> -L 5901:127.0.0.1:5901 <server>
 +# (utilisation de la connexion...) puis fermeture :
 +ssh -S <path-to-socket> -O exit <server>
 +</code>
 +
 +source: [[https://unix.stackexchange.com/questions/83806/how-to-kill-ssh-session-that-was-started-with-the-f-option-run-in-background|How to kill SSH session that was started with the -f option (run in background) ?]] sur StackExchange
 +
 +
 +=====Connexion forcée par mot de passe=====
 +
 +Pour forcer l'authentification par mot de passe (afin d'éviter un "failed login" avec une mauvaise clé publique par exemple), lancer le client SSH avec l'option ''PreferredAuthentications=password'', afin de privilégier l'authentification par mot de passe (par défaut l'ordre de préférence est "gssapi-with-mic, hostbased, publickey, keyboard-interactive, password") ; il faut vérifier que cette option ne soit pas désactivée sur le serveur.
 +
 +On peut l'agrémenter de ''PubkeyAuthentication=no'' afin de désactiver l'auth par clé publique (idem pour les autres modes d'authentification).
 +
 +<code bash>
 +ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no <SERVER>
 +</code>
 +
 +Ces options peuvent se positionner dans le fichier de conf : **~/.ssh/config** pour ne pas avoir à les saisir à chaque fois.
 ====== Liens ====== ====== Liens ======
  
 [[http://people.via.ecp.fr/~alexis/formation-linux/export-display.html|formation Linux]] [[http://people.via.ecp.fr/~alexis/formation-linux/export-display.html|formation Linux]]
informatique/logiciels/ssh.1585562349.txt.gz · Last modified: 2020/03/30 09:59 by pteu