title Windows
        rootnoverify (hd0,0)
        makeactive
        chainloader +1

Mais parfois, c’est embêtant…

Vous administrez un serveur MySQL sur un base Debian et vous avez oublié le mot de passe de root pour accèder à phpmyadmin? Pas de panique!

Suivez ces instructions:

cat /etc/mysql/debian.cnf

Relevez le mot de passe donné dans ce fichier.

Allez sur votre interface phpmyadmin et utilisez l’utilisateur debian-sys-maint avec le mot de passe relevé ci dessus.
Ensuite, grâce au lien privilèges, allez modifiez le mot de passe voulu.

Le fichier /etc/mysql/debian.cnf possède les droits en 600 et appartient à root. Il n’est donc pas lisible par un autre utilisateur.

Cette méthode rapide et facile ne fonctionne que sur les bases Debian. Pour les autres, ou si celle ci ne fonctionne pas, il faudra utiliser les méthodes classiques, comme par exemple celle ci

Avouez qu’il serait quand même plus pratique de recevoir le log au lieu d’une simple phrase « Please inspect this machine, because it may be infected. ».

Heureusement, il est possible de modifier simplement ce comportement.

En root, éditez le fichier /etc/cron.daily/rkhunter.

Modifiez la ligne:

...
/usr/bin/nice -n $NICE $RKHUNTER --cronjob --report-warnings-only \
--createlogfile /var/log/rkhunter.log $RK_OPT > $OUTFILE
...

pour qu’elle ressemble à celle ci

...
/usr/bin/nice -n $NICE $RKHUNTER --cronjob --report-warnings-only \
--createlogfile /var/log/rkhunter.log --display-logfile $RK_OPT > $OUTFILE
...

Au prochain lancement automatique, si vous avez paramétré rkhunter pour qu’il vous envoie un mail, vous recevrez en plus le log du scan.

Si vous possédez un serveur avec SSH opérationnel, vous ne serez pas long à avoir des messages tels que ceux ci dans le fichier /var/log/auth.log:

...
Mar 11 12:48:21 serv sshd[12956]: Failed password for invalid user root from 64.71.148.162 port 47270 ssh2
Mar 11 15:45:04 serv sshd[6954]: Did not receive identification string from 210.21.30.72
Mar 11 15:46:48 serv sshd[7041]: Did not receive identification string from 81.93.188.5
Mar 11 15:47:50 serv sshd[7106]: User root from 210.21.30.72 not allowed because none of user s groups are listed in AllowGroups
Mar 11 15:47:50 serv sshd[7106]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=210.21.30.72  user=root
Mar 11 15:47:52 serv sshd[7106]: Failed password for invalid user root from 210.21.30.72 port 54346 ssh2
Mar 11 15:49:33 serv sshd[7241]: User root from 81.93.188.5 not allowed because none of user s groups are listed in AllowGroups
Mar 11 15:49:33 serv sshd[7241]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=81.93.188.5  user=root
Mar 11 15:49:35 serv sshd[7241]: Failed password for invalid user root from 81.93.188.5 port 44663 ssh2
Mar 12 00:51:18 serv sshd[22229]: User root from host.ongamemarketing.com not allowed because none of user s groups are listed in AllowGroups
Mar 12 00:51:18 serv sshd[22229]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=host.ongamemarketing.com  user=root
Mar 12 00:51:20 serv sshd[22229]: Failed password for invalid user root from 174.133.12.130 port 48089 ssh2
Mar 12 00:51:22 serv sshd[22236]: User root from host.ongamemarketing.com not allowed because none of user s groups are listed in AllowGroups
Mar 12 00:51:22 serv sshd[22236]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=host.ongamemarketing.com  user=root
Mar 12 00:51:24 serv sshd[22236]: Failed password for invalid user root from 174.133.12.130 port 48521 ssh2
Mar 12 01:47:10 serv sshd[30827]: Did not receive identification string from 114.200.199.144
Mar 12 01:53:17 serv sshd[31227]: Invalid user staff from 114.200.199.144
Mar 12 01:53:17 serv sshd[31227]: pam_unix(sshd:auth): check pass; user unknown
Mar 12 01:53:17 serv sshd[31227]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=114.200.199.144
Mar 12 01:53:19 serv sshd[31227]: Failed password for invalid user staff from 114.200.199.144 port 35343 ssh2
Mar 12 01:53:27 serv sshd[31234]: Invalid user sales from 114.200.199.144
...

