Archive pour février 2011

Authentification SSH par clé privé/clé publique

Authentification SSH par clé privé/clé publique

l’authentification par clé necessite 2 clés :
la clé publique et la clé privé. Ces deux clé sont complémantaires
– la clé publique : ~/.ssh/id_dsa.pub
elle devra etre ajoutee sur le serveur dans le fichier ~/.ssh/authorized_keys2 du user utilisé pour la connexion
sur des vieilles versions de ssh ou des OS moins standard, il est possible qu’il s’agisse de :
~/.ssh/authorized_keys
~/.ssh2/authorized_keys2
– la clé privé : ~/.ssh/id_dsa
elle devra rester sur la machine cliente et être bien protégée (quiconque l’aura pourra s’authentifier sur le serveur)
1 ) si il n’y a pas de clés ou que la clé publique a été retirée, créer de nouvelles clés
attention: vous risquez d’ecraser une clé privé existante et ainsi d’empecher la connexion
a un serveur ayant la clé publique correspondante.
#  ssh-keygen -t dsa -P ""
ici on crée des clés de type dsa , avec un mot de passe vide (si on met un mot de passe, il sera demandé à chaque connexion en plus de l’échange de clé)
( # keygen -h pour connaitre toutes les possibilités )
les fichiers suivants sont créés :
~/.ssh/id_dsa
~/.ssh/id_dsa.pub
2 ) ajouter la clé publique d’un client à un serveur
allers sur le client, dans le répertoire ~/.ssh/ du user à utiliser pour la connexion.
copier la clé publique sur le serveur :
# scp id_dsa.pub <user>@<serveur>:.ssh/
vous connecter sur le serveur :
# ssh <user>@<serveur>
(le mot de passe est demandé)
ajouter la clé publique du client dans les clé authorisées du serveur :
# cat .ssh/id_dsa.pub >> .ssh/authorized_keys2
supprimer ce fichier, maintenant inutile
# rm -f .ssh/id_dsa.pub
très important !  si ce n’est pas fait, regler les droits du fichier authorized_keys2, sinon ssh refuse la connexion.
# chmod 600 .ssh/authorized_keys2
vous déconnecter
# exit
vérification :
reconnectez vous au serveur :
# ssh <user>@<serveur>
(cette fois, le mot de passe n’est plus demandé)
Troubleshouting
un mot de passe est toujours demandé :
– si vous avez utilisé une clé existante, celle si a peut-etre un mot de passe, essayez de le retirer avec « ssh-keygen -p »
– verifiez les droits des fichiers présents dans .ssh
– l’authentification par clé a elle été désactivée ? voir dans /etc/ssh/sshd_config du serveur et dans /etc/ssh/ssh_config du client.
pour plus d’info : ajouter l’option « -v » ou « -vv »
se connecter avec PuTTY ?
le format des clé est différent pour le client Putty. utiliser C:\Program Files\PuTTY\puttygen.exe pour convertir la clé (conversion>import key, puis « save private key »)
ensuite dans putty, spécifier la clé sauvegardée dans Connection>SSH>Auth> »Private key file for authentification »
un bon article :

Slitaz base avec wifi, ssh, screen et IRC sur un HP t5530

installation de Linux Slitaz sur un thin client HP t5530

Le but ici est d’avoir une linux-box simple, connectée en wifi sur un réseau WPA2, exécutant un serveur ssh, un « screen » et un client IRC « rhapsody ».

