Ssh

SSH Chroot

On peut avoir facilement un user chroot en ssh / sftp. Rajouter dans le fichier /etc/ssh/sshd_config

# Si openssh est compilé via les sources
Subsystem       sftp    /opt/applis/openssh/libexec/sftp-server
# Si openssh est la version package de l'OS :
# Subsystem sftp internal-sftp

Match user sogec1  # On est obligé de spécifier le user ici, on ne peut pas mettre %u
         ChrootDirectory /opt/data/in/%u
         X11Forwarding no
         AllowTcpForwarding no
         ForceCommand internal-sftp

Ou alors avec un group

Match group sftpweb
        ChrootDirectory /opt/data/in/%u
        X11Forwarding no
        AllowTcpForwarding no
        ForceCommand internal-sftp

Creer un groupe sftpweb (optionnel)

mkdir /opt/data/in

# Le user qui sera chrooté  :
mkdir /opt/data/in/$login (ici mkdir /opt/data/in/sogec1)
useradd -d /opt/data/in/$login/$login -m -s /sbin/nologin -g sftpweb $login (ici useradd -d /opt/data/in/sogec1/sogec1 -m -s /sbin/nologin sogec1)

/!\ Ne pas oublier après de modifier le home du user avec vipw (Pour que le user arrive bien directement dans son repertoire final /opt/data/in/sogec1/sogec1), sinon si on ne modifie
pas on arrivera dans opt/data/in/sogec1

vipw : sogec1:x:503:503::/sogec1:/sbin/nologin

chown -R $login:daemon /opt/data/in/$login/$login (dans notre exemple chown sogec1:daemon /opt/data/in/sogec1/sogec1)

chown root:$groupuser /opt/data/in/$login (ici chown root:sogec1 /opt/data/in/sogec1)

passwd $login

/opt/data/in/sogec1 doit appartenir à root:$user pour que le chroot fonctionne, c est pour ca qu il faut creer un autre repertoire qui appartient au user (/opt/data/in/sogec1/sogec1).

• Le répertoire /opt/data/in a les propriétés suivantes :

drwxr-xr-x 8 root root 4096 Jul 2 14:12 /opt/data/in /!\ Se mettre dans /opt/data/in, et faire un ls -la, s'assurer que le répertoire "." soit bien en 755 et pas en 777

• Le répertoire /opt/data/in/sogec1 a les propriétés suivantes :

drwxr-x--- 3 root sogec1 4096 Jul 5 14:21 /opt/data/in/sogec1

• Le répertoire /opt/data/in/sogec1/sogec1 a les propriétés suivantes (ici le group est daemon pour que apache puisse lire ce qu il y a dedans)

drwxr-xr-x 2 sogec1 daemon 4096 Jul 5 14:39 /opt/data/in/sogec1/sogec1

http://www.debian-administration.org/articles/590

SSH sans mot de passe

Générer sur le serveur local les clés ssh (ssh-keygen -t rsa), copier le contenu de /home/user1/.ssh/id_rsa.pub sur le serveur distant dans /home/user2/.ssh/autorized_keys
(cat ~/.ssh/id_rsa.pub | ssh user@machine "cat - >> ~/.ssh/authorized_keys"). Sinon on peut utiliser la commande ssh-copy-id -i ~/.ssh/id_rsa.pub user@machine
Puis depuis le serveur local ssh user2@w.x.y.z ; la connexion se fera dans demander de mot de passe.

SSH avec restriction de commande

1er cas

Sur le serveur où l'on veut faire la restriction, rajouter dans le .ssh/autorized_keys :
from="w.x.y.z/a",no-X11-forwarding,no-agent-forwarding,no-pty,command="..." ssh-rsa AAAAB3NzaC1yc2EAAAABIwAA...."
On peut autoriser cette clé publique que pour l'ip w.x.y.z et la commande suivante.

2ème cas

Si le user ne doit faire que du sftp/scp & rsync, installer rssh (lui mettre comme shell rssh) et dans /etc/rssh.conf :
allowscp
allowsftp
allowrsync

Rsync over ssh

Commande de base

rsync -avzn -e ssh tof benbis@w.x.y.z:/home/benbis/ (le -n permet de simuler)

Cela va copier le répertoire tof local dans le répertoire /home/benbis/ distant via ssh. Cela évite de faire un scp et d'avoir le daemon rsync qui tourne sur le serveur distant 
(rsync doit bien sur être installé sur le serveur distant)

Rsync over ssh secure

Permet d executer un rsync dans un script bash lancé sous root, et que le rsync utilise le user vision ainsi que sa clé

