Newsgroup: it.comp.os.linux.iniziare
Titolo: Sessione ssh: killare automaticamente precedenti sshd

Dunque, mi collego ad un server ssh su cui ho a disposizione
una shell unix e accesso come semplice utente.
Mi capita che la mia connessione cade e che il processo sshd sul
server resti appeso.
Quando mi riconnetto e rieffettuo la connessione via ssh, se d�:
ps -A|grep sshd
vedo 2 processi sshd: uno � quello vecchio e l'altro � quello
nuovo che sta tenendo in piedi la mia attuale sessione ssh.
Ora io vorrei uno script in grado di:
killare eventuali sessioni attuali ssh locali (quinid sul mio
sistema locale).
Avviare una nuova sessione ssh verso il server
e una volta loggato sul server, killare tutti i processi sshd
TRANNE il processo corrente che sta tenedo in piedi l'attuale
sessione ssh.
Questo pezzo di script lo aggiungerei ad un'altro pezzo che si
occupa di reindirizzare alcune porte locali attraverso verso il
server ssh, creando cos� una specie di tunnel. (ne avevo parlato
in qualche post addietro).
Sto facendo qualche prova con la sintassi base:
ssh user@host COMMAND
dove COMMAND potrebbe essere il pezzo di scripting che verifica
eventuali sessioni sshd appese e le killa.
Ma non saprei come individuare la sessione sshd corrente per
escluderla dal killing.
Spero in qualche vostra idea. Grazie in anticipo.  :-)

 sessione ssh.
  Così facendo, ammesso che il tuo utente abbia i diritti di mandare un
segnale ad un processo di root, killeresti il processo master sshd e
quindi impediresti tutte le sessioni sshd successive.
  Ciao,