Vous avez besoin de pouvoir vous connecter en ssh depuis le réseau local, depuis l’extérieur, mais vous voulez limiter les risques. Il existe plusieurs solutions, qui peuvent être cumulées:

Sécuriser par la configuration de SSH

N’autoriser QUE certains utilisateurs à accéder au service

Si vous avez peu d’utilisateurs nécessitant un accès ssh, vous pouvez les déclarer ainsi en ajoutant cette ligne dans le fichier de configuration /etc/ssh/sshd_config (et en redémarrant le service après chaque modification)

AllowUsers titi toto

Après relance du service ssh, les utilisateurs titi et toto pourront se connecter en ssh, les autres utilisateurs se verront refuser leur mot de passe.

Vous pouvez aussi créer un groupe (par exemple: sshusers) et autoriser tous les utilisateurs de ce groupe à se connecter en ssh. Ceux n’appartenant pas à ce groupe se verront refuser leur mot de passe.

addgroup sshusers
adduser toto sshusers
adduser titi sshusers

Puis ajoutez la ligne suivante dans /etc/ssh/sshd_config:

AllowGroups sshusers

IN and OUT

Oui, mais voilà un nouveau problème:

1. Le serveur fait passerelle avec internet, et possède une carte sur le réseau interne, et une carte vers le réseau internet.
2. Tous mes utilisateurs internes doivent pouvoir accéder par ssh (ce qui est le cas avec la configuration par défaut), mais ne doivent pas pouvoir accéder depuis l’extérieur (parce qu’ils n’en ont pas besoin, ou parce que les mots de passe des utilisateurs sont trop simples)
3. Si je laisse la configuration ainsi, le serveur sera piraté très rapidement.

Il est possible d’ajouter une directive à la liste des autorisations, permettant de faire ceci:

AllowUsers *@192.168.0.*

Ainsi, tous les utilisateurs du réseau local (et possédant un compte sur le serveur) pourront accéder par ssh, mais ne pourront pas le faire s’ils ne proviennent pas du réseau local (par internet).
Si je veux pouvoir ensuite me connecter depuis l’internet pour faire de la télémaintenance, il me suffit d’ajouter mon compte et de transformer la ligne en ceci:

AllowUsers manu *@192.168.0.*

(1)

Il est possible aussi de cumuler les directives Users et Groups pour obtenir des possibilités supplémentaires. Exemple:

1. Seuls certains de mes utilisateurs locaux doivent pouvoir se connecter au serveur, depuis le net ou en local.
2. Je veux pouvoir m’y connecter de partout (local et internet)

La configuration est la suivante:

AllowGroups sshusers
AllowUsers manu

Ainsi, seuls les utilisateurs appartenant au groupe sshusers pourront se connecter au serveur, en plus de l’utilisateur manu qui pourra se connecter depuis n’importe où.

Si je possède un adresse IP fixe, et que je suis assez bête pour crée un compte manu avec le mot de passe manu, je peux tout de même limiter l’accès par mon adresse IP (80.80.80.80)

AllowUsers @80.80.80.80

Je suis désolé, ça va pas être possible…

Vous pouvez même ajouter des directives inverses, pour interdire les connexions:

DenyUsers invite
DenyGroups stagiaires

Autres configurations conseillées de ssh

Vous pouvez modifier d’autres éléments du fichier de configuration, qui permettront de sécuriser un peu plus votre serveur ssh:

