Vous n'êtes pas identifié(e).
L'icône rouge permet de télécharger chaque page du wiki visitée au format PDF et la grise au format ODT →
Ceci est une ancienne révision du document !
Lorsque vous démarrez un ordinateur, à moins que vous n'ayez configuré de connexion automatique, il vous est demandé un nom d'utilisateur et un mot de passe.
C'est le processus de login qui vous permet de vous authentifier en tant qu'utilisateur de la machine.
À l'issue de cette authentification, vous avez accès à une interface vous permettant de lancer des commandes, souvent une interface graphique comme shell.
Le principe ici va être le même :
via un canal sécurisé2) vous allez fournir
mais cette fois, depuis votre PC à une machine distante.
Comme d'habitude, ça tient en une ligne :
apt-get install openssh-client
Pour pouvoir accéder à une machine via la couche IP (qu'utilise SSH), il nous faut :
Par exemple, pour se connecter au serveur Debian, vous pouvez lui envoyer des ping via son IP ainsi :
ping -c 5 128.31.0.51
ou via son nom d'hôte :
ping -c 5 debian.org
Par exemple, pour vous connecter sous le nom d'utilisateur3) jojo sur la machine d'IP coincoin4), vous faites simplement :
ssh jojo@coincoin
Si le serveur ssh distant n'écoute pas sur le port 22, vous pouvez spécifier le port à l'aide de l'option -p
:
ssh -p 1234 jojo@coincoin
Il est aussi possible de lancer sur le serveur distant une application graphique qui s'affichera sur votre ordinateur client.
Pour vous connecter sous le nom d'utilisateur jojo sur la machine d'IP coincoin et obtenir l'export X,
ssh -X jojo@coincoin
Le nom d'utilisateur est spécifié dans la commande de connexion. Le serveur nous demande alors notre mot de passe pour nous connecter, de la même façon que sur une machine locale
ssh jojo@coincoin
Ce à quoi le serveur vous répond :
jojo@coincoin's password:
Les mots de passes sont souvent peu complexes. On peut alors utiliser une paire de clé publique/privée plus complexe et plus sûre.
Le principe est le suivant, on génère une paire de clé. La clé privé reste sur votre poste client. La clé publique doit être transférée sur le serveur manuellement ou par le réseau. C'est cette clé qui servira alors à l'authentification.
ssh-keygen -t dsa
Generating public/private dsa key pair. Enter file in which to save the key (/home/user/.ssh/id_dsa): /home/user/.ssh/nom_fichier Enter passphrase (empty for no passphrase): (mettre une passphrase qui sera demandée à chaque connexion - ou rien si c'est pas nécessaire pour vous)
Vous validez 2 fois et vous obtiendrez le résultat en détail de la création de votre clé dsa.
Votre clé sera générée en 1024 bits dans votre dossier /home/votre_user/.ssh/ pour la mettre en place il vous suffit de l'exporter sur votre pc distant.
ssh-copy-id -i /home/user/.ssh/id_dsa.pub user@192.168.x.x
ssh-copy-id -i /home/user/.ssh/id_dsa.pub\ "-p 1234 user@192.168.x.x"
Ne pas oublier les guillemets, sans lesquels la commande ne fonctionnerait pas !
À présent, c'est la passphrase qui sera demandée.
Pour copier le contenu du fichier ~/.ssh/id_dsa.pub (créé côté client), sur le serveur par un autre moyen que la commande ssh-copy-id,
il faudra créer soi-même le fichier de type répertoire ~/ssh et vérifier qu'il ait les droits 700 (lecture + écriture + exécution pour l'utilisateur).
cp /chemin/de/la/clé ~/.ssh/authorized_keys
) cat /chemin/de/id_rsa.pub » ~/.ssh/authorized_keys
On peut par exemple copier sur une clé usb le fichier ~/.ssh/id_dsa.pub
contenant la clé publique du client, puis copier le contenu de ce fichier dans le fichier ~/.ssh/authorized_keys
sur le serveur. Pour ce faire :
- sur l'ordinateur client :
mount /mnt/usb /dev/sdxx
cp ~/.ssh/id_dsa.pub /mnt/usb/
umount /mnt/usb
-sur le serveur :
mount /mnt/usb /dev/sdxx
puis :
mkdir ~/.ssh
-puis copie de ssh/id_dsa.pub et création du fichier ~/.ssh/authorized_keys
mv /mnt/usb/ssh/id_dsa.pub ~/.ssh/authorized_keys
umount /mnt/usb
Pour vérification :
ls -la ~/.ssh/
retour :
drwxr-xr-x 2 user user 4096 mai 15 11:05 . drwxr-xr-x 29 user user 4096 mai 15 11:09 .. -rw-r--r-- 1 user user 402 mai 15 10:58 authorized_keys
chmod 400 ~/.ssh/authorized_keys
Retour :
drwxr-xr-x 2 user user 4096 mai 15 11:05 . drwxr-xr-x 29 user user 4096 mai 15 11:09 .. -r-------- 1 user user 402 mai 15 10:58 authorized_keys
ssh <-p port-choisi> user@192.168.XXXX
A présent, lors de votre connexion, seule votre éventuelle passphrase indiquée lors de la génération de la clé vous sera demandée, mais plus votre mot de passe.
Afin d'éviter de retaper votre passphrase à chaque connexion, vous pouvez utiliser ssh-agent. Il doit être invoqué au début de votre session de la façon suivante avec un shell bourne (comme bash)
eval `ssh-agent -s`
et comme cela avec un shell C
eval `ssh-agent -c`
Il suffit ensuite d'indiquer la clé à utiliser grâce à la commande ssh-add
ssh-add $cle_privee
Pour lister les clés ajoutées
ssh-add -l
Pour supprimer toutes les clés enregistrée
ssh-add -D
Installation
apt-get install keychain
configuration
Il faut appeler le script. Dans votre fichier ~/.bashrc ou ~/.bash_profile ajoutez (en remplaçant $cle_privee par le nom de votre clé)
########################################################################### # allow $USER to use keys. Only enter once and it will remain enabled till # you delete it or reboot the server ########################################################################### /usr/bin/keychain $HOME/.ssh/$cle_privee source $HOME/.keychain/$HOSTNAME-sh
##################################################################################### ### The --clear option make sure Intruder cannot use your existing SSH-Agents keys ### i.e. Only allow cron jobs to use password less login ##################################################################################### /usr/bin/keychain --clear $HOME/.ssh/id_rsa source $HOME/.keychain/$HOSTNAME-sh
Source : http://www.cyberciti.biz/faq/ubuntu-debian-linux-server-install-keychain-apt-get-command
Pour voir les fichiers avec konqueror et Nautilus rien de plus simple
fish://user@192.168.x.x
ssh://user@192.168.x.x:22
Il se peut que vous vouliez établir une connexion distante pour transiter des données de manière 100% transparente et sécurisée, nous allons donc établir un tunnel ssh.
ssh -L 5901:localhost:5900 user@80.80.80.80
Cette technique est très utile pour relier en local un bon nombre d'utilisation, comme sur kde distant, un serveur smtp personnel, une boite mail ( pop ou imap ) personnelle, un bon nombre d'utilisations ont recours à cette technique.
Détail sur la ligne de commande SSH :
Par défaut, SSH n'a pas besoin de configuration. Cependant, pour se simplifier la vie ou pour les cas particuliers, il est possible de préciser préalablement quelques informations sur les connexions que l'on effectue régulièrement.
Cela se fait au moyen de l'édition du fichier de configuration ~/.ssh/config
5) :
nano ~/.ssh/config
Si vous vous connectez régulièrement sur l'ordinateur de votre maman, d'IP ordi.de.ma.maman
sous le nom d'utilisateur gaston
, et sachant que son serveur ssh est configuré pour écouter sur le port 444
, ajoutez ceci dans votre fichier de configuration :
Host maman Hostname ordi.de.ma.maman User gaston Port 444
Et, pour vous connecter sur l'ordi de votre môman, il vous suffira maintenant de taper simplement la ligne suivante :
ssh maman
Host ServeurA IdentityFile ~/.ssh/cleA Host ServeurB IdentityFile ~/.ssh/cleB
Pour une liste de toutes les options disponibles, et il y en a… une floppée ! Tapez :
man ssh_config
Si le pc serveur est réinstallé, la clé unique l'identifiant est changée.
Le client va détecter le changement et soupçonner que quelqu'un d'autre essaye de se faire passer pour le serveur original et vous obtiendrez alors un message comme celui-ci :
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx. Please contact your system administrator. Add correct host key in /home/user/.ssh/known_hosts to get rid of this message. Offending key in /home/user/.ssh/known_hosts:9 RSA host key for 192.168.X.XX has changed and you have requested strict checking. Host key verification failed.
Ce message indique la ligne contenant l'empreinte de l'ancien serveur ici :
Offending key in ~/.ssh/known_hosts:9
Dans cet exemple, il faut alors supprimer la 9ème ligne de son fichier /home/user/.ssh/known_hosts
Donc nous éditons6) ce fichier en user7) :
nano ~/.ssh/known_hosts
et nous supprimons cette 9ème ligne.
À notre prochain contact vers le serveur, après le yes d'acceptation habituelle, une nouvelle clé d'identification sera créée et tout ira pour le meilleur des mondes ssh possible.
Rappel : il s'était créé une paire de clés, rangée par exemple dans le dossier proposé ~/.ssh/ :
- “~/.ssh/id_rsa”
- “~/.ssh/id_rsa.pub” (celle qu'on a envoyé au serveur, par exemple avec la commande ssh-copy-id
ou en scp
.
Donc si on veut, pour une raison ou un autre8) changer cette pair de clé, il faut :
yes
: PasswordAuthentication yes
9);service ssh start
;⇒ On peut ensuite recommencer la procédure : se connecter une première fois au serveur (si ça coince ne pas hésiter à supprimer sur le client ~/.ssh/known_hosts si on ne l'a pas fait) ; puis côté client créer une paire de clé et l'envoyer au serveur).
ssh-keygen -t dsa
), la commande est (côté client) :ssh-keygen -p
COPIER
un fichier sécurisé vous devez vous servir de : SCPMONTER
les fichiers servez-vous de : SSHFS