Question 1
Ma question est, comment puis-je restreindre la commande à ce transfert SFTP uniquement dans la clé publique générée?
Il existe 2 méthodes pour ce faire.
1. - Restriction via sshd
Cette méthode implique la mise en place de la fonction SFTP au sein de votre démon SSH, sshd. Ceci est contrôlé via le /etc/ssh/sshd_configfichier de configuration. REMARQUE: cela restreindra l'utilisateur, backuppour qu'il ne soit autorisé à SFTP que sur le serveur.
# /etc/ssh/sshd_config
Subsystem sftp internal-sftp
## You want to put only certain users (i.e 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. - Restriction via les touches autorisées
Cette méthode n'implique aucune modification du sshd_configfichier. Vous pouvez limiter un utilisateur + une clé SSH à une seule commande via la command=fonctionnalité que vous avez déjà mentionnée dans votre question. L'astuce réside dans la commande que vous incluez. Vous pouvez placer le serveur SFTP dans cette command=ligne, ce qui a le même effet que la configuration du serveur SFTP dans votre sshd_configfichier.
# User backup's $HOME/.ssh/authorized_keys file
command="/usr/libexec/openssh/sftp-server" ssh-dss AAAAC8ghi9ldw== backup@host
REMARQUE: si l'utilisateur dispose d'un accès en écriture à ~/.ssh/authorized_keys, il peut le lire et / ou le modifier. Par exemple, ils pourraient le télécharger, le modifier et le re-télécharger en supprimant le commmand=..., lui accordant un accès sans entrave aux commandes, y compris le shell. Si l'utilisateur dispose d'un accès en écriture ~/.ssh, il peut également simplement dissocier et recréer le fichier, ou le chmodcréer pour accéder en écriture. Il existe de nombreuses solutions possibles, telles que ranger les ~/.ssh/authorized_keysfichiers dans un endroit non accessible en écriture, comme avec:
Match Group sftponly
AuthorizedKeysFile /etc/ssh/authorized_keys/%u
Question 2
Et puisque je suis sur une adresse IP dynamique, comment puis-je surmonter le problème de "l'hôte connu manquant" chaque fois que mon IP change?
C'est plus délicat mais réalisable en utilisant également la from=fonctionnalité dans le authorized_keysfichier. Ici, nous limitons l'accès à partir de l'hôte uniquement somehost.dyndns.org.
from = "somehost.dyndns.org", command = "/ usr / libexec / openssh / sftp-server", no-port-forwarding, no-X11-forwarding, no-agent-forwarding, no-pty ssh-dss AAAAC8ghi9ldw == sauvegarde @ hôte
Les paramètres supplémentaires après le command=sont également importants, car ils limiteront encore plus l'utilisation de la clé SSH.
ventilation des fonctionnalités
from='hostname1,hostname2,'' - Restreint l'accès à partir des modèles IP ou de nom d'hôte spécifiés command='command' - Exécute la commande spécifiée après l'authentification no-pty - N'attribue pas de pty (ne permet pas la connexion interactive) no-port-forwarding - Ne permet pas la redirection de portno-X11-forwarding - l'utilisateur ne pourra pas supprimer les interfaces graphiques d'affichage X11no-agent-forwarding - l'utilisateur ne pourra pas transmettre via cet hôte à d'autres hôtes internes
Pour se débarrasser du message sur les "hôtes connus manquants", vous pouvez ajouter cette option SSH au client lorsqu'il se connecte comme ceci:
$ ssh -o StrictHostKeyChecking=no ....
Consultez la page de manuel ssh_configpour plus de détails sur ce commutateur.
Restreindre le shell de l'utilisateur
Pour les deux solutions ci-dessus, vous souhaiterez probablement verrouiller l' backuputilisateur en limitant également le shell de cet utilisateur dans le /etc/passwdfichier. En règle générale, vous souhaiterez le définir scponly, mais il existe également d'autres choix pour cela. Voir cette Q&R U&L intitulée: " Avez-vous besoin d'un shell pour SCP? " Pour savoir comment procéder.
L'utilisation de /sbin/nologinpeut également être utilisée si vous choisissez d'utiliser la fonction chroot sshd_configcomme indiqué au n ° 1 ci-dessus. Cependant, si vous choisissez d'utiliser la méthode décrite au # 2 , vous devrez probablement utiliser scponlyou autre chose pour le shell de l'utilisateur /etc/passwd.
BONUS - Prolonger # 2 ci-dessus
Si vous devez exposer un ensemble de commandes pour cet utilisateur, vous pouvez également le faire. Créez un script comme celui-ci /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 authorized_keysfichier comme suit:
command="/bin/sh /home/user/commands.sh" ssh-dss AAAAC8ghi9ldw== user@host
L' backuputilisateur peut ensuite exécuter ces commandes comme suit:
# 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 références