le t5530 (idem t5520) est un client léger dispose de 128Mo de RAM, ce qui est assez peu.
nous allons donc partir d’un version « base » de slitaz pour que le système puisse fonctionner.
Je rappel le principe de slitaz :
le média de boot contient 3 choses
– les fichiers de choix de boot : boot/extlinux/*
– le noyau linux : boot/bzImage
– le filesystem qui sera décompressé en ram lors du boot : boot/rootfs.gz
en l’occurrence, cela signifie que le système fonctionnera uniquement avec la ram une fois le système booté et que le média de boot n’est pas monté en temps normal.
De cette façon, une machine sous slitaz supportera très bien d’être arrêté en coupant son alimentation.
De plus cette façon de procéder à l’avantage de prolonger la durée de vie de la Flash, qui n’aime pas beaucoup les écritures répétées.
Cependant, le souci est  que de l’espace en RAM est utilisé pour stocker le filesystem lors du fonctionnement, or nous avons ici très peu de RAM.
nous allons donc utiliser  l’image « base » de Slitaz, qui ne fait que 8 Mo, nous rajouterons ensuite uniquement les paquets necessaires. Sachez tout de même qu’il existe une version  « loram » plus optimisée pour les systèmes ayant peu de mémoire vive.

voici la marche a suivre (sous windows)

choisir slitaz base cooking ici:
ayez une clé usb disponible.
sous windows utilisez le soft tazusb.exe :
ce programme vous permettra de créer une clé usb bootable avec l’image Slitaz téléchargée.
démarrez votre thin client avec la clé USB créée.
à la fin du boot, vous aurez peut-etre un message d’erreur, tapez Ctrl-C pour vous en débarrasser.
loggez vous avec l’identifiant et le mot de passe suivant : root / root
votre client doit avoir accès à Internet par ethernet

installez slitaz sur le disque embarqué :

vérifiez la présence de disque sur la machine :

# fdisk -l
vous devez voir votre clé usb et le disque embarqué.
montez la clé usb
# mount  /dev/sda/ /media/usbdisk/
vous devez disposer de l’iso originale pour installer le sur un disque, nous allons la récupérer
# cd /media/usbdisk
# wget http://mirror.slitaz.org/iso/cooking/flavors/slitaz-cooking-base.iso

formater le disque embarqué pour recevoir slitaz :

# tazusb format /dev/hda1

enfin installer slitaz base sur le disque:

# tazusb gen-iso2usb /media/usbdisk/slitaz-cooking-base.iso /dev/hda1
éteindre, retirer la clé USB, redémarrer.
vous devez avoir le me boot que précédemment.
vous pouvez commencer à installer des paquets

pour le wifi :

installer les modules qui prennent en charge les cartes et dongles wifi:

tazpkg get-install linux-wireless

il y a des chances que les modules disponibles ne soit pas ceux du noyau qui est utilisé en ce moment. c’est pourquoi il faut récuperer le dernier noyau aussi.

tazpkg get-install linux
Il faut placer le noyau au bon endroit avec le bon nom pour pouvoir rebooter la prochaine fois sur le bon noyau
(et le wifi ne fonctionnera pas avant ce reboot, faute de module compatible)
donc montez votre media
mount /dev/hda1 /media/flash

copier le noyau au bon endroit

cp /boot/vmlinuz-2.6.37-slitaz /media/flash/boot/bzImage
installer wpa_supplicant
tazpkg get-install wpa_supplicant

pour le ssh

modifier  /etc/rcS.conf pour que le serveur ssh se lance au démarrage :
# vi /etc/rcS.conf
modifier la ligne RUN_DAEMONS pour avoir ceci :
RUN_DAEMONS="dropbear dbus hald firewall slim"
et dans /etc/daemons modifiez la ligne DROPBEAR_OPTIONS pour avoir :
DROPBEAR_OPTIONS="-b /etc/dropbear/banner"

pour screen

tazpkg get-install elfutils
tazpkg get-install screen

pour le client IRC

tazpkg get-install rhapsody

configuration du réseau

rajout d’un « sleep 5 »  au début de /etc/init.d/network.sh pour laisser le temps au noyau de detecter/configurer le materiel avant de monter l’interface réseau
# vi /etc/init.d/network.sh
configuration de /etc/network.conf pour renseigner son SSID et ses identifiant WPA
# vi /etc/network.conf

sauvegarde des modifications

Les modifications faite ne sont faites que dans la RAM, dans l’état actuel des choses un reboot vous ramènera à un système  vierge comme au début de cette page.
pour sauvegarder les modifications, il faut utiliserla commande « tazusb » :
# mount /dev/hda1 /media/flash
# tazusb writefs gzip
# cp /rootfs.gz /media/flash/boot/rootfs.gz
Bon Courage.