Si vous rencontrez ce problème en pushant vers github par exemple.
Il suffit de vider le paramètre core.askpass :
git config --global core.askpass ''
Voir aussi man git config
Bsync est un outil de synchronisation bidirectionnelle utilisant Rsync pour les transferts. Les fichiers déplacés sont également synchronisés de manière intelligente.
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.
Plusieurs environnements de bureau (Gnome, Kde) lancent automatiquement un agent SSH au démarrage. Cependant, il faut penser à lancer la commande ssh-add avant de se connecter à un serveur.
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.
Vous disposez de deux systèmes et vous voulez mettre en place une sauvegarde sécurisée par rsync + SSH d’un système sur l’autre.
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 FORMATman rsyncview /usr/share/doc/rsync/scripts/rrsync.gz(restricted rsync, vous permet de gérer précisément les options autorisées)
Comment prendre la main en SSH sur un serveur planqué derrière une passerelle NAT ?
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 :
Problème :
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 :
On le trouve partout. Voici comment créer des partages sftp en chroot.
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 :
Si vous constatez de nombreuses tentative de connexion par ssh dans votre fichier /var/log/auth.log (robots qui testent des utilisateurs/mots de passes), il faut faire quelque chose.
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.
Pour afficher l’empreinte digitale (fingerprint) d’un système Unix :
ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key