Ciao a tutti, io mi sarei aspettato che tutti i comandi eseguiti sulla
shell da un utente sia da locale che da remoto fossero loggati nella
history dell'utente. Ho notato invece che i comandi shell inviati
tramite ssh non vanno a finire nella history... è giusto che sia così? Vengono loggati da qualche altra parte?

Grazie

Piviul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/27/24 15:12, Giancarlo Martini wrote:

forse sbaglio perchè non ho verificato ma a ad'occhio vengono loggati
nella history del sistema dove ci siamo connessi. Insomma, ci sono due history, una history per directory home

se intendi che vengono loggate nel sistema remoto certamente hai ragione
ma questo vorrebbe dire che su un server ssh è possibile eseguire
comandi di cui non rimane traccia sul server stesso? Forse è normale ma
credo mi sfugga qualcosa 😕...

Piviul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/27/24 15:12, Giancarlo Martini wrote:

forse sbaglio perchè non ho verificato ma a ad'occhio vengono loggati
nella history del sistema dove ci siamo connessi. Insomma, ci sono due
history, una history per directory home

se intendi che vengono loggate nel sistema remoto certamente hai ragione
ma questo vorrebbe dire che su un server ssh è possibile eseguire
comandi di cui non rimane traccia sul server stesso? Forse è normale ma >credo mi sfugga qualcosa 😕...

La shell, quando è in modo interattivo e la history non è disabilitata o cancellata, registra i comandi immessi.

Questo vale sia da un login locale che da un login remoto, in entrambi i casi è una shell interattiva.

Ma se ho ben capito, tu parli dei comandi eseguiti direttamente dal comando ssh, per esempio facendo "ssh nome.host.it ls -l" per vedere la lista dei file remoti nella directory remota. Se non erro quel comando "ls -l" non viene registrato in remoto
perché la shell eseguita sul sistema remoto non è interattiva. Se è eseguito da una shell locale interattiva, il comando "ssh nome.host.it ls -l" viene registrato sul sistema locale.

-- fp

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[1:text/plain Show]

[2:text/html Hide Save:noname (1kB)]

On 11/27/24 23:43, Francesco Potortì wrote:

[...]
Ma se ho ben capito, tu parli dei comandi eseguiti direttamente dal comando ssh, per esempio facendo "ssh nome.host.it ls -l" per vedere la lista dei file remoti nella directory remota. Se non erro quel comando "ls -l" non viene registrato in remoto

perché la shell eseguita sul sistema remoto non è interattiva. Se è eseguito da una shell locale interattiva, il comando "ssh nome.host.it ls -l" viene registrato sul sistema locale.

si parlo proprio dell'esecuzione di un comando shell all'interno della comando ssh; quindi è proprio così, i
comandi eseguiti direttamente da remoto tramite ssh non vanno a finire nella bash_history... anche se
quelli eseguiti direttamente da un comando ssh un po' interattivi sono: si possono lanciare ad esempio i
comandi apt e rispondere interattivamente... comunque se è così è così. Grazie mille, anche oggi ho
imparato una cosa nuova.

Per un'idea veloce di come funziona, puoi dare un'occhiata al man di una shell e cercare la parola "interactive".

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is a multi-part message in MIME format.
On 11/27/24 23:43, Francesco Potortì wrote:

[...]
Ma se ho ben capito, tu parli dei comandi eseguiti direttamente dal comando ssh, per esempio facendo "ssh nome.host.it ls -l" per vedere la lista dei file remoti nella directory remota. Se non erro quel comando "ls -l" non viene registrato in remoto

perché la shell eseguita sul sistema remoto non è interattiva. Se è eseguito da una shell locale interattiva, il comando "ssh nome.host.it ls -l" viene registrato sul sistema locale.

si parlo proprio dell'esecuzione di un comando shell all'interno della
comando ssh; quindi è proprio così, i comandi eseguiti direttamente da
remoto tramite ssh non vanno a finire nella bash_history... anche se
quelli eseguiti direttamente da un comando ssh un po' interattivi sono:
si possono lanciare ad esempio i comandi apt e rispondere
interattivamente... comunque se è così è così. Grazie mille, anche oggi
ho imparato una cosa nuova.

Buona giornata a tutti

