Su bash in generale
Il design di Bash rispetto ai file di avvio è piuttosto peculiare. I carichi di bash .bashrc
in due circostanze non correlate:
Su SSH in generale
Quando si esegue un comando tramite il protocollo SSH, il comando viene passato sul filo come una stringa. La stringa viene eseguita dalla shell remota. Quando si esegue ssh example.com somecommand
, se la shell di accesso dell'utente remoto è /bin/bash
, viene eseguito il server SSH /bin/bash -c somecommand
. Non è possibile ignorare la shell di accesso. Ciò consente shell di accesso limitate, ad esempio per consentire solo la copia dei file e non l'esecuzione generale dei comandi.
C'è un'eccezione: il protocollo SSH consente al client di richiedere un sottosistema specifico. Se il client richiede il sftp
sottosistema, per impostazione predefinita il server OpenSSH richiama il programma /usr/lib/openssh/sftp-server
(la posizione può variare) tramite la shell di accesso dell'utente. Ma può anche essere configurato per eseguire un server SFTP interno attraverso la linea
Subsystem sftp internal-sftp
nel sshd_config
file. Nel caso del server SFTP interno e solo in questo caso, la shell di accesso dell'utente viene ignorata.
Per questa sfida
Nel caso di OverTheWire Bandit 18, .bashrc
contiene
…
# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac
…
echo 'Byebye !'
exit 0
Quindi puoi risolvere questo livello facendo tutto ciò che impedisce a bash di non essere interattivo.
Come hai scoperto, SFTP funziona.
Ma ssh bandit18@bandit.labs.overthewire.org cat readme
funzionerebbe anche.
Come sarebbe echo 'cat readme' | ssh bandit18@bandit.labs.overthewire.org
.
E anche premendo Ctrl + C al momento giusto durante un login interattivo funzionerebbe: interromperebbe bash, quindi .bashrc
non verrebbe eseguito completamente. Bash impiega tempo macroscopico per avviarsi, quindi mentre questo non funziona in modo affidabile, può essere fatto in pratica.