Pourquoi certaines sessions ssh proposent-elles la saisie semi-automatique et d'autres non?


10

Question très débutant!

J'utilise deux serveurs différents, tous deux faisant partie du même cluster Amazon AWS. Ils ne sont pas dirigés par moi.

Sur une session ssh, le terminal me permet de compléter automatiquement. À l'autre séance, ce n'est pas le cas - j'aurais aimé que ce soit le cas.

Pourquoi est-ce - est-ce une option définie par l'administrateur du serveur?

Et puis-je faire quelque chose?

Merci!

Réponses:


15

Ce n'est pas vraiment une question de programmation, mais cela a à voir avec votre shell. Vous pouvez essayer de démarrer le bashshell (en tapant bashà l'invite) et voir si vous pouvez compléter la saisie semi-automatique.

Si cela fonctionne, vous pouvez utiliser which bashpour vérifier son emplacement, puis chsh -s /bin/bashpour définir votre shell de façon permanente.

Une liste des coques disponibles est également disponible dans /etc/shells.


Je ne peux pas changer ma coque pour une raison quelconque. Est-il possible de le faire en tant que root? You may not change the shell for 'counterstrike'.
Tomáš Zato - Réintègre Monica le

3

Il s'agit d'une combinaison du shell utilisé dans votre session ssh ainsi que de sa configuration.

Bien que votre shell puisse prendre en charge la saisie semi-automatique, il peut ne pas être configuré pour cela. Si vous utilisez le shell bash, vous pouvez modifier votre fichier .bashrc local pour les éléments suivants afin de fournir la saisie semi-automatique.

# enable bash completion in interactive shells
if [ -f /etc/bash_completion ]; then
    . /etc/bash_completion
fi

1
Le package d'achèvement bash n'est nécessaire que pour l'achèvement plus avancé de choses comme les options de ligne de commande, les noms de serveur, les répertoires de référentiel VCS, .... L'achèvement des commandes, répertoires, noms de fichiers, variables et noms d'utilisateurs fonctionne sans.
ak2

2

Copié de ma propre réponse sur unix.SE :

Il semble que spécifiquement dans Ubuntu les entrées ~/.ssh/known_hostssoient hachées , donc l'achèvement SSH ne peut pas les lire. C'est une fonctionnalité, pas un bug. Même en ajoutant HashKnownHosts noà ~/.ssh/configet /etc/ssh/ssh_configje n'ai pas pu empêcher le hachage de l'hôte.

Cependant, les hôtes qui m'intéressent se trouvent également dans ~/.ssh/config. Voici un script pour Bash Completion qui lit les entrées de ce fichier:

_ssh() 
{
    local cur prev opts
    COMPREPLY=()
    cur="${COMP_WORDS[COMP_CWORD]}"
    prev="${COMP_WORDS[COMP_CWORD-1]}"
    opts=$(grep '^Host' ~/.ssh/config | awk '{print $2}')

    COMPREPLY=( $(compgen -W "$opts" -- ${cur}) )
    return 0
}
complete -F _ssh ssh

Mettez ce script /etc/bash_completion.d/sshet sourcez-le avec la commande suivante:

$ . /etc/bash_completion.d/ssh

J'ai trouvé ce guide inestimable et je n'aurais pas pu l'écrire sans lui. Merci Steve Kemp d' avoir écrit ce formidable guide!


1

IIRC cela pourrait aussi être un problème qui ssh hache les noms d'hôtes dans ~ / .ssh / known_hosts

la plupart des installations que je connais utilisent ~ / .ssh / known_hosts comme source pour la liste des hôtes disponibles pour l'achèvement, mais certains systèmes ont également commencé à définir "HashKnownHosts yes", ce qui interdit l'utilisation de known_hosts comme source ....

si vos lignes d'hôtes connues commencent par quelque chose comme

|1|BWO5qDxk/cFH0wa05JLdHn+j6xQ=|rXQvIxh5cDD3C4

le hachage est alors activé.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.