Best practice : Apache et SSH

Programmation
#1

Bonjour à tous,

J’ai un serveur qui sert de serveur web. Sur ce serveur tourne Apache, qui fait appel via le moteur wsgi à un projet Django. Dans ce projet Django, je me connecte en SSH à un serveur de calcul. Pour l’authentification, j’ai mis en place des clefs RSA. Les clefs RSA de l’utilisateur apache sont stockées dans /usr/share/https/.ssh, avec les droits classiques (700 sur .ssh et 600 sur id_rsa).
Est-ce sécurisé ? La clef privée étant accessible en lecture à httpd, on peut imaginer que la moindre faille dans le projet donne la possibilité de récupérer cette clef, et donc d’obtenir un accès au serveur de calcul.

Je peux protéger la clef par mot de passe, et indiquer ce mot de passe dans la configuration du projet Django. Mais ce priojet doit être accessible au moins en lecture à l’utilisateur apache, ça ne fait que déplacer le problème…

Une idée pour améliorer ça ?

#2

Hello,

On peut s’arranger pour que la clé privée soit sur une smartcard (en français, carte à puce ou carte SIM) et qu’elle ne quitte jamais la smartcard.

Un lien au hasard du web : http://florin.myip.org/blog/easy-multifactor-authentication-ssh-using-yubikey-neo-tokens

Que l’appareil soit en USB n’est pas grave. Insérer un token USB ou insérer une carte à puce, du moment que cela parle le même langage / protocole, c’est du pareil au même.

–
AnonymousCoward

#3

Pas mal du tout ! Je ne connaissais pas, merci pour l’info :slightly_smiling:

Par contre, dans mon cas, ça s’applique mal. Le serveur web en question est virtualisé, et trimballer d’un serveur physique à un autre. Sans compter que je n’ai pas d’accès physique à la machine. Par Best practice, j’entends plutôt meilleure utilisation des technologies logicielles standards.

#4

Fais un accès ssh en local à un client ssh qui n’ouvre ses connexions que sur localhost (via iptables) et qui permet de faire la connexion avec ton serveur de calcul

#5

Ça, j’aime bien comme solution. Merci :slightly_smiling:

#6

Si le serveur n’avait pas été du virtuel on aurait pu espérer se servir de l’éventuel TPM intégré. Mais là, effectivement, c’est cuit.

Ceci étant, vu le temps utilisé pour l’ouverture d’une session ssh, les alternatives suivantes sont-elles possibles ?

  • Réécrire le client/serveur afin d’utiliser SSL/TLS. Le serveur peut être planqué derrière le logiciel stud qui s’occuperait de la partie SSL. Le client, probablement en Python, pourrait utiliser pyopenssl. Une session SSL est en général bien plus rapide à établir.
    Et on peut carrément ne pas utiliser d’authentification du client au niveau SSL. Donc se passer de clé privée côté client.

  • Etablir à l’avance un VPN. Et installer un filtrage/pare-feu à l’extrémité du VPN côté ferme de calcul. Pas de temps perdu pour l’établissement de sessions chiffrées individuelles. L’usage de IPSEC semble tout à fait possible, également.
    Dans ce cas, les clés sont conservées par root ou autre et ne sont pas lisibles directement via Apache.

–
AnonymousCoward