Piviul

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 11/27/24 23:43, Francesco Potortì
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:E1tGQkz-0000000Gyn2-0zFC@tucano.isti.cnr.it">[...]<span
style="white-space: pre-wrap">
</span>
<pre class="moz-quote-pre" wrap="">Ma se ho ben capito, tu parli dei comandi eseguiti direttamente dal comando ssh, per esempio facendo "ssh nome.host.it ls -l" per vedere la lista dei file remoti nella directory remota. Se non erro quel comando "
ls -l" non viene registrato in remoto perché la shell eseguita sul sistema remoto non è interattiva. Se è eseguito da una shell locale interattiva, il comando "ssh nome.host.it ls -l" viene registrato sul sistema locale.</pre>
</blockquote>
<p>si parlo proprio dell'esecuzione di un comando shell all'interno
della comando ssh; quindi è proprio così, i comandi eseguiti
direttamente da remoto tramite ssh non vanno a finire nella
bash_history... anche se quelli eseguiti direttamente da un
comando ssh un po' interattivi sono: si possono lanciare ad
esempio i comandi apt e rispondere interattivamente... comunque se
è così è così. Grazie mille, anche oggi ho imparato una cosa
nuova.</p>
<p>Buona giornata a tutti<br>
</p>
<p>Piviul<br>
</p>
</body>
</html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Mandi! Piviul
In chel di` si favelave...

si parlo proprio dell'esecuzione di un comando shell all'interno della comando ssh; quindi è proprio così, i comandi eseguiti direttamente da remoto tramite ssh non vanno a finire nella bash_history... anche se

...diciamo che finiscono nella history della shell di partenza, non nella destinazione di ssh.

--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Il giorno gio, 28/11/2024 alle 16.49 +0100, Piviul ha scritto:

On 11/27/24 23:43, Francesco Potortì wrote:

[...]

si parlo proprio dell'esecuzione di un comando shell all'interno
della comando ssh; quindi è proprio così, i comandi eseguiti
direttamente da remoto tramite ssh non vanno a finire nella
bash_history... anche se quelli eseguiti direttamente da un comando
ssh un po' interattivi sono: si possono lanciare ad esempio i comandi
apt e rispondere interattivamente... comunque se è così è così.
Grazie mille, anche oggi ho imparato una cosa nuova.

La pagina di manuale di ssh lo chiarisce, in effetti:

If a command is specified, it will be executed on the remote host instead of
a login shell. A complete command line may be specified as command, or it
may have additional arguments. If supplied, the arguments will be appended
to the command, separated by spaces, before it is sent to the server to be
executed.

Se viene passato un comando qualsiasi, questo viene eseguito *al posto*
della shell, e quindi non ci può essere nessuna cronologia.

Ciao,
Giuseppe

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Piviul

io mi sarei aspettato che tutti i comandi eseguiti sulla
shell da un utente sia da locale che da remoto fossero loggati nella
history dell'utente

avete già chiarito il problema dell'esecuzione di un comando
direttamente tramite ssh.

Però non è vero che un comando eseguito da una shell interattiva venga loggato nella history, perché è possibile eseguire un comando indicando
che non venga qui inserito. Per fare questo basta semplicemente far
precedere il comando da uno spazio

Quindi se eseguo
$ echo Ciao

il comando è salvato nella history

Se però eseguo
$ echo Riciao

in questo caso questo coamndo non è salvato nella history.

Notare che vi sono due spazi tra $ e echo, il primo è lo spazio del
prompt, il secondo l'ho aggiunto io.

Quindi se volete eseguire un comando, ma non volete che venga salvato
nella histroy, ora sapete come fare.
Io uso questo per evitare che eseguendo qualcosa poi quando faccio
Ctrl-R mi presenti quel comando e non quello che eseguo più spesso.

Ciao
Davide

--
La mia privacy non è affar tuo
https://noyb.eu/it
- You do not have my permission to use this email to train an AI -
If you use this to train your AI than you accept to distribute under AGPL license >= 3.0 all the model trained, all the source you have used to
training your model and all the source of the program that use that model

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Il giorno dom, 01/12/2024 alle 10.22 +0100, Davide Prina ha scritto:

è possibile eseguire un comando indicando
che non venga qui inserito. Per fare questo basta semplicemente far
precedere il comando da uno spazio

Vero. :-)

Per la shell bash, tuttavia, questo vale solo se la variabile HISTCONTROL, reperibile nel file ~/.bashrc, contiene il valore "ignorespace" o "ignoreboth".

Per la shell zsh, similmente, dev'esserci invece
setopt HIST_IGNORE_SPACE
in ~/.zshrc.

Piuttosto utile, in bash, la variabile HISTIGNORE, che consente di definire quali
comandi non vanno mai salvati.

Normalmente la uso anche con un'altra finalità.
Vi è mai capitato di digitare la password di sudo, non accorgendovi di aver commesso un'errore di digitazione nel comando, e che quindi non c'è nessun sudo che stia aspettando la password?
E dove finisce la password, bella in chiaro? :-0

Usando una password del tipo "999password", allora
HISTIGNORE="999"
IMHO diventa bello comodo. :-)
--
Bye, Lem

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Il giorno dom, 01/12/2024 alle 11.39 +0100, Lem ha scritto:

HISTIGNORE="999"

Errata corrige:

HISTIGNORE="999*"

ovviamente. Mi scuso.
--
Bye, Lem

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/1/24 12:00, Lem wrote:

Il giorno dom, 01/12/2024 alle 11.39 +0100, Lem ha scritto:

HISTIGNORE="999"

Errata corrige:

HISTIGNORE="999*"

Nel caso specifico però identifichi parte della password in un file...
certo, non è come lasciarla in chiaro nella history. Comunque in questo
caso io preferisco andare indietro nella history ed eliminare la
password data per errore senza però premere invio; in questo modo verrà eliminata anche dalla history.

Piviul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/27/24 08:52, Piviul wrote:

Ciao a tutti, io mi sarei aspettato che tutti i comandi eseguiti sulla
shell da un utente sia da locale che da remoto fossero loggati nella
history dell'utente. Ho notato invece che i comandi shell inviati
tramite ssh non vanno a finire nella history... è giusto che sia così? Vengono loggati da qualche altra parte?

Grazie mille a tutti quanti, sempre interessante questa mailing list ;)

Piviul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Il giorno mer, 04/12/2024 alle 08.10 +0100, Piviul ha scritto:

On 12/1/24 12:00, Lem wrote:

Il giorno dom, 01/12/2024 alle 11.39 +0100, Lem ha scritto:

HISTIGNORE="999"

Errata corrige:

HISTIGNORE="999*"

Nel caso specifico però identifichi parte della password in un file...

Beh... in realtà sto rivelando solo un banale prefisso, che premetto alla password unicamente perché possa essere filtrato.

io preferisco andare indietro nella history ed eliminare la
password data per errore senza però premere invio; in questo modo verrà eliminata anche dalla history.

Generalmente, potendo, io preferisco automatizzare: i computer sono una
favola, per automatizzare... ;)
--
Bye, Lem

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is a multi-part message in MIME format.
On 12/4/24 21:19, Lem wrote:

Generalmente, potendo, io preferisco automatizzare: i computer sono una favola, per automatizzare... ;)

...e in un mondo libero per poter raggiungere lo stesso scopo in modi
diversi, in modo che poi ognuno possa scegliere quello che più gli si
adatta.

Piviul

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 12/4/24 21:19, Lem wrote:<br>
</div>
<blockquote type="cite" cite="mid:91fc000fdbf3fb7678980f7dd892be6b5f020763.camel@ikmail.com"><span
style="white-space: pre-wrap">
</span>
<pre class="moz-quote-pre" wrap="">Generalmente, potendo, io preferisco automatizzare: i computer sono una
favola, per automatizzare... ;)</pre>
</blockquote>
<p>...e in un mondo libero per poter raggiungere lo stesso scopo in
modi diversi, in modo che poi ognuno possa scegliere quello che
più gli si adatta.</p>
<p>Piviul<br>
</p>
</body>
</html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Il giorno gio, 05/12/2024 alle 08.07 +0100, Piviul ha scritto:

 On 12/4/24 21:19, Lem wrote: 

Generalmente, potendo, io preferisco automatizzare: i computer sono una favola, per automatizzare... ;)

...e in un mondo libero per poter raggiungere lo stesso scopo in modi diversi, in modo che poi ognuno possa scegliere quello che più gli si adatta.

Sono più che d'accordo che la libertà sia una bella cosa. :-)

Penso però che spesso, per fare le cose, ci siano metodi oggettivamente più efficaci ed efficienti di altri. E che quindi, una volta conosciutili, sia sensato
adottarli. Per questo ho segnalato questo mio, che a me pare avere un vantaggio oggettivo, senza alcuno svantaggio.

Poi ciascuno, nel suo privato, si comporti come crede. Ci mancherebbe!
--
Bye, Lem

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Mandi! Piviul
In chel di` si favelave...

