Archives pour la catégorie Sécurité

ProxyJump: rebond automatique vers une machine non routée

Toto travaille sur sa machine pc-perso, il besoin de se connecter à une machine S2 située sur un autre LAN. Manque de pot,  S2 a une adresse IP privée et n’est donc pas accessible depuis Internet.

Toto ne veut pas utiliser le VPN propriétaire du LAN distant soumis au CloudAct et au PatriotAct … Pour ne rien arranger, ce VPN qui coûte un bras est aussi lent et instable que sa grand-mère en rollers !

Mais Toto a la chance d’avoir un accès SSH direct à la machine S1 qui a une patte sur le LAN distant (elle est joignable par une adresse IP publique).

Toto fait donc toutes ses opérations (SSH, scp, rsync, …) par rebonds: il se connecte d’abord à S1 puis  à S2 à partir de S1:

  • La clé publique de toto@pc-perso DOIT être installé sur le compte toto@s1
  • La clé publique toto@s1 DOIT être installés sur le compte toto@s2

Ce n’est pas très pratique pour Toto, surtout pour transférer des fichiers …

toto@pc-perso:~# ssh s1
Welcome to Ubuntu
You have new mail.
Last login: Sat Nov 26 17:05:22 2022 from xxxxxxxxxxxxx
toto@s1:~# ssh s2
Welcome to Debian
No mail.
toto@s2:~#

Un jour, Toto a ouvert la porte de son frigo et a vu la lumière: il a découvert la fonction ProxyJump d’OpenSSH !

Il s’agit d’une option qui permet de spécifier comment accéder à une machine en rebondissant par une autre:

  • Toto DOIT disposer d’un compte sur les deux machines (S1 et S2),
  • Toto DOIT disposer d’une clé SSH sur pc-perso,
  • La clé SSH publique toto@pc-perso DOIT être installée sur les machines (S1 et S2): Toto n’a plus besoin d’une clé publique toto@s1 pour accéder à toto@s2
toto@pc-perso:~# ssh -J s1 s2
Welcome to Debian
No mail.
Last login: Sat Nov 26 17:05:26 2022 from xxxxxxxx
toto@s2:~#

Il est possible de graver ce comportement dans le marbre pour se simplifier la vie: il ne sera plus nécessaire de préciser explicitement l’option de rebond, toutes les opérations (SSH, scp, rsync, …) se feront de façon transparentes entre pc-perso et S2. Il suffit de créer/éditer le fichier ~.ssh/config:

Host s2
 Hostname s2
 ProxyJump s1

Toto est content: il peut travailler sur S2 directement depuis pc-perso !

toto@pc-perso:~# ssh s2
Welcome to Debian
No mail.
Last login: Sat Nov 26 17:05:26 2022 from xxxxxxxx
toto@s2:~#

 

Patch RavadaVDI

Par défaut, le fichier généré par RavadaVDI n’embarque pas le mot de passe généré aléatoirement pour l’ouverture d’une session SPICE. De plus, la longueur du mot de passe (4 caractères) est beaucoup trop courte.

Le script suivant (ravada-patch.sh) permet de corriger ces deux problèmes sur RavadaVDI (version 1.8.0): il n’est plus nécessaire de saisir le mot de passe, sa longueur est portée à 16 caractères.

#!/bin/bash

dpkg -l patch >/dev/null 2>/dev/null || apt -y install patch

systemctl stop rvd_front.service
systemctl stop rvd_back.service

# Set spice passwords to 16 chars
files=$(grep -r "password = Ravada::Utils::random_name(4)" /usr/share/perl5/Ravada/* |grep password |awk '{print $1}' |cut -d: -f1)
for file in ${files} ; do
sed -i 's/password = Ravada::Utils::random_name(4)/password = Ravada::Utils::random_name(16)/g' ${file}
done

# Put spice passwords in ".vv" files, do no start viewer in fullscreen
[ -f Domain.pm.orig ] || cp /usr/share/perl5/Ravada/Domain.pm Domain.pm.orig
patch /usr/share/perl5/Ravada/Domain.pm Domain.pm.patch || cp Domain.pm.orig /usr/share/perl5/Ravada/Domain.pm

systemctl start rvd_back.service
systemctl start rvd_front.service

Le patch (Domain.pm.patch):

1861a1862,1863
> # Keep password for ".vv" file
> our $ppass="";
1864c1866,1868
< return $self->_data('spice_password');
---
> #return $self->_data('spice_password');
> our $ppass = $self->_data('spice_password');
> return $ppass;
1940c1944,1946
< $ret .="password=%s\n" if $self->spice_password();
---
> # Put password in ".vv" file
> #$ret .="password=%s\n" if $self->spice_password();
> $ret .="password=$ppass\n" if $self->spice_password();
1941a1948
> # Do not start in fullscreen
1943c1950
< "fullscreen=1\n"
---
> "fullscreen=0\n"

Avec Let’s Encrypt, vous n’avez plus d’excuses pour ne pas utiliser HTTPS !

Let’s Encrypt est un service qui permet d’obtenir des certificats TLS gratuitement. Bien évidemment, l’intérêt d’un tel service est que l’autorité qui signe les certificats est pré-enregistrée, donc connue des navigateurs et des systèmes d’exploitation.

Les certificats Let’s Encrypt sont donc:

  • reconnus par les systèmes d’exploitation,
  • reconnus par les navigateurs Web,
  • et reconnus par la plupart des logiciels.

Ce service est gratuit pour deux raisons:

  • il est porté par un consortium qui a compris que la généralisation de TLS permet d’apporter un peu plus de sécurité sur la toile,
  • la validation des certificats est entièrement automatique.

Les certificats ont une durée volontairement limitée (3 mois) pour inciter (disons plutôt obliger) les administrateurs à les renouveler régulièrement.