Reusing SSH Connection

SOURCE : http://sshmenu.sourceforge.net/articles/transparent-mulithop.html

"The transparent multi-hop connections can be very useful but you may find that it takes a second or two to establish each connection. This delay can become annoying if it happens a lot (e.g.: every time you save a file from the text editor).
The good news is that if you can configure SSH to reuse an existing connection. This means that for example if you have an SSH shell session running then a new connection for SCP can skip the connection setup phase. Two steps are required:
First, you must create a directory (or 'folder') which SSH will use to keep track of established connections:

mkdir ~/.ssh/tmp

Next, add these two lines at the start of your ~/.ssh/config (make sure to use your username in place of 'YOUR-NAME'):

ControlMaster auto
ControlPath   /home/YOUR-NAME/.ssh/tmp/%h_%p_%r

As you can see, a small investment in time setting up your SSH configuration can pay back dividends in convenience."

svn + ssh on NetBSD

Problème : sur une machine uniquement accessible en ssh, je souhaite installer un serveur svn pour la gestion de version. Je souhaite avoir plusieurs utilisateurs. Ces utilisateurs doivent pouvoir faire des "checkout", des "commit", et autres opérations avec svn, mais ne doivent pas pouvoir se logguer sur le serveur pour autre chose que pour utiliser le serveur.

1ère étape :
Création d'un utilisateur svn qui sera celui utiliser pour se logguer sur le serveur.

1.1 Authentification par clefs publique/privée ssh

 Chaque utilisateur créé une clef ssh ( ssh-keygen ). Ajouter la clef publique générée dans ~/.ssh/authorized_keys

cat clef.pub > ~svn/.ssh/authorized_keys

Maintenant les utilisateurs peuvent se logguer directement en tant que l'utilisateur svn.

Allons voir un peu plus avant le contenu du fichier ~svn/.ssh/authorized_keys ...
Chaque ligne est indépendante, et de la la forme

  command="COMMAND" TYPE KEY COMMENT
 

En utilisant cette syntaxe, pour restreindre l'accès uniquement au service svn, on peut également ajouter "no-port-forwarding" ainsi que "no-agent-forwarding,no-X11-forwarding,no-pty"

  command="svnserve -t",no-port-forwarding TYPE KEY COMMENT

ainsi l'on utilisera une fois la clef ssh enregistrée (ssh-agent bash; ssh-add clef)

  svn co svn+ssh://svn@host/path/to/base/repos
 

1.2 Plusieurs utilisateurs
Pour l'instant tout le monde se loggue en tant qu'utilisateur "svn". En particulier, il est ainsi impossible de différentier les auteurs des différents commits effectués.



ajouter l'option "--tunnel-user=user" également pour l'identifier.


2ème étape : Eviter d'avoir à afficher tout le path sur le serveur

Si le repo est dans /path/to/base/repos, alors :

  command="svnserve -r /path/to/base/",no-port-forwarding TYPE KEY COMMENT

Attention : il semble que l'option -r et l'option -t soient incompatibles si l'on utilise pas l'option --tunnel-user

3 Et Au Final...

Nous obtenons dans le fichier ~svn/.ssh/authorized_keys :

   command="/path/to/svnserve -t -r /repository/root --tunnel-user=alice",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty TYPE1 KEY1 COMMENT1
  command="/path/to/svnserve -t -r /repository/root --tunnel-user=bob",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty TYPE2 KEY2 COMMENT2
 

1.4 liens/remerciements.

• Merci à PeterS sur irc.freenode.net/#svn
• Pour certain des exemples : http://svn.collab.net/repos/svn/trunk/notes/ssh-tricks

Molly-guard (for ssh)

Installant sshd sur mon eee ubuntu m'a conseillé d'ajouter également «molly-guard», dont je n'avais jamais entendu parler.

Found on http://packages.ubuntu.com/fr/intrepid/molly-guard

protects machines from accidental shutdowns/reboots

The package installs a shell script that overrides the existing shutdown/reboot/halt/poweroff commands and first runs a set of scripts, which all have to exit successfully, before molly-guard invokes the real command.

One of the scripts checks for existing SSH sessions. If any of the four commands are called interactively over an SSH session, the shell script prompts you to enter the name of the host you wish to shut down. This should adequately prevent you from accidental shutdowns and reboots.

This shell script passes through the commands to the respective binaries in /sbin and should thus not get in the way if called non-interactively, or locally.

sshfs mount

Quand même tellement plus pratique qu'un ssh + scp lorsqu'il s'agit uniquement de transférer qq fichiers !!

# sshfs user@serveur.ext:/home/user/ mountpoint/

cron + ssh + keychain

Keychain :

dans .bash_profile

#!/bin/bash
#example ~/.bash_profile file
/usr/bin/keychain private keys
#redirect ~/.ssh-agent output to /dev/null to zap the annoying
#"Agent PID" message
source ~/.ssh-agent > /dev/null

cron :

crontab -e :

42 4 * * * time /home/cm/usr/bin/script_sauvegarde.sh

script_sauvegarde.sh

#!/bin/bash

keychain $HOME/SSH_PRIV_KEY
source /home/cm/.keychain/MACHINE-NAME-sh

rsync -e ssh --exclude-from=RSYNC_EXCLUDE_FILE  -Cavz CLIENT/ SERVER:PATH_ON_SERVER/