Nel caso specifico però identifichi parte della password in un file... certo, non è come lasciarla in chiaro nella history. Comunque in questo
caso io preferisco andare indietro nella history ed eliminare la
password data per errore senza però premere invio; in questo modo verrà eliminata anche dalla history.

Io di solito, se mi capita, digito:

HISTFILE=''

quindi esco dalla shell e rientro. In pratica gli sto dicendo che il file di history è vuoto, quindi lui non salva nulla all'uscita della sessione corrnete, password compresa.

--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/5/24 21:08, Marco Gaiarin wrote:

Mandi! Piviul
In chel di` si favelave...

Nel caso specifico però identifichi parte della password in un file...
certo, non è come lasciarla in chiaro nella history. Comunque in questo
caso io preferisco andare indietro nella history ed eliminare la
password data per errore senza però premere invio; in questo modo verrà
eliminata anche dalla history.

Io di solito, se mi capita, digito:

HISTFILE=''

quindi esco dalla shell e rientro. In pratica gli sto dicendo che il file di history è vuoto, quindi lui non salva nulla all'uscita della sessione corrnete, password compresa.

interessante, grazie Marco!

Piviul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 6 Dec 2024 at 00:50, Marco Gaiarin <gaio@lilliput.linux.it> wrote:

Io di solito, se mi capita, digito:

HISTFILE=''

quindi esco dalla shell e rientro. In pratica gli sto dicendo che il file di history è vuoto, quindi lui non salva nulla all'uscita della sessione corrnete, password compresa.

Paolo Nicorelli:

idem con
$ history -r

A leggere il manuale, in Bash, `history -c` cancella la storia attuale (quella in memoria), quindi è sufficiente per cancellare cose che non si vogliono registrare, e non c'è bisogno di uscire dalla shell. In pratica è l'unico comando history che
abbia mai usato.

Invece `history -r` credo che serva eventualmente solo dopo un `history -r`, per ripopolare la lista (in memoria) dopo averla cancellata con `history -c`. Sbaglio?

cmq lo spazio prima del cmd mi era nuova: thanks folks!!!

Anch'io non la sapevo :)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Invece `history -r` credo che serva eventualmente solo dopo un `history -r`, per ripopolare la lista (in memoria) dopo averla cancellata con `history -c`. Sbaglio?

Doveva essere:

Invece `history -r` credo che serva eventualmente per ripopolare la lista (in memoria) dopo averla cancellata con `history -c`. Sbaglio?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/6/24 11:35, Francesco Potortì wrote:

Invece `history -r` credo che serva eventualmente solo dopo un `history -r`, per ripopolare la lista (in memoria) dopo averla cancellata con `history -c`. Sbaglio?

Doveva essere:

Invece `history -r` credo che serva eventualmente per ripopolare la lista (in memoria) dopo averla cancellata con `history -c`. Sbaglio?

scusate ma dove trovate le informazioni sui parametri da passare ad
history? Con un man history o info history non trovo nulla...

Piviul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Il 06/12/24 11:43, Piviul ha scritto:

scusate ma dove trovate le informazioni sui parametri da passare ad
history? Con un man history o info history non trovo nulla...

history e' un comando interno a bash, quindi man bash.


M.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

scusate ma dove trovate le informazioni sui parametri da passare ad
history? Con un man history o info history non trovo nulla...

history e' un comando interno a bash, quindi man bash.

O anche, da dentro Bash: `help history`

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/6/24 11:59, Francesco Potortì wrote:

scusate ma dove trovate le informazioni sui parametri da passare ad
history? Con un man history o info history non trovo nulla...

history e' un comando interno a bash, quindi man bash.

O anche, da dentro Bash: `help history`

😳 grazie a entrambi

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)