SSH senza fonte .bashrc
Stavo sperimentando il mio .bashrcfile mentre ero connesso in remoto a un server tramite SSH. Ho inavvertitamente lasciato un messaggio exitche ha causato la disconnessione immediata di tutti gli accessi successivi. Sono stato effettivamente bloccato. Sono stato in grado di recuperare l'accesso con l'intervento di qualcuno con privilegi di root, ma sarebbe stato possibile senza l'aiuto di qualcun altro?
Ho provato a fare cose come correre ssh <server> 'bash --norc --noprofile'e ssh <server> 'mv .bashrc bashrc-backup', e persino provare a sovrascriverlo forzatamente con scp empty-file <server>:.bashrc. Tuttavia, tutte queste opzioni sembrano fare affidamento sul primo approvvigionamento del guasto .bashrcprima di eseguire il comando, quindi nessuna di esse ha funzionato.
Può darsi che non ci sia via d'uscita da questo tipo di situazione. Ma è questo in base alla progettazione? C'è una ragione per cui è così facile escludersi da un sistema, ad esempio semplicemente correndo ssh <server> 'echo exit > .bashrc'? Esistono modi per mitigare questo tipo di errore?
Risposte
Come discusso nell'altra risposta, quando un client SSH si connette al server OpenSSH, il server OpenSSH generalmente avvierà una sessione di shell per conto del client, utilizzando la shell di login dell'utente:
- Se il client richiede una sessione interattiva, il server avvierà la shell di login dell'utente.
- Se il client richiede l'esecuzione di un comando, il server utilizzerà la shell di login dell'utente per eseguire il comando come comando di shell.
- Utilità come
scp,rsyncegitche usano ssh per il trasporto richiederanno un comando da eseguire sul sistema remoto, quindi rientrano nella # 2.
Se hai qualcosa nei file di avvio della shell dell'utente remoto che causa l'uscita dalla shell, avrai problemi ad entrare.
SFTP tuttavia è un caso speciale. Il server OpenSSH può essere configurato per supportare SFTP senza avviare un comando esterno. In tal caso, puoi utilizzare sftp per connetterti al server ed eliminare, rinominare o modificare il .bashrcfile che causa il problema.
Dipende da come il server è configurato per supportare sftp. Può servire sessioni sftp avviando un programma esterno (denominato sftp-server). In questo caso avresti lo stesso problema di accesso che hai con programmi come scp. Oppure, il server può servire la sessione sftp tramite qualcosa chiamato "internal-sftp" , che non richiede l'invocazione di una shell. Dipende solo da come è configurato il particolare server SSH.
Il motivo per cui ciò accade è perché sshd, il componente lato server, richiama i processi utilizzando la shell. Se genera una shell interattiva, la genera come una shell di login; altrimenti, utilizza l' -cargomento per generare una shell non interattiva per eseguire il comando specificato.
Tutte le operazioni che hai specificato (comandi specificati e scp) sono operazioni non interattive, quindi normalmente bash non verrebbe caricata .bashrc, ma bash ha un caso speciale per quando invocato da in sshdmodo che lo invoca comunque. Se stavi usando zsh, allora .zshenv(che è invocato per tutte le shell) verrebbe caricato, ma .zshrc(che è solo per le shell interattive) non lo sarebbe a meno che tu non stia caricando specificamente una sessione di shell.
In questo caso, se stai usando bash, sei sfortunato. Non c'è alcun modo per invocare un comando SSH sul lato server senza utilizzare la shell; questo è vero anche per scp e sftp. Il più delle volte, si desidera utilizzare la shell perché imposta cose come PATHper vari programmi e consente una quantità ragionevole di scripting di comandi complessi, quindi OpenSSH la usa sempre.
Questo ha anche alcuni vantaggi in termini di sicurezza: se provi ad accedere a un account di sistema che in qualche modo ha una password valida ma una shell di /usr/sbin/nologino /bin/false, allora non puoi fare nulla, che è probabilmente ciò che intendeva l'amministratore di sistema.
Ci sono modi per mitigare questo problema. Molte persone mantengono un repository Git dei loro dotfile e li sviluppano su un sistema, quindi li distribuiscono su altri. Ad esempio, eseguo sempre lo sviluppo di file dot sul mio laptop. Presumibilmente noteresti questo problema un po 'prima se ogni volta che apri una nuova finestra di terminale uscisse immediatamente e potresti avere accesso root per risolverlo da solo.
Se hai bisogno di testare una configurazione che potrebbe bloccarti, come la configurazione della shell o una sudoersmodifica, puoi lasciare una shell (normale o root, rispettivamente) aperta e poi fare dei test, quindi se rompi qualcosa, hai ancora un modo per annullarlo.