Il suffit de vider le paramètre core.askpass :

git config --global core.askpass ''

Voir aussi man git config

Il utilise rsync pour les transferts de fichiers, find pour générer les snapshots de listes de fichiers, et ssh pour les les transferts distants.

bsync est une alternative à Unison, écrit en Python 3. Une grande force de bsync : il détecte et applique les déplacements de fichiers d’un dossier vers l’autre (Unison utilise des copies pour gérer les fichiers déplacés).

J’ai développé bsync pour synchroniser mon dossier de musique de mon laptop vers mon Raspberry Pi de manière efficace, et pour synchroniser avec le laptop de ma compagne également.

Bsync est publié sous GPL. N’hésitez pas à soumettre bugs et suggestions dans les tickets GitHub.

Infos, Téléchargement et Installation sur le dépôt GitHub.

En attendant que OpenSSH support le ssh-add automatique, vous pouvez ajouter ceci à votre .bashrc :

ssh-add -l >/dev/null || alias ssh='ssh-add -l >/dev/null || ssh-add && unalias ssh; ssh'

L’alias est créé uniquement si l’identity n’est pas encore ajoutée, et l’alias s’autodétruit une fois lancé.

Une fois l’identité ajoutée, la commande SSH normale est utilisée.

http://superuser.com/questions/325662/how-to-make-ssh-agent-automatically-add-the-key-on-demand/471640#471640

De manière très simple, vous pouvez utiliser la commande :

backup.example.com# rsync -avz --numeric-ids --delete root@myserver.example.com:/path/ /backup/myserver/

Pour faire la sauvegarde, vous devez être root sur le serveur, car certains fichiers ne sont lisibles que par root.

Problème : vous allez autoriser backup.example.com à faire n’importe quoi sur myserver.example.com, alors qu’un simple accès en lecture seule sur un dossier suffit.

Pour résoudre ce problème, il suffit d’utiliser la directive command="" dans le fichier authorized_keys pour filtrer la commande lancée.

Pour trouver cette commande, on lance rsync en ajoutant l’option -e'ssh -v' :

rsync -avz -e'ssh -v' --numeric-ids --delete root@myserver.example.com:/path/ /backup/myserver/ 2>&1 | grep "Sending command"

On obtient un résultat du genre :

debug1: Sending command: rsync --server --sender -vlogDtprze.iLsf --numeric-ids . /path/

Maintenant, il suffit d’ajouter la commande avant la clé dans le fichier /root/.ssh/authorized_keys :

command="rsync --server --sender -vlogDtprze.iLsf --numeric-ids . /path/" ssh-rsa AAAAB3NzaC1in2EAAAABIwAAABio......

Et pour encore plus de sécurité, on pourra ajouter un filtre par IP, et autres options :

from="backup.example.com",command="rsync --server --sender -vlogDtprze.iLsf --numeric-ids . /path/",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa AAAAB3NzaC1in2EAAAABIwAAABio......

Maintenant, vous pouvez essayer d’ouvrir un shell ssh, ou de lancer d’autres commandes rsync non autorisées…

Notes :

• Attention, si vous changez les options de la commande rsync, à ne pas oublier de modifier aussi le fichier authorized_keys.
• Plus besoin de chroot compliqué, vous pouvez oublier mon précédent article : SFTP-chroot-rsync

Voir aussi :

• man ssh #/AUTHORIZED_KEYS FILE FORMAT
• man rsync
• view /usr/share/doc/rsync/scripts/rrsync.gz (restricted rsync, vous permet de gérer précisément les options autorisées)

On utilise un tunnel SSH inverse :

nated-host$ ssh -R 2222:localhost:22 anyuser@public-host
anyuser@public-host$

Cette commande ouvre le port 2222 sur public-host et le redirige vers le port 22 local de nated-host.

Et pour finir, depuis public-host, on se connecte en ssh sur le port 2222 local, pour tomber sur nated-host :