• Changer le port d’écoute par défaut: vous pouvez changer ce port par autre chose que 22. Sachez cependant que la protection apportée par ce changement est TRÈS FAIBLE. Un scan de vos port repérera le port que vous avez choisi, et des logiciels de scans sont capable de déterminer le service qui tourne derrière ce port. Cela vous permettra seulement d’échapper à certains robots qui ne tentent des connexions que sur le port 22.
• N’autoriser une identification que par clef: il vous faudra générer des clefs d’identification (avec seahorse pour gnome ou ssk-keygen) pour tous vos utilisateurs et empêcher l’autentification par mot de passe dans la configuration de SSH. Cette protection est très efficace, par contre, il faut que les clefs soient sécurisées (pas sur une clef usb qui peut se perdre ou se faire voler, pas sur un partage accessible, pas échangées par courriel, …). L’autre inconvénient, c’est que vos clefs doivent voyager avec vous et être installées sur les ordinateurs que vous utilisez; d’où une incompatibilité avec le point précédent, si vous n’avez pas une politique stricte de stockage des clefs.
• Ne JAMAIS autoriser la connexion de l’utilisateur root: (PermitRootLogin no).  Il y a toujours un utilisateur root sur tous les Linux (même sur Ubuntu) et vous facilitez le travail d’un éventuel pirate, puisqu’il n’a qu’un mot de passe à trouver. Autrement, il doit d’abord trouver un login valide, puis son mot de passe, puis celui du root. Si vos mots de passe et vos logins sont adaptés, cela lui prendra des années avant d’y arriver par ce moyen.

Ajouter des logiciels de sécurisation

fail2ban

fail2ban est un logiciel qui va surveiller les tentatives de connexion échouées dans le fichier /var/log/auth.log , et bloquer, en modifiant les règles iptables à la volée, un nombre trop élevé de connexions échouées. Ce logiciel permet aussi, de la même manière, de protéger votre serveur apache, postfix, vsftpd, proftpd, wuftpd, sasl, dns, …
Une fois installé, il vous suffit d’éditer le fichier /etc/fail2ban/jail.conf pour configurer son comportement. Exemple pour ssh:

...
[DEFAULT]
# "ignoreip" can be an IP address, a CIDR mask or a DNS host
ignoreip = <a class="linkification-ext" title="Linkification: http://10.0.0.0/24" href="http://10.0.0.0/24">10.0.0.0/24</a>
bantime  = 600
maxretry = 3
...
[SECTION_NAME]
enabled = true # vérifier que cette valeur est à True, sinon le logiciel n'est pas activé!
...
[ssh]
enabled = true
port	= ssh
filter	= sshd
logpath  = /var/log/auth.log
maxretry = 6

Dans cette configuration:

• Tout ce qui vient du réseau local (10.0.0.0/24) est ignoré. Donc je pourrais me tromper autant de fois que voulu, je ne me ferais pas bannir.
• En dehors de mon réseau local, par ssh, j’ai droit à 6 tentatives (par session) de connexions échouées. Ensuite, je me ferais bannir. Si je m’identifie, la fois suivante, j’ai encore droit à 6 tentative (ça repart à zéro avec l’identification réussie)
• Si je suis banni, toutes mes tentatives de connexions pendant les 600 prochaines secondes (10 minutes) seront refusées, sans possibilité d’identification.

La configuration de fail2ban vous offre plein d’autres possibilité, comme de recevoir des mails en cas de tentatives échouées, d’utilisateurs inconnus, etc. Consultez la documentation pour exploiter cet outils très pratique.

denyhosts

denyhosts permet de faire la même chose, un peu différemment. Il maintient une base d’IP bannies dans /etc/hosts.deny et les compare avec les tentatives de connexions.

Il a quelques avantages sur fail2ban, même si je le trouve plus lent (consommateur) à l’usage:

1. Il permet de bloquer les tentatives d’accès ssh sur l’utilisateur root dès la première tentative.
2. Il permet de paramétrer comme on le veut les champs from et subject des mails envoyés
3. Il permet d’envoyer les rapports vers le syslog, qui peut être distant (et ineffaçable)

Simple à configurer, le fichier /etc/denyhosts.conf est largement commenté

Sur le même sujet:

