proxy ssh

Il arrive souvent que les machines d’un réseau de développement  ne soit pas accessibles depuis l’extérieur à l’exception d’une machine jouant le rôle de porte d’entrée (frontdoor.mydomain.com).

Pour accéder depuis l’extérieur aux machines internes on établit depuis son poste externe une première connexion ssh avec  frontdoor.mydomain.com puis, de là, on établit une seconde connexion ssh vers la machine interne sur laquelle on veut travailler. Donc une opération en deux temps.

On peut simplifier ceci en établissant des ‘tunnels’ entre le frontdoor et les machines internes qui vont faire en sorte qu’une connexion sur le port 8001 du frontdoor donne directement accès à dev1, qu’une connexion sur le port 8002 du frontdoor donne directement accès à dev2 etc…

On établit donc un tunnel entre le port 8001 du frontdoor et le port 22 de dev,
puis un tunnel entre le port 8002 du frontdoor et le port 22 de dev2 etc…

Pour cela on se connecte sur le frontdoor et on exécute par exemple ces 2  commandes pour établir deux tunnels :

ssh -N -f -L 8001:localhost:22 devusr1@dev1.mydomain.com

ssh -N -f -L 8002:localhost:22 devusr2@dev2.mydomain.com

Chaque commande va  demander le mot passe pour se connecter  avec le user voulu à la machine interne qui sera l’extrémité ‘22’ du tunnel. Si la clé publique du user de frontdoor  est acceptée par le devusr coté machine de développement aucun mot de passe n’est demandé.  (Cette possibilité est très utilise si on veut automatiser l’établissement et la supervision de ces tunnels)

Ceci fait on peut fermer la session avec le frontdoor, les tunnels resteront actifs.

Maintenant, pour se connecter sur dev1 depuis l’extérieur on tape

    ssh –p 8001 usr@frontdoor.mydomaine.com

et bien sur la commande suivante vous loguera sur dev2

    ssh –p 8002 usr@frontdoor.mydomaine.com

La demande de mot de passe sera pour l'utilisateur 'usr' sur frontdoor. Là aussi on peut aussi utiliser un système de clés.

NOTE

Du point de vue de la machine interne (dev1 ou dev2) vous êtes un utilisateur connecté depuis 127.0.0.1 pas depuis frontdoor. Facile à vérifier avec la commande ‘who ‘

Il y a plein d'autre utilisations de cette technique du 'Local Port Forwarding'. Mais attention au firewall qui peut se trouver devant le frontdoor et qui pourrait bloquer l’accès aux ports d'entré du tunnel (8001, 8002 dans notre exemple)

Il y aussi des variantes de cette technique :