public-host$ ssh -p2222 localhost
nated-host$

Références :

• man ssh
• http://articles.techrepublic.com.com/5100-10878_11-5779944.html?tag=nl.e011
• http://www.howtoforge.com/reverse-ssh-tunneling

Je souhaite créer un alias serveur-www qui me connecte au serveur en SSH et m’amène automatiquement dans le dossier /var/www/.

Voici :

ssh -t serveur 'cd /var/www && $SHELL'

Et pour l’alias qu’on pourra ensuite mettre dans son ~/.bashrc :

alias serveur-www="ssh -t serveur 'cd /var/www && $SHELL'"
serveur-www # pour tester

Références :

• http://groups.google.com/group/comp.security.ssh/browse_thread/thread/ab8981e1c8df2929
• http://ubuntuforums.org/archive/index.php/t-395113.html
• man ssh
• ssh -t serveur set

Dans le fichier /etc/ssh/sshd_config :

# on utilise le sftp interne d'openssh
# car la commande /usr/lib/openssh/sftp-server ne sera pas disponible dans le chroot
Subsystem sftp internal-sftp

Match group sftp
        ChrootDirectory %h
        X11Forwarding no
        AllowTcpForwarding no
        ForceCommand internal-sftp

MAJ 17/06/2010 : Attention à la syntaxe ! Les commentaires doivent commencer en début de ligne uniquement, et il ne doit pas y avoir d’espace en fin de la ligne ForceCommand internal-sftp.

Il suffit ensuite de créer des utilisateurs appartenant au groupe sftp, et le tour est joué.
On teste par :

sftp user@myserver.com

Problème si on veut utiliser la commande rsync pour transférer des fichiers, car la commande rsync n’est pas disponible dans le chroot.

En premier lieu, on autorise d’autres commandes que “internal-sftp” en commentant la ligne :

#ForceCommand internal-sftp

Ensuite, on crée l’arborescence suivante dans le dossier chroot :

bin/
bin/bash
bin/rsync
lib/
lib/libncurses.so.5
lib/ld-linux.so.2
lib/libacl.so.1
lib/libpopt.so.0
lib/libattr.so.1
lib/i686
lib/i686/cmov
lib/i686/cmov/libdl.so.2
lib/i686/cmov/libc.so.6

Il s’agit des commandes bash et rsync, ainsi que toutes leurs librairies (que l’on peut obtenir à l’aide de la commande ldd)

Note : l’utilisateur doit avoir /bin/bash comme shell par défaut.

Note 2 : le dossier du chroot doit appartenir à root, bien que ça soit le dossier de l’utilisateur. Pour permettre à l’utilisateur d’écrire dedans, il faut créer un sous dossier où il a les droit. C’est une contrainte importante, mais nécessaire à la sécurité d’un chroot, vous dirons les programmeurs d’OpenSSH.

Références :

• man sshd_config
• http://www.debian-administration.org/articles/590
• http://www.howtoforge.org/chrooted-ssh-sftp-tutorial-debian-lenny
• http://www.fuschlberger.net/programs/ssh-scp-sftp-chroot-jail/

Le plus simple est de mettre en place une restriction par IP dans votre pare-feu iptables, ou dans /etc/hosts.deny

Si vous ne pouvez/voulez pas mettre en place cette restriction, utilisez Fail2ban :

aptitude install fail2ban

L’installation par défaut bloque les tentatives de connexion SSH.

On peut adapter un peu la configuration, ou activer Fail2ban pour d’autres services. Exemple :

vi /etc/fail2ban/jail.conf
bantime  = 86400
maxretry = 10 # pour ssh
enabled  = true # pour vsftpd
maxretry = 10 # pour vsftpd

Ensuite, la commande iptables -L donne les adresses IP qui ont été bannies.

ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key

Source : http://ubuntuforums.org/showthread.php?t=789301