Come impostare bash readline in modalità vi automaticamente all'accesso a un sistema?

Il mio team è responsabile di migliaia di macchine Linux / Unix, quindi naturalmente l'account di root è "condiviso" tra gli amministratori. Preferisco la modalità vi, altri preferiscono la modalità emacs.

Come posso impostare readline di bash in modalità vi al login SSH su qualsiasi macchina, senza costringere tutti gli altri a usare anche la modalità vi?

In sostanza, vorrebbe avere l'effetto di set -o vidopo il login senza doverlo digitare ogni volta e senza forzarlo su tutti gli altri (per quanto la modalità emacs sia fastidiosa per me, la modalità vi è fastidiosa per loro).

So che questo non sarebbe un problema se tutti usassero i propri account con sudo per eseguire comandi privilegiati, ma a causa di circostanze al di fuori del mio controllo, purtroppo non è un'opzione.

Ecco un modo stupido per farlo, che funziona davvero solo con l'autenticazione a chiave pubblica:

Innanzitutto, assicurati che la tua macchina locale sia ncpresente.

In secondo luogo, sempre sul tuo computer locale, crea uno script (lo chiamerò connect-to-server) e mettilo in un posto che ${PATH}conosci *:

#!/bin/sh
# connect-to-server
ssh -q server-hostname "touch .yourname" </dev/null >/dev/null 2>&1
nc server-hostname 22

Successivamente, modifica il .bashrcsul sistema remoto per includerlo da qualche parte:

# partial .bashrc
if [ -f "${HOME}/.yourname" ]; then
  rm "${HOME}/.yourname"
  set -o vi
fi

Infine, nel tuo computer locale, modifica ~/.ssh/configper aggiungere:

# partial ssh config
Host serverNickname
  Hostname server-hostname
  ProxyCommand connect-to-server

Gli aspetti negativi di questo approccio (e perché lo chiamo sciocco):

• Se è necessario un comando proxy effettivo, diventa più complicato.
• Se qualcun altro accede contemporaneamente a te, c'è la possibilità che il .yournamefile non sia stato ancora cancellato, nel qual caso ottengono set -o vianche il file.
• Soprattutto, se lo fai ssh serverNickname command, commandverrà eseguito, ma (poiché .bashrcnon viene mai fornito) il .yournamefile rimane, quindi sarebbe educato avere un secondo alias nella tua configurazione ssh che non usi lo pseudo-proxy.

In effetti, l' unico lato positivo di questo approccio è che sshnon è necessario fornire ulteriori argomenti al comando.

* Se non vuoi cambiare nulla sui sistemi remoti, ecco uno pseudo-proxy alternativo che crea un temporaneo .bashrc:

#!/bin/sh
# connect-to-server
ssh -q server-hostname 'ln .bashrc .bashrc.real; cat .bashrc.real <(printf "set -o vi; ln -f .bashrc.real .bashrc\n") >.bashrc.yourname; ln -f .bashrc.yourname .bashrc' </dev/null >/dev/null 2>&1
nc server-hostname 22

Ciò ha gli stessi svantaggi dell'altro metodo, quindi si vorrebbe comunque un secondo alias nella sshconfigurazione che non invochi lo pseudo-proxy.

Vorrei andare per:

ssh server -t "bash --login -o vi"

ma se sei un amministratore, puoi provare qualcosa di più pulito. Ad esempio, è possibile utilizzare l' SendEnvopzione ssh sul lato client per trasmettere una variabile specifica, utilizzare AcceptEnvnella sshdconfigurazione (lato server) per accettarla e, in base a ciò, modificare il .bashrcfile root per regolare il comportamento in base al valore della variabile.

Ciò implica cambiare la sshdconfigurazione su tutti gli host e sui loro .bashrc. Non esattamente un modo "autonomo" di fare, tuttavia ...

Per una soluzione lato client semplice:

alias connect='ssh -t root@server "bash -o vi"'

Questo fallirà se gli script di inizializzazione della shell di root usano esplicitamente set -o emacso si impostano EDITORsu emacs, o se il .initrcfile di root richiama emacsle associazioni di tasti.

Il resto di questa risposta riguarda soluzioni lato server.

Funziona quando si sshentra nella macchina e quindi si utilizza sudo -i:

Per il tuo /root/.bashrc:

