Hints

ssh -q -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no user@hostname/IP-address

var d'env

  • Dans certains cas l'env de l'user ne se chargera pas comme on l'attend, donc :
  • Au niveau Serveur

cat <<EOF >> /etc/ssh/sshd_config
# Load User environment file ~/.ssh/environment
PermitUserEnvironment yes
EOF

  • Au niveau user

cat <<END >>~/.ssh/environment
PATH=~/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
END

ssh-agent

Gestion des sessions ssh

  • Pour finir la session ssh-agent:
    • ssh-add -D
    • ssh-add -t 36000 (merci Arnaud)
    • keychain (merci Pascal)

cat ~/.profile
keychain --agents ssh -Q -q --timeout 40 id_rsa ...
[ -f $HOME/.keychain/$HOSTNAME-sh ] && . $HOME/.keychain/$HOSTNAME-sh
et un script à lancer régulièrement :
#!/bin/ksh
# $Id: key,v 1.12 2011/07/26 15:15:24 pc Exp $
IFS="^M"
export IFS 
pc_key=${HOME}/.ssh/id_rsa

keys=$(ssh-add -l)
echo ${keys} |egrep "${pc_key}\>" > /dev/null
if [[ $? -eq 1 ]]; then
  echo "Chargement de la clef $pc_key pour 1200s (20mn) :"
  ssh-add -t 1200 ${pc_key}
  ssh-add -l
else
  echo "La clef ${pc_key} est chargée ; clef(s) actuellement chargée(s) :"
  echo ${keys}
fi
Pour utiliser avec X11, il faut comprendre que ssh-agent(1) doit propager les variables d'environnement (aux processus fils) ⇒ renommez vos .xsession en .SessionX et remplacez par :
$ cat .xsession
exec ssh-agent /users/pc/.SessionX
ssh-agent -k
$ .SessionX
...
SSH_ASKPASS=/usr/pkg/bin/x11-ssh-askpass
export SSH_ASKPASS
...
eval 'keychain -Q -q --timeout 40 $HOME/.ssh/id_rsa'
. $HOME/.keychain/${HOST}-sh
...

Ssh clef Forwarding

  • SSH fait de l'agent forwarding avec l'option -A
    • ainsi on peut rebondir sans avoir à placer la clef (ssh-agent doit etre lancé sur son poste)
    • ATTENTION: toute personne pouvant lire votre fichier d'“auth sock” peut utiliser votre tunnel pour s'authentifier à votre place.
      • il lui suffit de cfg la var d'env SSH_AUTH_SOCK (par defaut: /tmp/ssh-XXXXXXX/agent.PID) sur votre sock… (merci Adrien)

Qui c'est connecte avec une clef ssh

Bon, j'avais le besoin de savoir quelle clef avait été utilisée pour se loguer sur un serveur et donc d'avoir un peu plus d'informations…

Dans les faits il y a des infos dans le /var/log/auth.log mais… ce n'est pas amusant pour recouper avec la clef publique utilisée…

Voici donc ce que j'ai commis :

#!/bin/bash


grep ": Accepted publickey for " /var/log/auth.log | tr -s "\t " " " | cut -d" " -f1-4,9,11,13,15,16 | while read d1 d2 d3 d4 login ip port rsa cles
    do
    holo=$(getent passwd $login | cut -d: -f6)
    grep -v "^#" $holo/.ssh/authorized_keys | sed -s "s/.*\(ssh-.*\)/\1/g" | sort -u | ssh-keygen -lf - | while read null clef com
        do
            if [ "$cles" = "$clef" ]; then
                echo $d1 $d2 $d3 $d4: $login $ip:$port $com
            fi
        done
    done

Et ça rend à peu près ça

Jun 4 09:24:0 2 wurzel: adlp 10.a.b.c:55156 adlp@TAFF (RSA)
Jun 5 08:50:22 wurzel: adlp w.x.y.z:55918 adlp@TAFF (RSA)
Jun 5 13:50:26 wurzel: adlp 10.a.b.c:46410 adlp@TAFF (RSA)
Jun 6 08:27:54 wurzel: adlp w.x.y.z:48496 adlp@TAFF (RSA)

Limiter les ayants droits

