Accedi senza eseguire bash_profile o bashrc

Quindi diciamo che uno ha digitato qualcosa nel loro .bashrcche gli impedisce di accedere tramite ssh(cioè il login ssh esce a causa dell'errore nel file). C'è un modo in cui quella persona potrebbe accedere senza eseguirlo (o .bashrcpoiché l'uno esegue l'altro) o altrimenti eliminare / rinominare / invalidare il file?

Supponiamo di non avere accesso fisico alla macchina, e questo è l'unico account utente con la possibilità di accedere.

Per riferimento: .bash_profileinclude .bashrc:

[[ -f ~/.bashrc ]] && . ~/.bashrc

Modifica: cose che ho provato:

ssh user@host "rm ~/.bashrc"

scp nothing user@host:/RAID/home/tom/.bashrc

ssh user@host  "/bin/bash --norc"

Tutti danno l'errore:

/RAID/home/tom/.bashrc: line 16: /usr/local/bin/file: No such file or directory
/RAID/home/tom/.bashrc: line 16: exec: /usr/local/bin/file: cannot execute: No such file or directory

Penso che le tue uniche opzioni siano:

• ssh come altro utente e su al tuo account;

• utilizzare qualcosa come ftp o smbclient, se i servizi pertinenti sono abilitati sull'host;

• trova una vulnerabilità aperta in un servizio di rete aperto e sfruttalo :).

• ottenere un amministratore per risolvere il problema.

ssh -t username@hostname /bin/sh per me va bene.

Ho avuto lo stesso problema e in qualche modo sono stato in grado di risolverlo. Ho usato ssh per accedere al sistema e ho premuto e tenuto premuto Ctrl + c non appena ho effettuato l'accesso al sistema. Quindi, ~ / .bashrc non è stato letto e sono stato in grado di modificarlo.

Ho usato un CVE pubblicato per eseguire un comando come root tramite un'interfaccia Web in un software di monitoraggio della rete che avevo installato. rm /RAID/home/tom/.bashrc

Quindi potrei accedere e svn ripristinare le modifiche che ho fatto.

È necessario a) avviare bash senza source'ing sia ~/.bashrco ~/.bash_profilee b) in quanto tale shell non sarebbe una shell di login completo / non hanno alcun tty allegato, la forza ssh di allegare una tty :

ssh -t user@host bash --norc --noprofile

Sei sfortunato.

Tutti i comandi ssh eseguono la shell di accesso. ssh $COMMANDcorre $SHELL -c $COMMAND, scpcorre $SHELL -c /path/to/sftp-server, pianifica sshsolo il tuo guscio.

Nessuna delle risposte sopra può bypassare la shell di accesso di ssh. È possibile passare una riga di comando completa e quindi esegue la shell remota per elaborare il comando e impostare l'ambiente di lavoro per il comando. Ecco a cosa servono le shell ed è il modo Unix. Avresti tutti i tipi di problemi di compatibilità se provassi a eseguire qualcosa senza una shell. Allo stesso modo, provare un control-C dovrebbe fare come chiamare exit, che è il comportamento che stai cercando di evitare. Se bash continua è un bug. Perché la gente continua a dire che la pagina man dice qualcosa di diverso, è necessario citarla perché non dice nulla del genere nella mia pagina man.

Inoltre, sulla maggior parte dei sistemi Linux, specificare / bin / sh non fa NIENTE poiché si tratta solo di un link simbolico a bash!

Vuoi fare un test? Aggiungi istruzioni "echo" a te .bashrc e .profile e vedi quale viene eseguito. L'ho fatto. Ecco i risultati

ssh user@hosteseguirà .bash_profile ssh user@host /bin/basheseguirà .bashrc, ma pensa che non sia interattivo (nessun prompt). ssh -t user@host /bin/bashesegue .bashrc due volte ... una volta al login, una volta per il comando passato, quindi specificando QUALSIASI shell verrà sempre eseguito il primo. ssh -T user@hostequivale a non specificare affatto -T o -t.

