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

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

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

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