Authorisation par groupes

La methode la plus simple consiste a creer un groupe (client-ssh), et y mettre les utilisateurs qui auront le droit de faire du ssh

Et modifier ainsi le /etc/ssh/sshd_config

AllowGroups client-ssh

Authorisation par groupes, la suite

Dans certains cas on peut avoir besoin d'accorder des autorisations distinctes en fonction du reseau de provenance, et qui plus est etre plus restrictif vis a vis de l'Internet.

Cas concret: Autoriser le scp pour certains users coté Internet, et autoriser coter LAN le shell

A savoir:

  1. Par defaut on essaye d'etre restrictif, puis on ouvre
  2. Il est autement recommandé que les users scp aient le droit de faire du ssh…
  3. Les configuration sont lut sequentiellement par le ssh
  4. Sequentiellement, mais cumulable…

AllowGroups client-ssh

ChrootDirectory /tmp
AllowAgentForwarding no
AllowTcpForwarding no
Banner no
MaxAuthTries 2
PermitEmptyPasswords no
X11Forwarding no


Match Address 10.0.0.0/8,192.168.0.0/16,172.16.0.0/12,127.0.0.1/32
    ChrootDirectory none
    AllowAgentForwarding yes
    AllowTcpForwarding yes
    X11Forwarding yes

Match Group client-scp
    ChrootDirectory none
    ForceCommand internal-sftp
    AllowAgentForwarding no
    AllowTcpForwarding no
    X11Forwarding no

Etre plus specifique sur une clef

Ainsi on pourra specifier les commandes authorisés, les origines de cnx…

Exemple (issue de la man page quand meme…)

# Comments allowed at start of line
ssh-rsa AAAAB3Nza...LiPk== user@example.net
from="*.sales.example.net,!pc.sales.example.net" ssh-rsa AAAAB2...19Q== john@example.net
command="dump /home",no-pty,no-port-forwarding ssh-dss AAAAC3...51R== example.net
permitopen="192.0.2.1:80",permitopen="192.0.2.2:25" ssh-dss AAAAB5...21S==
tunnel="0",command="sh /etc/netstart tun0" ssh-rsa AAAA...== jane@example.net

FIXME exemple a reprendre d'un truc deja mis en prod… (merci Pascal)

En voilà un pour rebondir depuis une passerelle :

command="/bin/sh -c '/usr/bin/ssh -l pc internal ${SSH_ORIGINAL_COMMAND}'" ssh-rsa AAA...
En voici un autre pour SVN :
command="/usr/pkg/bin/svnserve -t --tunnel-user=pc -r $HOME/depot\"$@\"",no-port-forwarding,no-X11-forwarding,no-pty ssh-rsa AAAAB...

Chrooter les ayants droits

Voir aussi ce que sait faire rssh (merci Pascal)

Ici seront chrootés les users du groupe www-users

Cfg sshd

Toujours dans /etc/ssh/sshd_config, rajouter :

Match Group www-users
    ChrootDirectory %h
#    ForceCommand internal-sftp
    AllowTcpForwarding no
NB: on peut reproduire cette conf a plusieurs reprise..

Cfg user

FIXME: En gros il faut une buzybox avec les liens adequates + si prg supplementaires, ne pas oublier de faire des ldd dessus…

Creation de l'environement chrooté

NB: c'est tout de meme plus simple que le “ChrootDirectory” pointe vers un meme repertoire pour tout les utilisateurs…

Le Script ci-joint a pour objectif de valider:

  • Que les lib necessaire au bon fonctionnement des binaires positionnés dans le chroot sont là
  • Qu'il n'y a pas de lib en trop
  • Que les lib et binnaires soient à jour par rapport a ceux accessibles dans le $PATH de la machine

#!/bin/bash

REPCHROOT=/home-chroot

# Objectif
#   .Verifier qu'il y a toutes les libs
#   .Verifier que les lib et les binnaires sont uptodate
# Evidement, signalera des erreures sur les cas particuliers
#   Fichiers speciaux pr le chroot


TMP=/tmp/vert-$$
find $REPCHROOT/lib/  -maxdepth 1 -type f | sort | while read lib ;do basename $lib; done | tr -s "\n" " " >$TMP