# Serveur A
rsync -e 'ssh -F /home/vision/.ssh/ssh.conf' -a $DIR_TMP/* vision@admin1.so.apps.valeo.com:/opt/data/log/syslog/

cat /home/vision/.ssh/ssh.conf :
Host admin1.so.apps.valeo.com
        Hostname admin1.so.apps.valeo.com
        User vision
        IdentityFile /home/vision/.ssh/id_dsa (cela est la clé sur le serveur A)

# Serveur B
dans /home/vision/.ssh/authorized_keys doit se trouver le contenu de /home/vision/.ssh/id_dsa.pub du serveur A

Tunnel ssh

ssh -L <port_local>:<hote_cible>:<port_destination> user@server -pXX

	
ssh -L 9089:localhost:3389 xhark@109.238.2.200 -p443

Cela aura pour effet de rediriger toutes les requêtes tapant en local sur le port 9089 de votre machine vers le port 3389 de la machine distante. Dans cet exemple, il s’agit d’une
 connexion sur un serveur Windows ayant OpenSSH écoutant sur le port 443. Le but est de réaliser un tunnel SSH pour prendre le contrôle en bureau à distance (RDP) sur le port par 
défaut 3389.

Dans cet exemple on veut joindre le serveur https 10.0.1.1 qui ne peut etre join que via le serveur 212.43.194.1. On va donc effectuer cette commande en local, qui a pour but
d'ouvrir le port 8000 en local qui sera redirigé (comme un proxy) sur le port 443 de la 10.0.1.1 via le tunnel ssh via 212.43.194.1

#ssh -N -L 8000:10.0.1.1:443 benj@212.43.194.1

mettre sur sa machine en local dans le navigateur  https://localhost:8000

Tunnel SSH avec translation de port dynamique (dynamic forwarding) : ssh -D <port_local> <utilisateur>@<hote_cible> -pXX

	
ssh -D 8080 xhark@109.238.2.200 -p443
Dans cet exemple nous ouvrons un tunnel dynamique qui permettra de surfer à travers le tunnel SSH via un proxy de type Socks.

Tunnel ssh avec Putty

On peut aussi faire cela avec Putty pour se connecter à un vncserver qui tourne en local sur un serveur.

Sur le serveur on a en ecoute : 127.0.0.1:5900

Sur le poste client, on lance putty :
  - on va dans Connection / SSH / Tunnels
  - source port : 5900 / destination : ip_du_serveur:5900 et cliquer sur "Add"
  - Session : mettre l'ip du serveur et lancer la connexion ssh

Puis sur le poste client on lance vncviewer et on met comme adresse 127.0.0.1:5900. La connexion ssh doit etre lancée pour que le tunnel s'établisse, et que lorsqu'on lance vcnviewer 
sur 127.0.0.1:5900, il passe par le tunnel et nous connecte.

Tunnel ssh avec Putty & contournement de proxy

On est dans le cas ici, que nos ordinateurs ne peuvent sortir uniquement sur les ports 80 & 443, et doivent obligatoirement passer par le proxy de l'entreprise. La méthode ci-dessous
va nous permettre de faire du ssh sur notre serveur, et aussi de passer par notre proxy pour les navigateurs internet sans que nos requetes soient enregistrées dans le proxy de la 
société. On va aussi installer sslh qui permet de faire écouter le port 443 et de rediriger vers ssh ou vers apache suivant si c'est une connexion ssh ou https qui arrive.
Sur le serveur perso :
 - faire écouter ssh sur le port 80 ou 443 (pour faire une connexion ssh et un tunnel)& modifier apache en conséquence
 - installer un proxy qui écoute en localhost sur le port 8888 (par exemple)

Dans putty :
 - connexion / proxy : mettre le "proxy type" sur http, et renseignerl ip / port du proxy agarik
 - connexion / ssh / tunnel : source port 8888 / Destination 127.0.0.1:8888

Puis dans son navigateur lui mettre comme proxy 127.0.0.1:8888

Sftp

Si on veut faire du scp / sftp uniquement, il faut verifier que dans sshd_config on ait bien une ligne avec "/usr/lib/openssh/sftp-server" (ou un autre path vers sftp-server).
On rajoute alors ce path complet dans /etc/shell, et on donne ce shell au user qui veut faire du scp / sftp

Forward X11

On peut avoir besoin d'avoir un export de display (via putty : activer dans "connexion / ssh / x11 / enable x11 forwarding" ; ou via ssh -Y), il faut installer sur le serveur linux les packages suivant : libaio-devel.x86_64 libaio.x86_64 sysstat.x86_64 glibc-devel.x86_64 compat-glibc.i386 glibc-devel.i386 compat-libstdc++-33-3.2.3-61 compat-libgcc-296-2.96-138 compat-libstdc++-296-2.96-138 xorg-x11-xauth.x86_64 libXp.i386 libXt.i386 libXtst.i386

ssh_config : ForwardX11 yes
sshd_config : X11Forwarding yes & X11DisplayOffset 10

Il n'est pas nécessaire de faire des export display, xhost +x

Upgrade de version

Cette doc concerne un upgrade de version lorsque openssh est installé via les sources

Dans cette manipulation, on ne perd pas la main sur le serveur même lorsque l'on arrete le service sshs (notre connexion ssh est forké et est en mémoire). Si sshd ne se relance pas, 
il faut vérifier que /etc/sysconfig/sshd ne contienne pas le lien en dur vers l'ancienne version. Il faudra se déconnecter après tout ca, car notre connexion continue d'utiliser 
l'ancienne version de ssh

# tar zxf openssh-6.2p2.tar.gz
# cd openssh-6.2p2
#./configure --prefix=/opt/applis/openssh-6.2p2-1 --with-privsep-user=sshd --with-md5-passwords --with-ssl-dir=/opt/applis/openssl --with-libs="-ldl"
# make & make install
# Copie des conf et des cles
# cp -r /opt/applis/openssh/ssh_host_* /opt/applis/openssh-6.2p2-1/
# cp -r /opt/applis/openssh/etc/ssh_* /opt/applis/openssh-6.2p2-1/etc/
# /etc/init.d/sshd stop
# rm -f /opt/applis/openssh (lien sympbolique)
# ln -s /opt/applis/openssh-6.2p2-1 /opt/applis/openssh
# /etc/init.d/sshd start
# rm -rf /opt/applis/openssh-oldversion

SSH regénération des clés

Si l'on veut regénérer les clés suite à un clonage ou une autre version, supprimer tous les ssh_host_* présents dans /etc (ou dans /opt/applis/openssh/etc & /opt/applis/openssh),
puis faire un ssh-keygen -A (cela va générer tous les types de clés : rsa, dsa...) et faire un restart de ssh pour finir de générer les clés.
!!! Attention, une fois les clés supprimées, il ne faut pas fermer la session avant de regénerer les nouvelles clés, car on ne peut plus se logguer en ssh !!!