if [[ -n "$SUDO_USER" ]] && [[ -f /root/.bashrc-"$SUDO_USER" ]]; then
  source /root/.bashrc-"$SUDO_USER"
fi

Questo ti permette di avere un bashrcfile personale chiamato in /root/.bashrc-patrickcui puoi fare quello che vuoi, come set -o vi.

Combinando questo con un approccio un po 'ingenuo per raccogliere quel file rc a seconda di $SSH_CLIENT:

if [[ -n "$SUDO_USER" ]]; then
  person="$SUDO_USER"
elif [[ -n "$SSH_CLIENT" ]]; then

  case "$SSH_CLIENT" in
    192.168.216.100*)  person="joe" ;;
    192.168.216.120*)  person="patrick" ;;
    192.168.216.150*)  person="lindsey" ;;
  esac

fi

if [[ -n "$person" ]] && [[ -f /root/.bashrc-"$person" ]]; then
  source /root/.bashrc-"$person"
fi

Questo ovviamente funziona solo se ti connetti sempre dallo stesso indirizzo IP ...

Un altro approccio che utilizza il campo dei commenti della particolare chiave SSH che stai utilizzando, che funziona se stai inoltrando l'agente SSH al server:

ssh_comment="$( ssh-add -L | grep -f /root/.ssh/authorized_keys | awk '{ print $NF '} | head -n 1 )"

Questo seleziona il campo del commento per la chiave che hai usato per connetterti al server. L' head -n 1è lì nel caso in cui vi capita di avere molti dei vostri chiavi nel authorized_keysfile.

È quindi possibile utilizzare $ssh_commentper selezionare un file rc da sorgente, sia direttamente come con l' $SUDO_USERapproccio sopra (in cui il commento in $ssh_commentpotrebbe dover subire un po 'di pulizia se è un nome di percorso), sia tramite caseun'istruzione come con l' $SSH_CLIENTapproccio.

Se vuoi davvero farlo senza modifiche sul lato server, o:

1) Esegui qualcosa di simile

$ ssh user@host -t 'bash -l -o vi' 

Non credo che la documentazione sia troppo chiara su questo, ma -o optionè menzionata e sembra funzionare.

2) Utilizzo previsto:

La expectsceneggiatura:

$ cat bashsetup.expect
#!/usr/bin/expect -f 

set user [lindex $argv 0];
set host [lindex $argv 1];

spawn ssh -l $user $host
expect "$ "
send "set -o vi\n"
interact

Renderlo eseguibile ed esegui:

$ ./bashsetup.expect user testhost
spawn ssh -l user testhost
[motd, blahblah...]
user@testhost ~$ set -o vi
user@testhost ~$ 

Ciò presuppone che sia possibile accedere senza immettere le password (per l'host remoto o per le chiavi), altrimenti lo script di attesa dovrebbe tenerne conto. Ma con molte macchine probabilmente lo avrai già. Inoltre, mi aspettavo un segno di dollaro e uno spazio, modificalo secondo il tuo prompt: "# "forse.

Tuttavia, se qualcosa stampato prima del prompt include quegli stessi caratteri, dovrai includere qualcosa di più specifico nella stringa prevista.

Inoltre, quello script non supporta fornire ulteriori argomenti a ssh. Se hai intenzione di dare un comando esplicito per l'esecuzione, probabilmente non hai bisogno di vi-mode, ma se hai bisogno di dire port tunneling, questo potrebbe essere un problema.

Ma in ogni caso, penso davvero che questo dovrebbe essere risolto sui sistemi di destinazione con account separati ( sudoo semplicemente vecchio UID 0). La configurazione personalizzata sarebbe utile anche in molti altri casi e in generale avresti un mucchio di file di configurazione e variabili di ambiente che desideri impostare. (Considera che gli amministratori potrebbero non essere d'accordo sul valore $EDITORo sul contenuto virco altro.)

Anche la rimozione degli utenti sarebbe più semplice con account separati.

Qualsiasi modo di sincronizzare i file su tutti gli host lo risolverebbe anche banalmente permettendoti di accedere con qualcosa di simile ssh -t user@host 'patricks_shell.sh'o ssh -t user@host 'bash --rcfile patrick.rc'.

puoi avere un file rc personalizzato seguendo questa guida:

File rc utente | Secure Shell: la guida definitiva

o iniettare un'azione da riga di comando nel file authorized_keys:

Config SSH esegue automaticamente il comando remoto | Scambio di stack Unix e Linux