find $REPCHROOT/bin/ -type f -exec ldd '{}' \; | awk '{ print $3 }' | grep lib | sort | uniq | while read lib
do
        BNL=`basename $lib`
        sed -i "s/$BNL//g" $TMP

        if [ -e $REPCHROOT$lib ]; then
                NBL=`md5sum $REPCHROOT$lib $lib | awk '{ print $1 }' | uniq | wc -l`
                if [ $NBL -eq 1 ]; then
                        echo OK:$lib::md5sum $REPCHROOT$lib $lib
                else
                        echo KO:$lib:not uptodate:md5sum $REPCHROOT$lib $lib
                fi
        else
                echo KO:$lib:not here
        fi
done

sed -i "s/ //g" $TMP

if [ -s $TMP ]; then
        echo NOK:too much lib in chroot:`cat $TMP`
else
        echo OK:lib are just fine
fi
rm $TMP

find $REPCHROOT/bin/ -type f | while read bin
do
        BNF=`basename $bin`
        CHC=`which $BNF`
        if [ ! -z "$CHC" ]; then
                NBL=`md5sum $bin $CHC | awk '{ print $1 }' | uniq | wc -l`
                if [ $NBL -eq 1 ]; then
                        echo OK:$bin:md5sum $bin $CHC
                else
                        echo KO:$bin not uptodate:md5sum $bin $CHC
                fi
        else
                echo KO:$bin:not here
        fi
done

Le Umask et le ssh

Anciennement

On edite le fichier /etc/pam.d/sshd: et on rajoute ca :

# Setting UMASK for all ssh based connections (ssh, sftp, scp)
session    optional     pam_umask.so umask=0027

NB apres, si on est joueur on eut faire ca :

sudo chfn -o "umask=002" daemon_username

Et maintenant

Pour faire uniquement du sftp… chrooté avec positionnement de umask, on peut désormais faire plus simple : http://en.wikibooks.org/wiki/OpenSSH/Cookbook/SFTP

A noter que si l'on utilise pas la solution de chroot intégrée évoquée ici, il faut ajouter le device log du chroot au niveau de la config de son syslog préféré si on veut avoir un peu de logs ;-) (merci à Jean-Yves)

Les Tunnels

Report de port

ssh -L 8080:localhost:80 utilisateur@serveurdistant
Cela permettra de faire apparaitre sur le port 8080 de la machine local le port 80 de la machine “serveur distant”

Le revert tunnel

AllowTcpForwarding yes
distant$ ssh -NR 22222:localhost:22 user@local
local$ ssh -p 22222 user@127.0.0.1
# autossh -i /path/to/privateKey.rsa -NR 22222:localhost:22 user@local

Machine Cachée derriere le FW

Initialisation

  • Configuration du sshd : AllowTcpForwarding yes
  • Generation de la clef

Pas besoin de refaire une lecon : ssh-keygen….

  • Copie de la clef

Utiliser ssh-copyid, en precisant la meme syntax que celle appelée par la suite, ici rebond@rebond.adlp.org

  • Test

ssh -NR 22000:localhost:22 rebond@rebond.adlp.org

Automatisation

  • Creation du fichier /etc/init/autossh.conf

# autossh - tunnel
#
# This service maintain a ssh tunnel to the maintenance center

start on stopped rc RUNLEVEL=[2345] and (
            not-container or
            container CONTAINER=lxc or
            container CONTAINER=lxc-libvirt)

stop on runlevel [!2345]

respawn
exec /bin/su - rebond -c "/usr/bin/autossh -i /home/rebond/.ssh/id_rsa -NR 22000:localhost:22 rebond@rebond.adlp.org"

Machine de rebond

local$ ssh -p 22000 user@127.0.0.1

Les tunnels socks

SshFs

Montage

sshfs user@machine.distante:MesDocuments/Video ~/MesDocuments/Video
Si le user distant a un uid different du local, est recommandé cela :
sshfs -o uid=xxxx -o gid=yyyy [user@]host:[dir] mountpoint [options]

Démontage

fusauto ~/MesDocuments/Video

docs/linuxeries/ssh.txt · Dernière modification: 2023/06/06 18:25 (édition externe)
Recent changes RSS feed Debian Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki