SSH

De Avided.info
Aller à : navigation, rechercher


Information : Dans ce document, des mots générique ont été utilisés

  • user : est à modifier par votre nom d'utilisateur
  • machine, serveur, serveur1, serveur2 : sont à modifier par le nom ou l'adresse IP de la machine distante.


Connexion sur une machine distante

Le plus simple et le plus courrant

ssh user@machine

Meme chose

ssh -l user machine

Un mot de passe vous est demandé est vous êtes connecté.

Pour chaque machine distante a la 1er connexion. Une question vous demandant d'accepter la "clef permettant de créer la connexion ". Accepter en tapant "yes" puis valide. La clef sera stocker sur votre machine local dans le fichier suivant ~/.ssh/known_hosts.

Il est possible que pour des raisons de modification vous ayant besoin de supprimer la ligne correspondante a la machine distante de votre fichier.

Pour copier un fichier sur une machine distante sshd Permet de transférer des fichier a la mode ftp. Il faut pour cela que sshd soit lancer avec une option qui démarre un autre démon.

sftp utilD@machine_distante
mots de pass

Par contre avec cet commande, c'est bien le demon sshd qui sera utiliser. De plus il ressemble plus a une commande bien connue et local "cp" Syntaxe :

scp source destination.

Exemple :

scp /rep/fichier_local user@serveur:/repertoire/distant/

pour un répertoire utilisez l'option -r

scp -r /chemin/rep/local user@serveur:/repertoire/distant

Il est possible d'inverser si l'on veut que la source soit distante et la cible local. Ou indiquer une source et une destination distante

scp -r user@serveur1:/repertoire
user@serveur2:/repertoire

Connexion non interactive

Tous ça c'est bien, mais y'en a marre de taper les mot de passe, de changer de nom d'utilisateur en fonction du serveur, et comment faire pour effectuer des script en utilisant c'est commandes qui ce connecte au demon sshd. Voyons les mecanisme nous permettant d'effectuer ces taches.

Si vous êtes sur de votre réseau (soyez modeste), vous pouvez utiliser cette méthode, si cela passe par Internet, cette méthode est dangereuse. Si vous n'avez pas le choix créer un compte qui sera utilisé uniquement à cette effet et ne faisant partie d'aucun groupe pouvant compromettre votre sécurité.

Ceci étant dit voila les différentes étapes à effectuer

Sur votre poste local "A" depuis votre compte:

cd
cd .ssh
ssh-keygen -t rsa -b 2048 -f id_rsa
chmod 600 id_rsa*
cat id_rsa.pub >> authorized_keys
chmod 400 authorized_keys

transférer le fichier "authorized_keys" dans le répertoire .ssh du compte utilisateur "utilD" de la machine distante "B"

cd .ssh
scp authorized_keys user@machine:~/.ssh/

Attention: des droits trop permissif sur certain répertoire et fichier empêche le fonctionnement de cette méthode. Sur la destinations les droits ne doivent pas exeder ceux-ci :

chmod 700 ~/
chmod 750 ~/.ssh
chmod 400 authorized_keys

maintenant si vous reconnectez il n'y a plus de mot de passe a donner

ssh user@machine

executer une commande sur une machine distante

Il est donc possible d'écrire des fichiers contenant les commandes à exécuter sur la machine distante avec les client scp et sftp ou simplement lancer une commande sur une machine distante.

ssh user@host commande


Copier un fichier d'une machine distante sur une autre machine distante

une solution simple qui devrais, mais qui ne fonctionne pas chez moi:

scp user@server1:/chemin/fichier user@server2:/chemin/dest

une astuce qui cet fois fonctionne

ssh root@serveur1 "cat /etc/sudoers" | ssh root@serveur2 "cat > /etc/sudoers "

Forwarding : passer au travers d'un rebond

ssh -L 2002: @ip_station_destination:22 @ip_bastion -N $
ssh user@localhost -p 2002

Quelques paramètres de configuration du serveur

Permet a root de ce connecter via ssh Si a no seul une connexion avec un autre user pourra se connecter, puis un su - devra etre utilisé afin de de venir root

PermitRootLogin yes

seul les utilisateur definit sur cette ligne pourrons ce connecter depuis les machine indiqué. un asterik peut etre utiliser pour dir tous les utilisateur ou toutes les machine

AllowUsers root@10.162.203.74 *@10.162.202.138 user1@*

le fichier ~/.ssh/config

Ce fichier permet de facilité la connexion aux machines auxquelle vous êtes habituer Grace a ce fichier, la commande "ssh nom2machine" suffira a vous connecter Toutes les options que vous devez mettre habituellement serons indique dans le fichier config

ex: Dans l'exemple suivant quand j'execute ssh amazone

la commande réel est :

ssh -X -p 322 -i /home/user/key/amazone/OSaccess.pem username@ec2-xxx-xxx-xx-xxx.eu-west-1.compute.amazonaws.com
Host amazone
        Hostname ec2-xxx-xxx-xx-xxx.eu-west-1.compute.amazonaws.com
        user username
        Port 322
        IdentityFile /home/user/key/amazone/OSaccess.pem
        Compression yes
        StrictHostKeyChecking no
        ForwardX11 yes
Host *%*
ProxyCommand ssh $(echo %h | cut -d%% -f1) nc -w1 $(echo %h | cut -d%% -f2) %p
Host host1%host2
ProxyCommand ssh host1 nc -w1 host2 %p

Connexion au travers un proxy http

Pour des question de securité, beaucoup d'endroit son cloisonner a des proxy qui ne gere que du http, https et ftp. De notre coté nous avons besoin de ce connecter a des machines disponible sur Internet mais en ssh. Une technique permettant ce type de connection est de passer nos connection ssh au travers le port 443 du proxy en lui faisant croire que ce qui passe et de l'https. Pour cela il faut un outils appelé corkscrew installer sur notre machine. Modifier le port de chaque connexion par le port 443. ajouter la ligne suivante a chaque host dans votre fichier ~/.ssh/config

ProxyCommand /usr/bin/corkscrew adresse.du.proxy.qvb 8080 %h %p ~/.ssh/authproxy

Creer le fichier ~/.ssh/authproxy avec les droit 600, il doit contenir votre utilisateur et mot de passe sous le format suivant :

nomutilisateurproxy:motdepasse

Vos serveur ssh n'ecoute pas sur le port 443 Pour utiliser cet méthode il est necessaire que vos appel se fasse sur le port 443 (https), puisque Si il n'est pas possible de faire ecouter sshd sur vos ou votre machine sur le port 443. Virtualhost avec un reverseproxy apache, mais pas encore testé