-- 
Alessandro Selli 
http://alessandro.route-add.net
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.

  Cos� facendo, ammesso che il tuo utente abbia i diritti di mandare un


 ssh, ma l'intera connessione ad internet col mio isp.
]zac[
Probabilmente ricordo male, ma sshd potrebbe/dovrebbe avere un timeout di
chiusura delle sessioni rimaste aperte.

 avere un timeout di chiusura delle sessioni rimaste aperte.
S�, confermo, ma a quanto pare sul lato server questo timeout �
troppo lungo.
Ora vedo un po' cosa riesco a tirar fuori... grazie ancora.

 troppo lungo.
man sshd_config
e cerchi:
ClientAliveInterval
e
ClientAliveCountMax
se ho capito bene il problema (vado di fretta...)
-- 
Fr3ddie
fr3...@fr3ddie.it
Home Page: 
http://www.fr3ddie.it
OpenPGP Public Key available on my website
Non c'è niente di più pericoloso di un cretino che ha ragione per caso

 ClientAliveCountMax
Probabilmente il file di configurazione a cui ti stai riferendo �
/etc/ssh/sshd_config.
Nel mio caso stiamo parlando di accesso ssh ad una free-shell
remota. Come ho gi� detto, ho accesso a quel sistema solo come
semplice utente, non certo come root.
Tuttavia i processi sshd appesi e relativi a mie precedenti
sessioni ssh, sono controllabili da me: posso killarli senza
problemi.


Ma se non sei amministratore di quel sistema, perche' vuoi
contestare la politica con cui e' erogato il servizio sshd?
Se le sessioni non vengono ammazzate subito, magari e' una scelta
consapevole dell'amministratore. A parte il lato accademico,
a te che importa se ci sono sessioni zombie? Non comportano
rischi, e le puoi chiudere quando esci correttamente da una sessione ssh.

 rischi, e le puoi chiudere quando esci correttamente da una sessione ssh.
Bella domanda...
In alcuni casi mi sono accorto che dopo qualche riconnessione le
cose non funzionano pi� bene, forse perch� giustamente
l'amministrazione del sistema limita ad un certo numero le
sessioni sshd appese, magari interpretandole come processi in
background...ma la butto l�.
In effetti hai ragione, prima di tirare conclusioni affrettate
dovrei testare meglio le cose.
Usando questo servizio principalmente per tunneling (port
forwarding) over ssh, non ho quasi mai l'occasione di accedere
alla shell tramite normale login interattivo. Di solito lo faccio
proprio apposta per ripulire un po' la situzione. Cone che ogni
mezzora la mia connessione cade e riconnettendomi rieffettuo una
nuova sessione ssh.
Killando i processi remoti appesi ho notato che le cose tornano
apposto...ma come ho detto, non hai tuttii torti, in quanto devo
testare meglio quando sorge il problema, cio� dopo quanto non mi
� pi� possibile effettuare tunneling.
Saluti.

 non saprei:
   Te lo dice ps:
[alessandro@rocca ~]$ ps uww -C sshd
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      1453  0.0  0.2   7632  1076 ?        Ss   11:16   0:00 
/usr/sbin/sshd
root      2810  0.0  0.5  10568  2936 ?        Ss   11:55   0:00 sshd: 
alessandro [priv]
alessandro   2825  0.0  0.3  10568  1676 ?        S    11:55   0:00 sshd: 
alessandro@pts/2
   In ogni caso, non puoi intervenire sui processi di sistema (del 
superutente root, ossia) da utente privilegiato.  Volessi cambiare il 
tempo di timeout delle connessioni che instauri su un server remoto, puoi 
intervenire sul file ~/.ssh/config del tuo utente e impostare questi 
parametri (da ssh_config(5)):
      ConnectTimeout
              Specifies the timeout (in seconds) used when connecting to
              the SSH server, instead of using the default system TCP
              timeout.  This value is used only when the target is down or
              really unreachable, not when it refuses the connection.
      ServerAliveInterval
              Sets a timeout interval in seconds after which if no data
              has been received from the server, ssh(1) will send a mes-
              sage through the encrypted channel to request a response
              from the server.  The default is 0, indicating that these
              messages will not be sent to the server.  This option
              applies to protocol version 2 only.
    Ciao,
-- 
Alessandro Selli 
http://alessandro.route-add.net
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.
Chiave PGP/GPG: EC885A8B

      ServerAliveInterval
Per�....questa impostazione la potrei fare lato server...
Ma in tal modo non mi servirebbe a nulla, perch� quando cade la
linea....i processi sshd restano appesi sul server remoto non
sulla mia macchina locale da cui faccio girare il client ssh.
Non ti pare?
Cio� anche se il mio ssh locale giungesse rapidamente al timeout
muorendo, in remoto resterebbero comunque appesi i processi sshd.
Questo perch� � la connessione fisica ad internet che � caduta...
Non so se mi spiego. In soldoni io a naso direi che bisogna agire
sul sistema remoto...forse in un eventuale file di configurazione
di sshd per singolo utente...qualcosa tipo ~/.ssh/sshd_config,
che francamente non so neanche se poi esista.
Saluti.

 Non ti pare?
  Si,  vero.  Quello che ti servirebbe  di impostare queste voci in
sshd_config piuttosto:
	ClientAliveCountMax
		Sets the number of client alive messages (see
		below) which may be sent without sshd(8)
		receiving any messages back from the client.
		If this threshold is reached while client alive
		messages are being sent, sshd will disconnect
		the client, terminating the session.
	ClientAliveInterval
		Sets a timeout interval in seconds after which if
		no data has been received from the client,
		sshd(8) will send a message through the encrypted
		channel to request a response from the client.
		The default is 0, indicating that these messages
		will not be sent to the client.  This option
		applies to protocol version 2 only.
  Ma sono voci del file di configurazione del server, e per modificarle
ti servirà la password di root.


 per modificarle ti servir� la password di root.
Appunto...quindi devo eventualmente cercare una via alternativa.
Prima per� voglio valutarese questo fatto degli sshd appesi
comporta realmente problemi, oppure � ininfluente.
Grazie comunque delle risposte  :-)