Sans doute l'un des services les plus utiles, et le mode de connection le plus fiable. Je ne m'attarderai pas ici sur l'utilisation courante d'SSH mais simplement les quelques éléments de configuration permettant de le sécuriser d'avantage encore :
Pour l'utilisation courante de SSH, Linux Journal a publié un très bon article de vulgarisation :
Cet article présente également l'ensemble des paramètres de configuration coté client et coté serveur.
OpenSSH est buggé (annoncé le 7 Mars 2002) et OpenBSD affecté, ça faisait bien longtemps que chose pareille n'était pas arrivée :)
Il faut donc le patcher (ou mettre carrément à jour sa version OpenBSD, Cf 4, Mais bon là en gros, juste un petit '=' à ajouter à la ligne 148 de /usr/src/usr.bin/ssh/channels.c, puis make et make install.
Le bug est sérieux, il permettrait à tout utilisateur disposant d'un compte d'acquérir les privilèges root. La possibilité d'exploiter cette faille sans compte local n'est pas exclue, et la possibilité pour un serveur SSH de l'exploiter contre un client vulnérable est envisagée.
SSH1, toujours très répandue, était la première version du protocole, apparue en 1995. SSH2 est la version actuelle du Secure Shell protocol, et fait l'objet d'un groupe de travail au sein de l'IETF pour devenir un standard à part entière. C'est une réécriture complète de SSH1, ayant pour but de pallier à ses principales limites, telles que l'absence de code d'authentification de message (message authentication codes, ie MAC, algorithme de hachage qui utilise en plus une clé privée nécessaire à la vérification de l'empreinte).
SSH1 est basé sur l'algorythme RSA, SSH2 supporte également DSA, ce deuxième étant exempt de brevet ou d'une quelconque restriction de license. Notons cependant que, le brevet RSA ayant expiré, plus rien ne justifie le choix en faveur de DSA (proposé comme standard fédéral de signature numérique par NIST...).
Plus important, la version 1 du protocole a souffert de graves vulnérabilités, auquelles seule l'équipe OpenSSH a su trouver des palliatifs (tels que la suppression du support RC4 pour le chiffrement). Voir le bulletin OpenSSH pour admirer le travail :
Une vulnérabilité importante concerne l'intégrité des données. Découverte en février 2001, cette faille permettrait en particulier d'insérer, en cours de session, des blocs de commandes encryptés potentiellement exécutables par le serveur. Bien que cette attaque relève de l'exploit, la vulnérabilité existe et aucun système et/ou implémentation SSH n'est épargnée, la seule recommandation consiste à passer en SSH2 :
SSH2 apporte fournit en effet des mécanismes supplémentaires pour assurer la confidentialité des échanges (chiffrement du traffic basé sur au moyen des algorythmes 3DES, Blowfish, CAST128 ou Arcfour), et surtout l'intégrité des données (hmac-md5, hmac-sha1).
Convaincu ?
Alors nous allons de ce pas désactiver SSH1, ne serait-ce que par principe :)
L'authentification par clé RSA, beaucoup plus sûre que l'authentification par mot de passe, est également plus contraignante puisqu'elle oblige à définir, coté serveur, une liste de clé autorisée et, coté client, à avoir toujours cette clé sur soi et la possibilité de l'utiliser depuis l'endroit d'où l'on se connecte. Pas forçément évident lorsqu'on veut se connecter depuis n'importe quel cybercafé équippé de machines windows (quoique les versions récentes de putty soient supposées gérer l'authentification RSA 2...). C'est en revanche idéal lorsqu'on se déplace constamment en compagnie de son portable :)
Mêmes restriction à l'égard de l'interdiction de SSH 1, SSH 2 n'étant pas forçément géré par tous les clients.
Question de choix donc, à définir selon le compromis sécurité/flexibilité que l'on estime devoir mettre en place.
Pour la mise en pratique, d'abord s'assurer que l'on dispose d'une version SSH suffisamment récente, capable de gérer les 2 protocoles :
ssh -V OpenSSH_2.9, SSH protocols 1.5/2.0, OpenSSL 0x0090600f
C'est bon :)
Puis éditer /etc/sshd_config et commenter/décommenter/modifier les lignes suivantes :
Protocol 2 PasswordAuthentication no RSAAuthentication yes
Relancer sshd :
kill -HUP `pidof sshd`
Générer une clé RSA 2 (coté client) :
ssh-keygen -t rsa
SSH crée alors une clé publique et une clé privée, respectivement nommées id_rsa.pub et id_rsa (contre identity.pub et identity pour les clés ssh version 1)
Autoriser cette clé (coté serveur), dans le home directory du compte auquel on souhaite autoriser l'accès :
cat id_rsa.pub >> ~/.ssh/authorized_keys2
Où id_rsa.pub est évidemment la clé générée coté client.
On peut ensuite, coté client, enregistrer une fois pour toutes cette clé de manière à pouvoir se connecter sans taper directement son mot de passe :
ssh-agent /bin/monshell ssh-add .ssh/id_rsa [taper son mot de passe] ssh -C -l compte_autorisé serveur
Le démon DHCPd fait partie du système de base, il n'y a donc normallement rien à installer, simplement se configurer un petit /etc/dhcpd.conf et activer le service au démarrage :
# /etc/dhcpd.conf
# DHCP server options.
shared-network LOCAL-NET {
option domain-name "thessalie.net";
option domain-name-servers 192.168.10.1, 62.4.16.70, 62.4.16.80;
subnet 192.168.10.0 netmask 255.255.255.0 {
option routers 192.168.10.1;
range 192.168.10.7 192.168.10.10;
group {
host vega {
hardware ethernet 00:30:70:02:E8:9D;
fixed-address 192.168.10.4;
}
host andromede {
hardware ethernet 0:90:65:3B:0B:E5;
fixed-address 192.168.10.3;
}
}
}
}
...
Il s'agit ici d'un petit réseau personnel, les invités auront une adresse
comprise entre 192.168.10.7 et 192.168.10.10 (les premières étant réservées aux
hôtes identifiés par leur MAC address, très utiles pour définir les règles PF).
Le serveur de nom, et routeur par défaut, est la machine 192.168.10.1, nom de
domaine thessalie.net. On peut également y spécifier des DNS externes.
Le premier sous réseau ne comprend que le modem adsl :)
Reste à lancer le démon au démarrage (rc.conf) avec l'option ``-q''pour éviter l'affichage des messages de lancement.
# /etc/rc.conf dhcpd_flags="-q" # for normal use: "-q"
Installer ntpd : cd /usr/ports/net/ntp/ && make && make install
#/etc/rc.conf ntpd=YES # run ntpd if it exists #/etc/ntp.conf server rackety.udel.edu server barnstable.udel.edu server mizbeaver.udel.edu restrict 127.0.0.1 restrict 128.4.1.1 nomodify restrict 128.4.1.4 nomodify restrict 128.4.1.2 nomodify restrict 192.168.10.0 mask 255.255.255.0 nomodify restrict default ignore driftfile /var/ntp/ntp.drift statsdir /var/ntp/ntpstats filegen peerstats file peerstats type month enable filegen loopstats file peerstats type month enable filegen clockstats file peerstats type month enable
1ere synchronisation : s'assurer que les règles autorisent les requetes NTP en UDP, et taper:
# ntpdate rackety.udel.edu # /usr/local/sbin/ntpd -p /var/run/ntpd.pid
Pour les postes clients du réseau interne, simplement installer ntpdate et le coller dans sa crontab, par exemple :
30 * * * * /usr/sbin/ntpdate 192.168.10.1
Il faut biensûr que le firewall autorise explicitement les requêtes NTP (au moins en UDP et via l'interface interne) :
pass in log quick on $Int proto udp from $IntNet to any port ntp keep state
Où $Int = interface interne, et $IntNet = réseau interne, ici 192.168.10.0/24.
Rien de plus simple, juste suivre les consignes. En 3.*, en installant le package postfix, ces consignes sont les suivantes et elles fonctionnent parfaitement :
Configurer ensuite /etc/postfix/main.cf comme d'hab.