Outils pour utilisateurs

Outils du site


Panneau latéral

Tips

Divers

Projets

Ham Radio

Machines

Research

Privé

Études

projets:reversessh

Connexion en reverse SSH

Problème

Pour se connecter depuis l'extérieur (mudrublic) vers vega, on est forcé de se connecter sur epsilon, qui redirige la connection SSH vers vega. Il est possible de forwarder des ports depuis epsilon, mais pas de placer une clé dans les authorized_hosts, donc pas de connection automatique…

Pour palier à ce problème, on va faire la connection dans l'autre sens et demander à vega de se connecter à mudrublic.

Solution

Vega

On se connecte en forwardant le port ssh local par lequel la connection en retour passera, établissant les tunnels nécessaires.

Le script dig.sh permet de gérer (ouverture, réouverture, fermeture) le tunnel.

#!/usr/local/bin/bash
REPORTADDR=shtrom@ssji.net
USERHOST=tunnel@tunnels.narf.ssji.net
REMOTEPORT=1337
PIDFILE=/tmp/dig.pid
 
if [ -e ${PIDFILE} ]; then
        if [ "$1" = "-k" ]; then
                echo "Killing tunnel process"
                kill `cat ${PIDFILE}`
                rm ${PIDFILE}
                exit 0
        elif ps -u olmehani | grep `cat $PIDFILE` | grep -q ssh; then
                exit 0
        fi
fi
 
ssh -nT -R${REMOTEPORT}:localhost:22 ${USERHOST} &
echo $! > $PIDFILE
 
mail ${REPORTADDR} << EOF
To: ${REPORTADDR}
Subject: Tunnel (re)openned
 
The vega part of the tunnel has been reopenned:
${USERHOST}
${REMOTEPORT}
PID: `cat ${PIDFILE}`
`date`
EOF

muDrublic

Un utilisateur “tunnel” sert à recevoir la connection depuis vega et ouvrir les tunnels appropriés. Son script de login ne fera rien d'autre qu'ouvrir les tunnels, et surtout ne présentera pas de session interactive.

D'abord on le crée (avec un mot de passe invalide pour interdir la connection autrement que par clef SSH).

$ sudo adduser

Puis on lui génère sa clef RSA sans passphrase.

$ sudo -u tunnel ssh-genkey -t rsa

Un petit script va lui servir de shell, tunnelvega.sh

#!/bin/sh
REPORTADDR=shtrom@ssji.net
 
mail -s "Tunnel (re)openned" ${REPORTADDR} << EOF
 
The mudrublic part of the tunnel has been reopenned:
`date`
EOF
 
exec ssh -gNTx -L3128:sigma.utc.fr:3128 -L2222:vega.utc.fr:22 olmehani@localhost -p 1337
$ sudo chsh tunnel

Soit au final dans le master.passwd:

tunnel:*:1000:1000::0:0:Tunnel User:/home/tunnel:/home/tunnel/tunnelvega.sh

Petit warning

OpenBSD checke quotidiennement le master.passwd et détecte un truc qui le dérange:

From root@mudrublic.narf.ssji.net Sun Feb 26 01:33:42 2006
From: Charlie Root <root@mudrublic.narf.ssji.net>
To: root@mudrublic.narf.ssji.net
Subject: mudrublic.narf.ssji.net daily insecurity output

            
Checking the /etc/master.passwd file:
Login tunnel is off but still has a valid shell and alternate access files in
         home directory are still readable.

Échange de clefs

On autorise les users respectifs à se connecter aux comptes en utilisant leur clef RSA.

vega$ cat tunnel_mudrublic_rsa.pub >> ~/.ssh/authorized_hosts
mudrublic# cat olmehani_vega_rsa.pub >> ~tunnel/.ssh/authorized_hosts

Maintien de la connection

Un cron

Dans le crontab sur vega

5,20,35,50 * * * *     /users/olmehani/bin/dig.sh

Réouverture sur réception d'un mail

:!: NotSoClean™ inside :!:

Un mail particulier à l'utilisateur sur vega demande la réouverture du tunnel. Afin de limiter au maximum les risques de hijacking, aucun paramètre n'est passé avec la demande, et l'ouverture par défaut du tunnel est faite.

Dans le .procmailrc sur vega:

:0
* ^X-Action: DigThisHole$
| /users/olmehani/bin/dig.sh

Et un rapide script demandant l'ouverture par mail:

#/bin/sh
#ssh -Nfg -L 3128:proxyweb.utc.fr:3128 olmehani@epsilon.utc.fr
/usr/sbin/sendmail olmehani@etu.utc.fr << EOF
To: olmehani@etu.utc.fr
Subject: automatic mail
X-Action: DigThisHole
 
EOF
projets/reversessh.txt · Dernière modification: 2013-11-15 05:06 (modification externe)