- Remote port forwarding (on établit le tunnel dans l'autre sens en utilisant ssh -R à la place de ssh -L)

- Dynamic port forwarding (plus complexe et nécessite la configuration SOCKS)

pg_hba.conf (part2)

(Dans la première partie on a vu comment configurer l'accès local à un serveur Postgresql)

Sachant que pour se connecter à distance (via le réseaux) à un serveur Postgresql il faut utiliser la commande
    psql -h host  database  username

On va essayer d’accéder à notre nouvelle installation de Postgresql se situant sur le serveur avec l'ip 192.168.0.3

> psql -h 192.168.0.3  postgres  postgres
psql: n'a pas pu se connecter au serveur : Connection refused
      Le serveur est-il actif sur l'hôte « 192.168.0.3 » 
      et accepte-t-il les connexions TCP/IP sur le port 5432 ?

Effectivement la première chose à faire est d’autoriser les connections venant du réseau.
Pour cela il faut éditer le fichier /var/lib/pgsql/data/postgresql.conf et y ajouter la ligne
    listen_addresses = '*'

puis redémarrer le serveur Postgresql
    systemctl restart postgresql

On ré-essaye :
    psql  -h 192.168.0.3  postgres  postgres
    psql: FATAL:  no pg_hba.conf entry for host "192.168.0.59",
    user "postgres", database "postgres", SSL off

Maintenant il faut autoriser les connections sur la base du triplet : (data-base, user, ip-client)

Pour faire simple on va ajouter cette ligne à pg_hba.conf
    host   all   all   all   md5
Ce qui signifie que s'il connait le password n'importe quel utilisateur de Postgresql peut se connecter à n'importe quelle base de données depuis n'importe où sur internet. C'est un peut trop ouvert !

En utilisant cette ligne
    host   all   all   samenet   md5
les clients devront être sur des machines du même réseau local que le serveur Postgresql.

En utilisant cette ligne
    host   sameuser   all   samenet   md5
Un user ne pourra se connecter qu'a la base de données qui porte son nom et seulement depuis une machine du réseau local. (config typique d'un environnement de développement dédié. Ne pas utilisé si le réseau local est trop ouvert, ni dans un environnement cloud)

En utilisant ces deux lignes en même temps
    host   webapp    webapp  w.x.y.z/32  md5
    host   sameuser  all     a.b.c.0/24  md5
Le serveur web situé à l'adresse w.x.y.z pourra se connecter à la base webapp avec le user webapp
et les développeurs du sous réseau a.b.c.0/24 pourront utiliser la base qui à le même nom que d'utilisateur.
Par exemple : postgres/postgres, webapp/webapp, webbackup/webbackup  jean/jean


Si vous avez pigez cela vous pigerez la petite doc qui se trouve au début du fichier pg_hba.conf

RAPPEL: Pour que les changements dans le fichier pg_hba.conf prennent effet il faut redémarrer le serveur Postgresl.

Info sur le codage md5 des mots de passe dans la table pg_shadow de Postgresql;
http://code18.blogspot.fr/2010/01/cracker-un-md5-de-postgresql.html




 

pg_hba.conf (part1)

Dans cette première partie on va voir comment sécuriser Postgresql  juste après son installation.


1) Vous venez donc d'installer Posgresql 9.x et voulez vous connectez en tapant psql.

> psql
psql: FATAL:  role "bidule" does not exist

En fait, en absence d'information, psql utilise le nom de l'utilisateur coté Unix et essaye de s'en servir pour se connecter à la base de données du même nom.

En fait, pour l'utilisateur 'bidule'
    > psql
est équivalant de
    > psql bidule bidule

Le premier 'bidule' est le nom de la base de données et le second le nom de l'utilisateur coté postgresql.


2) Dans toute installation par défaut de Postgresql il y a une base de données nommée postgres et un utilisateur nommé postgres. Donc ceci doit marcher :

> psql postgres postgres
psql (9.2.7)
Type "help" for help.

postgres=# _

Effectivement, on a bien le prompt du serveur Posgresql.


3) QUOI ?! Pas besoin de mot de passe !!!
Incroyable : Sur la machine où s’exécute le serveur Postgresql aucun utilisateur local n'a besoin de mot de passe pour y accéder. Ceci est dû à cette ligne dans le fichier pg_hba.conf

    local   all   all  trust

Elle signifie qu'en 'local', toutes  les bases de données (premier 'all') sont accessibles par tous les utilisateurs (deuxième 'all') à qui l'OS a déjà fait confiance ('trust') en acceptant qu'ils se connectent sur la machine.

Bien sur ceci est un véritable problème sur une machine multi-utilisateurs.

Notez que cette méthode très libérale pose exactement les mêmes problèmes que le mot de passe par défaut connu de tout le monde ou que l'utilisateur par défaut sans mot de passe.


4) Les trois premières choses à faire sont, dans cet ordre :
- attribuer un password au user 'postgres'  (coté Postgresql, pas coté Unix)
- changer la ligne de pg_hba en: "local   all   all  md5"
- mettre en commentaire toute les autres lignes utilisant la méthode 'trust'

En remplaçant la méthode 'trust' par la méthode 'md5' on force tout utilisateur local à donner le mot de passe de l'utilisateur coté base de données. Encore faut-il qu'il en ait un...

4.1) Donc on se connecte à Posgresql avec:

    > psql postgres postgres

puis on tape ces deux commandes pour attribuer un mot de passe à l'utilisateur postgres :

    ALTER USER postgres WITH PASSWORD 'Secr3tPassW0rd';
    \q


4.2) Dans le fichier pg_hba on remplace sur la ligne local la methode 'trust' par 'md5'
et on met en commentaire les deux lignes host utilisant aussi trust
# host    all  all  127.0.0.1/32   trust
# host    all  all  ::1/128        trust
On sauve, puis on redémarre le serveur Postgresql :

    systemctl restart postgresql


4.3) Maintenant si on utilise la commande  psql on doit taper le mot de passe

    > psql postgres postgres
    Password for user postgres: xxxxxxxxxxxx
    psql (9.2.7)
    Type "help" for help.
   
    postgres=# _

Ouf !

Notez qu'en remettant la méthode d'authentification pour 'local' à 'trust' pour pourrez vous connecter à nouveau (en local) sans mot de passe, ce qui est bien pratique si vous l'avez oublié.

Ce qui signifie que le 'root' Unix a tous pouvoirs sur le serveur Postgresql puisque il peut outre passer l’authentification en modifiant le fichier pg_hba.conf

Passons à l’accès via le réseaux ...

Postgresql 9 + Centos 7

Un rapide mémo sur l'installation de Postgresql 9.x sur centos7 avec un PGDATA personnalisé.

1: Installer postgresql

yum install postgresql postgresql-server

2: Créer le home directory de postgresql

mkdir /home/postgres
chown postgres:postgres /home/postgres

3: Initialiser le repertoire où postgresql va stocker ses bases de données et autres meta-data

su postgres
cd
initdb /home/postgres/data
exit

4: Configuration systemd

Ce qui suit a pour but de ne pas modifier la version d'origine de  /usr/lib/systemd/system/postgresql.service

La solution proposé par postgresql est d'utiliser .include mais il faut savoir que cette méthode  est obsolète (https://lists.fedoraproject.org/pipermail/devel/2014-July/200804.html)

Créer le fichier  /etc/systemd/system/postgresql.service
avec ces 3 lignes (respectez la case)

.include /usr/lib/systemd/system/postgresql.service
[Service]
Environment=PGDATA=/home/postgres/data

Si nécessaire ajouter la ligne suivante pour aussi changer le port

Environment=PGPORT=2345

5: Démarrer le serveur postgresql à la main

systemctl daemon-reload                (important)

systemctl start postgresql

verifier les log

systemctl status postgresql

6: Si tout va bien activer le démarrage automatique

systemctl enable postgresql 

Reste à configurer /home/postgres/pg_hba.conf
Voir ces 3 posts:

• pg_hba (part1)  accès local avec/sans mot de passe
• pg_hba (part2)  accès via le réseau
• pg_hba + SSL   cryptage

7: Installer les extensions

yum install postgresql-contrib

Toutes les extensions vont dans /usr/share/pgsql/extension
Pour installer une extension (par exemple adminpack) dans une base il faut se se connecter à cette base avec le user postgres et taper

CREATE EXTENSION adminpack;



8: Installer les .h


yum install postgresql-devel

Necessaire si on veut compiler un driver pour perl php ruby etc...
Par exemple quand un programme d’installation a besoin de libpq-fe.h

APACHE 2.2 et Centos 7

Il y a de nombreuses raisons pour vouloir encore utiliser Apache 2.2 et de ne pas migrer vers Apache 2.4. L'une d'entre elles est l'utilisation de mod_perl2 qui ne fonctionne toujours pas correctement avec Apache 2.4.
Malheureusement l’installation d’Apache 2.2 sur centos 7 ne peut pas se faire avec yum car seule la version 2.4 est disponible. Voici comment procéder pour compiler Apache 2.2 et mod_perl2 sur centos 7 et mettre en place les fichiers nécessaires au  démarrage de httpd 2.2 avec systemctl (aka systemd).


1) Il faut avoir les outils de développements

yum group install "Development Tools"


2) Puis on va sur http://www.us.apache.org/dist/httpd/ et on repère la version la plus récente de httpd-2.2
puis on la télécharge et on la décompresse :

wget http://www.us.apache.org/dist/httpd/httpd-2.2.29.tar.gz
tar xvf httpd-2.2.29.tar.gz


On compile et installe apache 2.2.x
On utilise --prefix pour ne pas installer apache par dessus l’éventuelle version 'officielle'.

cd httpd-2.2.29
./configure --prefix=/path/to/apache22
make
make install

On démarre  apache (risque de conflit si une autre version utilise le port 80)

/path/to/apache22/bin/apachectl -k start

Et avec le browser ont doit avoir le classique « It works »


3) Pour compiler mod_perl et tester il y a plus de préparatifs ET une correction de bug:
(peut être certains des packages ci-dessous sont déjà sur votre machine)