Ora, se noti, il mio sistema non esegue entrambi i file, solo l'uno o l'altro. Ma il poster originale ha una linea in .bash_profile che esegue .bashrc, quindi .bashrc verrà sempre eseguito, qualunque cosa accada. Non avrei dovuto mettere quella linea lì! Se quella linea non esistesse, non avresti avuto problemi.

Dovrai trovare un altro modo o trovare un amministratore. Ecco a cosa servono gli amministratori.

Qualcosa di simile a:

ssh host "/bin/bash --norc"

che sembra funzionare, ma nota che PS1 non è impostato, quindi digiterai i comandi senza un prompt.

Questo ha il vantaggio di essere non distruttivo.

provare

echo ^C | ssh <hostname> ' rm .bashrc'

^ C c'è control-v quindi c

ssh -t user@host "bash --norc --noprofile -c '/bin/rm .bashrc'"

Mashing ctrl-C funziona fintanto che puoi ottenere un ctrl-C prima che il .bashrc esca. Sfortunatamente, questo può essere difficile da fare se exitè all'inizio del .bashrc.

Puoi inserire un ctrl-C il prima possibile eseguendo il piping su ssh direttamente:

{ echo ^C; cat /dev/tty; } | ssh -tt user@host

Si noti che ^Cviene digitato come ctrl-V seguito da ctrl-C.

Questo convoglia un singolo ctrl-C seguito dall'input dal terminale di controllo, mentre -ttimpone l'allocazione di un psuedo-terminale. Tutto ciò ti dà una shell (alquanto malformata) sulla macchina remota, bypassando il più possibile di .bashrc.

Puoi provare a sovrascrivere .bash_profilecon un file vuoto usando il scpcomando. Da quello che ho cercato su google, scp usa un login non interattivo che non legge .bash_profile.

Puoi anche eliminare il file bashrc:

ssh <hostname> rm ~/.bashrc

Se il sistema è configurato normalmente, .bash_profile non verrà eseguito per una shell non interattiva (come l'esecuzione di un comando).

Poiché affermi che il problema si trova nel file .bash_profile, prova a spostarlo di mezzo:

ssh user@host "mv ~/.bash_profile ~/.bash_profile_broken"

UH = 'user @ host'; ssh $ UH 'mv ~ / .bashrc ~ / letmein'; ssh $ UH

Si prega di non tagliare ed eseguire, cambiare usere host, quindi modificare letmeine salvare come.bashrc

Complimenti a user60069, ha funzionato per me, ma io uso il file di avvio specifico della shell .bashrc, quindi il login con / bin / sh ha funzionato per me.

Tuttavia, se ti trovi in ​​una situazione "senza fortuna", offro questa soluzione, basata sulle soluzioni di user60069 e Dennis W:

ssh -t you@host  /bin/bash --noprofile  --norc

Dennis W ha offerto l'opzione --norc, che qualcuno ha detto che non funzionava per loro.

Esegui "man bash" o "man (la tua shell)" per le opzioni per disabilitare i file di avvio. Hai solo bisogno di usare una shell disgustosa per il tempo necessario per risolvere il problema.

Un altro modo per accedere al server è senza profilo, si prega di trovare sotto il comando
ssh -t user@host bash --noprofile

Per AWS utilizzando il file pem e nessun altro utente
ssh -ti "YOUR-PEM-FILE-NAME.pem" ec2-user@YOUR-IP-ADDRESS bash --noprofile

Spero che sia di aiuto!

Dai suggerimenti e dalle risposte di cui sopra, direi che non sono i file .bashrc o .bash_profile. Inoltre la manpage ssh dice che se si specifica un comando da eseguire, i file del profilo non verranno letti.

Suggerirei di provare a eseguire una shell di login diversa (ksh? Csh? Sh?) Dal percorso assoluto; inoltre, fai attenzione che potrebbe trattarsi di un problema completamente diverso (quota? Esegui e leggi i permessi sulla tua home directory?), quindi un approccio laterale sarebbe meglio. Puoi chiedere a un altro utente di fare una ls -la $YOUR_HOME_DIRe-mail il risultato?