• Pour pousser une clef, il y a la commande ssh-copy-id c'est plus simple
  • (cf droits'n co sur le ~/.ssh/authorized_keys)
  • ou http://www.ir.bbn.com/~gdt/ir-account/ (FreeBSD et NetBSD) et sa commande extract-account.
• Lors de la création d'une clef Ssh songer a utiliser le parametre -C avec la cmd ssh-keygen
• Un jour explorer le comportement du fichier ~.ssh/config
  • Cf http://www.admin-linux.fr/?p=323
• Pour jouer une commande sur plusieurs noeuds en meme tps : ClusterIt (merci Pascal)
• Un peu de port fowrding ssh -f user@domaine.tld -L 3128:Proxy:3128 -N
• Encore des infos… http://www.dbsysnet.com/restriction-des-commandes-ssh-sur-cles-publique-privee/
• Utiliser, avec putty un socks proxy https://www.digitalocean.com/community/tutorials/how-to-route-web-traffic-securely-without-a-vpn-using-a-socks-tunnel
• Lors de multiples reinstall, ne pas avoir a nettoyer le known_host, etc.

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

• 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

• 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 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)

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)

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

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

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

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...

Voir aussi ce que sait faire rssh (merci Pascal)

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

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..

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

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

• La bonne doc est la : How to setup ssh's umask for all type of connections
• Il suffit betement de suivre un truc qui est bien documenté dans la man page de pam_umask (avec un usage interessant du gecos)

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

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)

• http://openclassrooms.com/courses/mise-en-place-d-un-tunnel-tcp-ip-via-ssh

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”

• Copié collé a l'arrache d'un super site pour ne pas le perdre : http://geekfault.org/2011/02/19/reverse-ssh-acceder-a-un-serveur-derriere-un-natfirewall/

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

• 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

• 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"

local$ ssh -p 22000 user@127.0.0.1

• Important : c'est un repompage sans aucune honte d'un site que j'aime beaucoup : https://david.mercereau.info/autossh-tsocks-tunnel-socks-permanent/

• Doc Ubuntu sur le SshFS

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]

fusauto ~/MesDocuments/Video

STATUT DOCUMENT
Titre du document : Hints
Date de Création : 08-11-2011 11:11
Date de dernière édition : 06-06-2023 06:06
Statut du document : VALIDE
Validation par : Antoine Delaporte
le : 06-06-2023 06:06