• http://www.fail2ban.org/wiki/index.php/FAQ_french
• http://doc.ubuntu-fr.org/denyhosts
• http://www.alsacreations.com/tuto/lire/622-Securite-firewall-iptables.html
• http://senseya.free.fr/index.php?tag/fail2ban

(1) Ne pensez pas que je suis assez bête pour utiliser un login simple tel que « manu » sur mes serveurs… C’est juste pour l’exemple.

S’il n’est pas installé par défaut sur votre distribution, installez le de manière classique.

Si vous utilisez rkhunter pour scanner votre machine, sans opération particulière vous aurez deux problèmes:

1. rkhunter n’utilisera pas par défaut unhide, et vous perdrez donc le bénéfice d’un seul scan.
2. rkhunter va détecter un warning sur unhide et unhide-linux26, ce qui vous enverra un mail à chaque détection.

La solution est simple: il suffit d’indiquer à rkhunter que unhide est fiable, en l’ajoutant à sa base de donnée. Ensuite, rkhunter utilisera unhide automatiquement.

ATTENTION: n’utilisez la commande suivante QUE SI VOUS ÊTES SÛR de votre système ! En effet, cette commande va réinitialiser la base de données des programmes considérés comme sûrs par rkhunter. Si vous avez un rootkit ou des programmes cachés, ils ne seront plus détectés!

Il est conseillé de lancer un rkhunter -c et de vérifier le rapport avant de lancer la commande suivante.

Maintenant que vous êtes prévenus, voici la commande magique (en root ou avec sudo):

rkhunter --propupd

C’est tout. La prochaine fois que rkhunter sera lancé, manuellement ou par la programmation, unhide sera détecté et utilisé.

application-par-defaut

Mais si vous désirez changer d’application, comment faut il faire ? Encore une fois, avec le libre, c’est simple si vous savez où aller chercher l’information.

La liste des associations entre les type de fichiers et les applications à lancer se trouvent dans le fichier ~/.local/share/applications/mimeapps.list (ces dossiers et fichiers ne sont présents qu’une fois que vous avez créé au moins une association)

Ce fichier se compose ainsi:

[Added Associations]
x-content/audio-cdda=vlc.desktop;

Si je désire changer l’application associée aux fichiers audio CD, il me suffit de modifier le fichier pour lui donner le nom du lanceur de l’application voulue.

Voici un autre exemple de fichier sur un ordinateur utilisé quotidiennement:

[Added Associations]
application/x-shellscript=userapp-kwrite-MEM3AU.desktop;gedit.desktop;
application/x-extension-inf=gedit.desktop;
application/x-designer=userapp-designer-qt4-YG48AU.desktop;
text/x-python=userapp-wing-101-3.1-NFH9NU.desktop;userapp-wing-101-3.1-SGDVNU.desktop;gedit.desktop;userapp-python-CDV5AU.desktop;
video/x-mng=gimp.desktop;
image/svg+xml=inkscape.desktop;
audio/x-vorbis+ogg=userapp-audacity-ENNGCU.desktop;
image/x-ico=gimp.desktop;
application/x-executable=userapp-wine-HQHEDU.desktop;userapp-bash-V6E5CU.desktop;
application/msword=ooo-writer.desktop;kwrite.desktop;gedit.desktop;
application/pdf=userapp-kpdf-8V7VLU.desktop;evince.desktop;gimp.desktop;
application/x-cd-image=userapp-vlc-Z4WYDU.desktop;
application/x-extension-2008=eog.desktop;
application/octet-stream=eog.desktop;
application/x-dia-diagram=dia-common.desktop;
application/x-extension-dat=gedit.desktop;
application/x-extension-QCM=ooo-template.desktop;
text/html=firefox.desktop;geany.desktop;
text/css=geany.desktop;
image/x-xcf=
image/png=eog.desktop;
text/x-gettext-translation=poedit.desktop;userapp-poedit-8NECLU.desktop;
application/x-flash-video=vlc.desktop;totem.desktop;
 
[Removed Associations]
application/x-shellscript=ooo-writer.desktop;wine.desktop;userapp-wine-HQHEDU.desktop;userapp-kwrite-3738AU.desktop;kde-kate.desktop;kde-kwrite.desktop;
text/x-python=ooo-writer.desktop;wine.desktop;userapp-wine-HQHEDU.desktop;userapp-eclipse-0HNYBU.desktop;
application/x-dia-diagram=opera.desktop;firefox.desktop;thunderbird.desktop;kde-kfmclient_html.desktop;geany.desktop;gedit.desktop;
image/x-xcf=userapp-inkscape-0BW2KU.desktop;
image/png=inkscape.desktop;
text/html=kwrite.desktop;ooo-writer.desktop;thunderbird.desktop;

Vous pouvez noter qu’on peut associer plusieurs applications à un type de fichier: ce seront les applications lancées si vous double cliquez sur un fichier. Si la première n’est pas trouvée, la deuxième sera lancée, et ainsi de suite.

Cette liste d’applications est celle que vous pouvez voir si vous faites un clic droit sur un fichier, que vous choisissez Propriétés et que vous allez dans l’onglet Ouvrir avec.

liste-des-applications-pour-html

Si vous supprimez une des applications de la liste proposée (en cliquant sur le bouton Enlever de cette fenêtre), cette suppression d’association sera notée dans la liste [Removed Associations] du fichier  ~/.local/share/applications/mimeapps.list. Par exemple, nous voyons dans le fichier ci dessus (ligne 31) que les images au format png ne doivent pas être ouvertes avec le logiciel inskape.

Classement des dossiers

L’organisation des dossiers est laissée à votre goût, mais pour simplifier les explications, voici l’organisation que nous allons adopter sur le serveur:

• Un dossier à la racine nommé bzr qui contiendra les divers projets à versionner
• Un dossier par projet dans le dossier /bzr (projet1 et projet2 )
• Les droits en lecture/écriture pour les membres du groupe projets sur le dossier /bzr (récursivement)

addgroup projets              # ajout d'un groupe projets
adduser manu projets        # ajout de l'utilisateur au groupe projets
mkdir -p /bzr/projet1         # création du dossier du premier projet
mkdir -p /bzr/projet2         # création du dossier du deuxième projet
chgrp -R projets /bzr         # attribution du groupe projet à tous les fichiers du répertoire /bzr
chmod -R g+rw /bzr          # attribution des droits en lecture/écriture à tous les fichiers pour les membres du groupe projets

Il n’est pas nécessaire d’installer bazaar sur le serveur, mais il est nécessaire que l’accès par ssh fonctionne, avec ou sans mot de passe.

Sur les clients

Mise en place du projet sur le serveur

Ce sont les clients (qui vont modifier le code des projets) qui doivent installer le logiciel bazaar

apt-get install bzr python-paramiko

Les préférences de bazaar (limitées) se trouvent dans Système/Préférences/Bazaar preferences

Ce sont eux, aussi, qui vont initier le versionning, à l’endroit qui leur va bien:

mkdir ~/projets
mv ~/Bureau/monprojet ~/projets # déplacement des fichiers du prototype dans les projets
cd ~/projets/monprojet
bzr init                        # initialisation du versionning du projet
bzr add *                    # ajout de tous les fichiers (récursif) au versionning
bzr commit -m "Création" # prise en compte des modifications avec le commentaire "Création"
bzr push sftp://manu@server/bzr/projet1 --use-existing-dir # envoi de la version du projet sur le serveur en utilisant les répertoires créés plus haut.

Récupération des fichiers sur un autre client

mkdir ~/beauprojet     # création du dossier qui va accueillir le projet
cd ~/beauprojet
bzr init                     # initialisation du dossier au versionning
bzr merge sftp://toto@server/bzr/projet1/  # intégration des fichiers de "monprojet" dans le dossier "beauprojet" dans lequel on se trouve

Chacun des clients possède maintenant les fichiers sur lesquels effectuer les développements

Codage!

Les clients vont effectuer les modifications sur les documents. Après chaque modification (enfin, chaque fin de bloc de modification) ou avant l’envoi des fichiers modifiés, il faudra effectuer la commande suivante (qu’ils aient décidé ou non d’envoyer les fichiers sur le serveur. Les commit peuvent être fait hors connexion.):

