suite de Zombie is not dead #1

La Secure SHell family apporte un protocole crypté et des outils bien adaptés pour administrer et gérer le contenu des serveurs distants. Une véritable invitation pour jeter vos services qui osent encore diffuser en clair : ftp, telnet, rsh, etc. et renvoyer, de fait, les sniffers sur PeyoLand.
Dans ce billet une connexion ssh entre un poste local et un distant :

- sans utiliser root ;
- sans password mais avec passphrase ;
- sans passer par le port 22 ;
- sans les mains pour croner devant les copains.

Portier, cryptez moi tout çà... et à l'occassion gimme the keys

Pour simplifier le présent billet, nous supposerons qu'un accès ssh est opérationnel sur le poste distant :

.-$ ssh foobar@remote.com
foobar$

En cas de problème, les options -v, -vv et -vvv sont inestimables...

La bonne pratique conseille de ne pas se connecter en root sur le serveur^[1]... Un utilisateur de base^[2] fera très bien l'affaire.

Pour automatiser l'authentification, ssh propose un système de cryptage asymétrique par clé privée/publique.

So... forgeons sur le poste local :

.-$ ssh-keygen -b 2048

Par défaut, c'est un couple de clés rsa qui vient de naître dans le dossier ~/.ssh du répertoire utilisateur.

 Q: Est-ce que la passphrase est obligatoire ? 
 R: OUI, sinon votre clé privée n'est pas protégée...

Sésame open toi

L'étape suivante consiste à placer la clé publique du poste local, dans un fichier ~/.ssh/authorized_keys2^[3] sur le poste distant.

Soit à la mano, soit via la commande :

.-$ ssh-copy-id -i ~/.ssh/id_rsa.pub foobar@remote.com

Si tutto va bene... vous pouvez désormais joindre le poste distant^[4] comme avant, mais plus besoin de password (fun), il devient juste nécessaire de saisir la passphrase (pas fun)...

Agent ssh, protégez moi de cette passphrase...

Les outils pour s'alléger de la passphrase sans trop compromettre la sécurité sont légions, pour se soigner : ssh-askpass, sshkeychain, pam_ssh, screen et ssh-agent, etc.^[5]

Sur ma machine locale, j'utilise juste ssh-agent et ssh-add (et un peu de screen...) pour n'avoir à cogner ma passphrase qu'une fois par reboot.

Le daemon ssh-agent permet de stocker la passphrase. Une fois lancée, la commande ssh-add communique la clé privée et la passphrase à l'agent.

ssh-agent

^[6]

Première galipette maison, à placer dans le ~/.bashrc :

.-$ vi ~/.bashrc
############################
# One passphrase by reboot #
############################

# to store agent data
sshConnect=".ssh-connect"

# load without errors
source $sshConnect 2> /dev/null

# retrieve agent name by pid 
processName=$(ps -x | grep $SSH_AGENT_PID | grep -v 'grep' | awk '{print $5}')

# no pid, no file... so create an agent
[[ ! -f $sshConnect || $processName != "ssh-agent" ]] && {
  ssh-agent | head -n 2 > $sshConnect 
  source $sshConnect
        ssh-add
}

Pas grand chose à dire... La 1ère connexion au terminal réclame la passphrase et jusqu'au prochain reboot silencio...

keychain

Ce daemon s'arrange pour ne laisser qu'un process ssh-agent... C'est, du coup, parfaitement adapté pour^[7] les tâches automatiques...

Pour exemple, sur un serveur de sauvegarde^[8] insérer les deux lignes suivantes dans le bash_profile :

backbar$ vi ~/.bash_profile
keychain ~/.ssh/id_rsa
source ~/.keychain/backup.com-sh

Et yop, tous les comptes peuvent faire la fête avec la ssh family, à condition d'insérer cette ligne en début de script...

source /home/backbar/.keychain/backup.com-sh

Gravons les tables de lois...

Ne reste plus qu'à configurer les fichiers de conf.

visudo

Pour pouvoir administrer à partir de l'utilisateur de base et uniquement à partir de lui, il faut adapter la configuration de /etc/sudoers sur le distant... pour l'éditer la commande visudo et rien d'autre :

foobar$ visudo

  foobar    remote.com = (ALL) ALL
  backbar  remote.com = NOPASSWD:/usr/bin/rsync

On ne fait pas dans la dentelle, foobar hérite en sudo de TOUT et pour backbar^[9] rsync sera même utilisable sans password... Il faudra affiner tout çà, mais c'est un début plutôt correct...

foobar$ sudo /usr/bin/foo_cmd
foobar$ sudo -s

À ma décharge, root n'est plus l'utilisateur indispensable pour administrer... D'ailleurs autant lui régler son compte :

foobar$ sudo passwd -l root

sshd_config

Au tour de sshd_config dans /etc ou /etc/ssh sur le distant :

foobar$ vi /etc/.../sshd_config

  Port 20109
  PasswordAuthentication no
  ChallengeResponseAuthentication no
  PermitRootLogin no
  Protocol 2

Cela pourrait constituer un minimum :

1. - Changement de connexion du port 22 vers port xxxxxx^[10]
2. - Accès par clés uniquement, password interdits.
3. - root ne peut plus se connecter en distant.
4. - man 5 sshd_config

... un supplément :

UsePrivilegeSeparation yes
  SyslogFacility AUTH
  LogLevel INFO
  StrictModes yes
  PrintLastLog yes

Yep...

foobar$ /etc/init.d/sshd reload

ssh_config

Sur le poste local, éditer le ssh_config pour améliorer le confort :

.-$ vi /etc/.../ssh_config
Host *
  VisualHostKey

Host remote
  HostName remote.com
  port 20109
  user foobar

backbar$vi /etc/.../ssh_config
Host remote
  HostName remote.com
  port 20109
  user backbar

Ce qui a pour effet de dégraisser nos lignes de commande :

.-$ ssh remote # eq. à  ssh -p 20109 foobar@remote.com
foobar$

On test un peu :

Comment va remote ?

.-$ ssh remote w

Petite modification, ultra-rapido dans un private pts

.-$ ssh -t remote vi /home/foobar/.bashrc

Air zinc, mon amour !!!

Dans la famille, le petit rsync est brillant !!! Du coup, scp prend un peu de poids...

Pour se faire la main :

backbar$ rsync -n -vaz /etc/  .

L'option -n permet de faire le boulot à blanc^[11].

Pour le reste, un bon début peut s'amorcer avec les options ci-dessous :

backbar$ rsync -vaz /home/PuC -e ssh  --rsync-path="sudo rsync" remote:/home/foobar

En gros verbeux, récursif, compressé avec les droits du local vers le distant... Yep man !

Un tip pas mal ~/.rsync/exclude^[12], et puis faut regarder --delete, --exclude, etc. qui devrait se terminer (ou commencer) par man rsync.

That's All

Un billeton fleuve pour un sujet pas bateau... En attendant la dernière part #3 sur chroot.

Et comme dirait Grégoire une machine sécurisée est une boite vide dans un endroit peu accessible... Pas la peine de demander aux Taïkonautes de déposer subrepticement votre serveur dans l'espace, j'ai déjà envoyé 3 tupperwares à l'agence Chinoise.

See ya !