yum install perl-ExtUtils-Embed
yum install perl-libwww-perl
yum install perl-CGI
yum install perl-Test-Simple
yum install perl-Linux-Pid
yum install expat
cd /usr/lib64
ln -s libexpat.so.1.x.0 libexpat.so.0

(Adaptez le version de libexpat à votre cas. Pour moi c'est 1.6.0)


4) On va sur http://apache.org/dist/perl/ repérer la dernière version de mod_perl2
puis on la télécharge et on la décompresse :

wget http://apache.org/dist/perl/mod_perl-2.0.8.tar.gz
tar xvf mod_perl-2.0.8.tar.gz
cd mod_perl-2.0.8

 
ATTENTION #1: Dans le fichier t/api/err_headers_out.t il faut remplacer à deux endroits:

     if defined HTTP::Headers->VERSION and HTTP::Headers->VERSION==6.00;
par
  if defined HTTP::Headers->VERSION and HTTP::Headers->VERSION>=6.00;

Enfin on peut exécuter la séquence standard :

perl Makefile.PL MP_APXS=/path/to/apache22/bin/apxs
make
make test
make install


NB: Le fait d'avoir installé apache 2.2.x dans un répertoire spécifique n'implique pas que toute la partie mod_perl aille aussi dans ce répertoire. Une partie ira dans apache/include et apache/module mais les modules perl iront dans /usr/local/lib64/perl5


5) Quand on compile soit même Apache on ne bénéficie pas des petits plus apportés par un package comme par exemple la mise en place du script de démarrage. Voici donc comment installer cela avec un Linux, comme centos os 7, qui utilise systemd (sytemctrl) à la place les scripts init.d. On va créer deux fichiers :

a) Le premier est /etc/sysconfig/httpd22 
Il sert à configurer l’environnement et les paramètres à passer au daemon httpd.

OPTIONS="-f /path/to/conf/httpd22.conf"
LANG=C


b) Le second /etc/systemd/system/httpd22.service
Il est utilisé par systemd pour exécuter les commandes start/reload/stop et il fait référence au fichier créé ci-dessus.

[Unit]
Description=The Apache HTTP Server 2.2.x
After=network.target remote-fs.target nss-lookup.target

[Service]
Type=simple
KillMode=none
PIDFile=/path/to/apache22/logs/httpd.pid


EnvironmentFile=/etc/sysconfig/httpd22

ExecStart=/path/to/apache22/bin/httpd  -DFOREGROUND  $OPTIONS
ExecStop=/path/to/apache22/bin/httpd   -k stop       $OPTIONS
ExecReload=/path/to/apache22/bin/httpd -k restart    $OPTIONS

[Install]
WantedBy=multi-user.target


NB: C'est apache qui gère le fichier .pid. Par défaut il est avec les logs de apache, mais on peut changer sa position avec la directive PidFile. Dans ce cas il faut adapter le PIDFile=... dans notre fichier httpd22.service


Après avoir créé ces deux fichiers (et avoir un fichier httpd.conf correct) faire

systemctl daemon-reload
systemctl start httpd22
systemctl status httpd22

Si tout est ok rendre le démarrage automatique

systemctl enable httpd22

Ces 2 fichiers cohabitent très bien avec ceux de httpd 2.4. Si les eux doivent s’exécuter en même temps il faut faire en sorte qu'ils n'utilisent pas le même port en changeant le paramètre "listen 80" dans la config de l'un ou de l'autre.

ATTENTION #2: Quand on se compile un programme (comme ici Apache 2.2) avec ses propres répertoires d'installation on se retrouve avec des fichiers .h ou des librairies à des endroits non standards. Ceci peut poser problèmes par la suite.

Par exemple, si pour utiliser mod_perl on veut installer la librairies Apache2::Request, qui utilise APR::Request, qui est une interface avec la librairie C libapreq2.so, il faudra que le programme d'installation de APR::Request trouve libapreq2.so dans le répertoire ou on a installé notre version d'Apache.

La solution la plus élégante est d'ajouter un fichier apache22.conf dans le répertoire /etc/ld.so.conf.d/ . Ce fichier contiendra juste une ligne du type:

/path/to/apache22/lib

Après quoi on exécute ldconfig pour que ce nouveau chemin soit pris en compte.


Enjoy  2.2 ;-)