bzr commit -m "message"

qui permet de prendre en compte les modifications effectuées dans le versionning et, accessoirement, de revenir à une version antérieure.

Il suffit ensuite « d’assembler » les fichiers modifiés avec ceux du serveur, que ceux ci aient été modifiés ou non par une autre personne:

bzr merge sftp://toto@server/bzr/projet1/

Enfin, les fichiers « finaux » sont envoyés sur le serveur afin d’être disponibles pour tous les développeurs:

bzr push sftp://toto@server/bzr/projet1/

A retenir

• Il ne suffit pas d’ajouter un fichier/dossier au répertoire du projet pour qu’il soit pris en compte. Il faut le faire manuellement avec bzr add lefichier
• Pour supprimer un fichier, il faut utiliser bzr remove lefichier
• la commande bzr status permet de savoir l’état des fichier (plus exactement, du versionning)
• La commande bzr log permet de voir le log des changements avec les commentaires
• la commande bzr conflicts affiche les versions de fichiers en conflits
• La commande bzr resolve lefichier permet de résoudre les conflits dans le fichier lefichier
• Le manuel de bzr donne plein d’informations et de commandes utilisables

Interface graphique

Il existe une interface graphique pour bazaar nommée olive (paquet bzr-gtk) que je n’ai pas réussi à utiliser: impossible de comprendre les messages d’erreur (pas parlant) et pas trouvé de configuration à effectuer (ni dans le programme, ni dans les fichiers de configuration).

Pas grave, je suis un adepte de la ligne de commande.

Autres sources:

http://bazaar-vcs.org/fr/IntroductionABzr

Notez qu’il existe des outils graphiques pour réaliser ces opérations (par exemple seahorse sous Gnome), mais je n’en parlerais pas.

Sur l’ordinateur client (manu-desktop)

La première chose à faire, si vous n’avez pas de clef pour votre machine, est d’en générer une

manu@manu-desktop:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/manu/.ssh/id_rsa):
Created directory '/home/manu/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/manu/.ssh/id_rsa.
Your public key has been saved in /home/manu/.ssh/id_rsa.pub.
The key fingerprint is:
cd:9e:bb:0a:1e:22:29:fa:e3:dc:12:72:8a:15:13:58 manu@manu-desktop
manu@manu-desktop:~$ ls -l ~/.ssh
total 8,0K
3367418 -rw------- 1 manu manu 1,7K 2009-01-15 13:26 id_rsa
3367419 -rw-r--r-- 1 manu manu  399 2009-01-15 13:26 id_rsa.pub
manu@manu-desktop:~$

Ne mettez pas de passphrase et laisser les options par défaut pour la création de la clef. Il est aussi possible de spécifier les options via la ligne de commande:

ssh-keygen -qt rsa -b 1024 -C manu -f ~/.ssh/manu@manu-desktop.rsa -N ""

La commande précédente crée une clef rsa (-t) avec le commentaire (-C) manu d’une longueur de 1024 bits (-b) dans le fichier ~/.ssh/manu@manu-desktop.rsa (-f) avec une passphrase (-N) vide.

Sur le serveur (server)

Le compte utilisateur de connexion doit exister. Il n’est pas obligé que ce soit le même identifiant que sur le client. Par exemple, sur le serveur, mon compte est nommé zephir.

[root@server]:# adduser zephir
Ajout de l'utilisateur « zephir »...
Ajout du nouveau groupe « zephir » (1002)...
Ajout du nouvel utilisateur « zephir » (1002) avec le groupe « zephir »...
Création du répertoire personnel « /home/zephir »...
Copie des fichiers depuis « /etc/skel »...
Entrez le nouveau mot de passe UNIX :
Retapez le nouveau mot de passe UNIX :
passwd : le mot de passe a été mis à jour avec succès
Modification des informations relatives à l'utilisateur zephir
Entrez la nouvelle valeur ou « Entrée » pour conserver la valeur proposée
Nom complet []:
N° de bureau []:
Téléphone professionnel []:
Téléphone personnel []:
Autre []:
Ces informations sont-elles correctes ? [o/N] o
[root@server]:#

