Si vous souhaitez passer des arguments à quelque chose de prédéfini dans Bash, vous pouvez utiliser une fonction au lieu d'un alias pour le même effet :
ssh-keyrm() { ssh-keygen -f "$HOME/.ssh/known_hosts" -R "$1"; }
Qui serait exécuté comme tel :
$ ssh-keyrm 127.0.0.1
Comme les alias, les fonctions peuvent être stockées dans .bashrc, .bash_profile ou définies en ligne dans un shell.
vous ne pouvez pas fournir d'argument à alias
Les alias bash fonctionnent comme de simples extensions (le nom de l'alias est simplement remplacé par la valeur de l'alias), ils ne peuvent donc pas référencer individu arguments utilisant $n.
Cependant, vous pouvez fournir des arguments tant qu'ils vont à la fin de la commande. Avec un alias comme celui-ci :
alias rmh="ssh-keygen -f ~/.ssh/known_hosts -R"
vous pouvez l'exécuter en tant que rmh 192.168.0.1 et bien que le mot rmh sera développé, tous les arguments qui le suivent resteront toujours au même endroit.
J'ai un problème similaire avec différents appareils utilisant la même adresse IP, mais j'ai adopté une approche légèrement différente pour le résoudre :empêcher les clés de l'hôte d'entrer dans known_hosts en premier lieu .
alias sshn='ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no'
Ensuite, exécutez sshn chaque fois que vous souhaitez désactiver la sécurité de la clé de l'hôte.
$ sshn [email protected]
Warning: Permanently added '192.168.1.1' (ECDSA) to the list of known hosts.
[email protected]'s password:
ssh vous indique qu'il a ajouté l'hôte aux hôtes connus, mais ce n'est pas le cas puisque l'écriture est passée à /dev/null . Vous pouvez supprimer cela en manipulant le niveau de journalisation, mais cela peut désactiver d'autres messages utiles.
J'ai aussi StrictHostKeyChecking=no afin qu'il ignore l'invite d'authenticité, mais si vous préférez voir l'empreinte digitale de la clé, vous pouvez omettre cette option.