Restreignez la sauvegarde sans mot de passe avec SFTP

Question 1

Ma question est, comment puis-je restreindre la command à ce transfert SFTP dans la key publique qui est généré?

Il y a 2 methods pour faire cela.

1. – Restreindre par sshd

Cette méthode implique la configuration de la fonctionnalité SFTP dans votre démon SSH, sshd . Ceci est contrôlé par le file de configuration /etc/ssh/sshd_config . REMARQUE: Cela limitera l'user, la backup ne sera autorisée à SFTP dans le server.

 # /etc/ssh/sshd_config Subsystem sftp internal-sftp ## You want to put only certain users (ie users who belongs to sftpusers ## group) in the chroot jail environment. Add the following lines at the end ## of /etc/ssh/sshd_config Match User backup ForceCommand internal-sftp 

2. – Restreindre via authorized_keys

Cette méthode n'implique aucune modification du file sshd_config . Vous pouvez limiter un user + une key SSH à une seule command via la fonction command= que vous avez déjà mentionnée dans votre question. L'astuce est dans quelle command vous incluez. Vous pouvez mettre le server SFTP dans cette command= ligne, ce qui a le même effet que la configuration du server SFTP dans votre file sshd_config .

 # User backup's $HOME/.ssh/authorized_keys file command="/usr/libexec/openssh/sftp-server" ssh-dss AAAAC8ghi9ldw== backup@host 

REMARQUE: si l'user a un access en écriture à ~/.ssh/authorized_keys , il peut le lire et / ou le modifier. Par exemple, ils pourraient le download, le modifier, et le reupload enlever le commmand=... , en lui accordant un access illimité aux commands, y compris le shell. Si l'user a un access en écriture à ~/.ssh , ils peuvent aussi simplement dissocier et recréer le file, ou chmod pour écrire l'access. Il existe de nombreuses solutions possibles, telles que la mise à distance des files ~/.ssh/authorized_keys dans un endroit non accessible à l'user, par exemple:

 Match Group sftponly AuthorizedKeysFile /etc/ssh/authorized_keys/%u 

Question 2

Et puisque je suis sur une adresse IP dynamic, comment surmonter le problème de "l'hôte connu manquant" à chaque fois que mon IP change?

Ceci est plus difficile mais faisable en utilisant la fonction from= dans le file authorized_keys . Ici, nous somehost.dyndns.org access à partir de seulement l'hôte, somehost.dyndns.org .

de-no-port-forwarding, no-X11-forwarding, no-agent-forwarding, no-pty ssh-dss AAAAC8ghi9ldw == backup @ host

Les parameters supplémentaires après la command= sont tout aussi importants, car ils vont limiter encore plus l'utilisation de la key SSH.

répartition des fonctionnalités

• from='hostname1,hostname2,'' – Restreint l'access à partir des templates IP ou hostname spécifiés
• command='command' – Exécute la command spécifiée après l'authentification
• no-pty – N'alloue pas de pty (ne permet pas la connection interactive)
• no-port-forwarding – Ne permet pas le transfert de port
• no-X11-forwarding – user ne sera pas en mesure de supprimer l'affichage X11 GUI
• no-agent-forwarding – l'user ne sera pas en mesure de transmettre par cet hôte à d'autres hôtes internes

Pour se débarrasser du message concernant les «hôtes connus manquants», vous pouvez append cette option SSH au client lorsqu'il se connecte comme ceci:

 $ ssh -o SsortingctHostKeyChecking=no .... 

Voir la page de ssh_config , ssh_config pour plus de détails sur ce commutateur.

Restreindre la coquille de l'user

Pour les deux solutions ci-dessus, vous voudrez probablement verrouiller l'user de backup en limitant également le shell de cet user dans le file /etc/passwd . En règle générale, vous voudrez le configurer de façon scponly , mais il existe également d'autres choix. Voyez ce Q & A d'U & L intitulé: " Avez-vous besoin d'un shell pour SCP? " Pour les façons de le faire.

L'utilisation de /sbin/nologin peut également être utilisée si vous optez pour l'utilisation de la fonction chroot de sshd_config comme indiqué dans # 1 ci-dessus. Cependant, si vous choisissez d'utiliser la méthode décrite au # 2 , vous devrez probablement utiliser scponly ou quelque chose d'autre pour le shell de l'user dans /etc/passwd .

BONUS – Extension # 2 ci-dessus

Si vous avez besoin d'exposer un set de commands pour cet user, vous pouvez également le faire. Créez un script comme ceci, /home/backup/commands.sh :

 #!/bin/sh case $SSH_ORIGINAL_COMMAND in "diskspace") df -h ;; "dirlist") ls -1 ;; "apache_restart") /etc/init.d/apache restart ;; *) echo "Unknown command" esac 

Vous configurez ensuite le file authorized_keys comme ceci:

 command="/bin/sh /home/user/commands.sh" ssh-dss AAAAC8ghi9ldw== user@host 

L'user de backup peut alors exécuter ces commands comme ceci:

 # diskspace $ ssh -q user@remote_host diskspace Filesystem Size Used Avail Use% Mounted on /dev/mapper/dev-root 39G 2.2G 35G 6% / # dirlist $ ssh -q remote_host dirlist commands.sh dump.sql 

Les references

• Conseils et astuces SSH
• Cinq minutes pour un SSH encore plus sécurisé

Shell restreinte

Vous devez affecter un shell restreint tel que scponly ou rssh.

Lorsque vous utilisez scp ou sftp, vous vous connectez au site distant via ssh, puis le shell distant exécute un process scp ou un process sftp. Ce dont vous avez besoin est un shell restreint qui n'autorise que scp ou sftp à verrouiller la connection.