Sur l’ordinateur client (manu-desktop), fin des opérations

Il ne reste plus au client qu’à envoyer sa clef d’identification au serveur simplement par la commande suivante:

ssh-copy-id -i ~/.ssh/id_rsa.pub zephir@server

Acceptez l’identification du serveur, le mot de passe est demandé (puisque vous n’avez pas encore envoyé la clef) et la clef est copiée dans le fichier /home/zephir/.ssh/authorized_keys.
Tentez la commande suivante (Ctrl+D pour sortir)

ssh zephir@server

Vous ne devriez plus avoir de demande de mot de passe.

Sur le serveur, fin des opérations

Il est possible de sécuriser le serveur afin de n’accepter que les authentifications avec clef et sans demande de mot de passe (pour ssh. L’accès en local demandera toujours un mot de passe).
Ainsi, les tentatives d’attaque par force brute sont vouées à l’échec. MAIS, soyez conscient que vous ne pourrez plus vous connecter depuis une autre machine que celle pour laquelle vous avez envoyé la clef, pas plus que vous ne pourrez envoyer d’autres clefs.
Paramétrez le fichier /etc/ssh/sshd_config tel que ci dessous:

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes
 
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      %h/.ssh/authorized_keys
 
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

Relancez ensuite le serveur ssh pour prendre en compte les modifications.

Note sur la sécurité

L’accès au serveur est possible sans authentification par l’utilisateur manu depuis l’ordinateur client (manu-desktop). Si cet ordinateur est un portable et qu’il se fait voler, celui qui arrivera à se connecter avec l’identité de manu arrivera sans demande de mot de passe à se connecter au serveur !
Réfléchissez bien à l’utilisation de ce mode de fonctionnement avant de le mettre en place.
En cas de vol, il suffira de supprimer le fichier /home/zephir/.ssh/authorized_keys pour que la clef volée avec le portable ne soit plus opérationnelle.
Vous pouvez, de même, recréer et changer vos clefs d’identification lorsque vous le voulez en réutilisant les commandes données en début d’article.

Liens:

http://doc.ubuntu-fr.org/gnupg
http://doc.ubuntu-fr.org/ssh

L’installation du paquet rsync, sur Ubuntu, ne suffit pas à activer un serveur rsync; il reste quelques manipulations simples à mettre en place.

Tout d’abord, si le progrmme rsync n’est pas installé, faites le:

apt-get install rsync

Le serveur rsyncd a besoin d’un fichier de configuration /etc/rsyncd.conf. Voici un exemple de fichier:

# sample rsyncd.conf configuration file

# GLOBAL OPTIONS

#motd file=/etc/motd
#log file=/var/log/rsyncd
# for pid file, do not use /var/run/rsync.pid if
# you are going to run rsync out of the init.d script.
pid file=/var/run/rsyncd.pid
#syslog facility=daemon
#socket options=
read only = yes
list = yes
uid = nobody
gid = nogroup
use chroot = yes
max connections=10
log format = %t: host %h (%a) %o %f (%l bytes). Total %b bytes.
syslog facility=local5

# MODULE OPTIONS
[astuces]
	comment = repertoire des astuces
	path = /var/www/astuces
#	use chroot = yes
#	max connections=10
	lock file = /var/lock/rsyncd
# the default for read only is yes...
	#read only = yes
	#list = yes
	#uid = nobody
	#gid = nogroup
#	exclude =
#	exclude from =
#	include =
#	include from =
#	auth users =
#	secrets file = /etc/rsyncd.secrets
	strict modes = yes
#	hosts allow =
#	hosts deny =
	ignore errors = no
	ignore nonreadable = yes
	transfer logging = no
#	log format = %t: host %h (%a) %o %f (%l bytes). Total %b bytes.
	timeout = 600
	refuse options = checksum dry-run
	dont compress = *.gz *.tgz *.zip *.z *.rpm *.deb *.iso *.bz2 *.tbz

Pour la définition des options, consulter le man.
Les options peuvent être placées dans une section (auquel cas elles ne s’appliquent qu’à cette section, ou en tête de fichier (hors section) et s’appliquent alors à toutes les sections, sauf configuration contraire dans l’une d’elle.

Le serveur peut désormais être lancé manuellement ainsi:

sudo rsync --daemon

Mais il est plus simple d’activer le lancement en démon au démarrage en modifiant le fichier /etc/default/rsync. Voici un fichier correctement paramétré:

# defaults file for rsync daemon mode
# start rsync in daemon mode from init.d script?
#  only allowed values are "true", "false", and "inetd"
#  Use "inetd" if you want to start the rsyncd from inetd,
#  all this does is prevent the init.d script from printing a message
#  about not starting rsyncd (you still need to modify inetd's config yourself).
RSYNC_ENABLE=true
# which file should be used as the configuration file for rsync.
# This file is used instead of the default /etc/rsyncd.conf
# Warning: This option has no effect if the daemon is accessed
#          using a remote shell. When using a different file for
#          rsync you might want to symlink /etc/rsyncd.conf to
#          that file.
# RSYNC_CONFIG_FILE=
# what extra options to give rsync --daemon?
#  that excludes the --daemon; that's always done in the init.d script
#  Possibilities are:
#   --address=123.45.67.89        (bind to a specific IP address)
#   --port=8730                (bind to specified port; default 873)
RSYNC_OPTS=''
# run rsyncd at a nice level?
#  the rsync daemon can impact performance due to much I/O and CPU usage,
#  so you may want to run it at a nicer priority than the default priority.
#  Allowed values are 0 - 19 inclusive; 10 is a reasonable value.
RSYNC_NICE='10'
# Don't forget to create an appropriate config file,
# else the daemon will not start.

Une fois ceci fait, il ne reste plus qu’à relancer rsync:

sudo killall rsync
sudo /etc/init.d/rsync restart

Désormais les utilisateurs peuvent synchroniser anonymement le répertoire que vous avez programmé par la commande:

rsync -avP www.montsite.org::astuces /mon/dossier/a/synchroniser/

Notez que dans la commande ci dessus, astuces est appelé module par rsync. Ce module correspond à la section entre crochets que vous avez défini dans le fichier de configuration ([astuces])

Autres sources d’information:

http://doc.ubuntu-fr.org/rsync
http://prendreuncafe.com/blog/?q=rsyncd
http://man.developpez.com/man5/rsyncd.conf.5.php

Je vous livre les manipulations qui m’ont permis de le faire fonctionner:

• Ouvrir le contôleur de volume (clic droit sur l’icone du haut parleur sur la barre des tâches et « ouvrir le contrôleur de volume »)
• Régler les options comme sur les captures ci dessous. Notez le périphérique contrôlé (HDA Intel)

Réglage de l'onglet lecture

Réglages de l'onglet enregistrement

Réglages de l'onglet options

• Lancer skype et ouvrir le réglage des préférences
• Ouvrir l’onglet son et régler comme sur la capture
  

  Options audio de skype

• Cliquez sur « Appliquer » et vous pouvez lancer un appel et profiter des communications par le réseau

A noter que j’utilise le noyau de FOZZY optimisé pour le AAO (http://aspireoneuser.com/forum/viewtopic.php?f=28&t=7560&start=0)

Section "Monitor"
Identifier      "Configured Monitor"
HorizSync       30.0 - 83.0
VertRefresh     55.0 - 75.0

EndSection

et

Section "Screen"
Identifier      "Default Screen"
Monitor         "Configured Monitor"
Device          "Configured Video Device"
DefaultDepth    24
SubSection "Display"
Depth        24
Modes        "1024x768" "960x600" "800x600"
EndSubSection

Ceci permet d’indiquer au serveur X qu’il peut sortir du mode sécurisé des dimensions 640×480 et 800×600 pour monter en fréquence vers des dimensions supérieures.