Newsgroup: it.comp.os.linux.sys
Titolo: Connessione SSH che va in freeze

Buongiorno a tutti,
ho "ereditato" la gestione di un firewall "inutile" presso un'azienda 
locale.
"Ereditato" perchè abbiamo un contratto di manutenzione di tutti i pc 
aziendali.
"Inutile" perchè non ha alcuna regola se non il NAT ed è dietro un 
router Pirelli con il port forwarding della sola 22.
Il problema è che se mi collego in ssh dall'esterno ed eseguo un 
comando dicretamente verboso tipo "ls -l /etc" dopo qualche carattere 
ricevuto la connessione si pianta e resta lì appesa senza poter fare 
più nulla.
Ripeto, iptables non contiene alcun rate limit, non c'è traffic 
control, ecc..
Cosa diavolo devo controllare (tenendo conto che non posso eseguire 
comandi discretamente verbosi come iptables -nvL...) ?
Ah, aggiungo che se imposto un tunnel con Putty verso un'altra 
macchina.. dato che il tunnel passa per la connessione ssh, mi si 
pianta tutto alla prima richiesta.
Il firewall è fatto con Ubuntu 7.04, kernel 2.6.20-15-server e sshd 
4.3p2
Mauro
-- 
Mauro D.

 
hai provato ad attivare una connessione ssh DA quella macchina aprendo 
poi un tunnel su questa seconda connessione?
da quella macchina fai una connessione ssh verso un tuo server attivando 
un tunnel da usare poi per ritornare su quella macchina.
macchinoso e contorto, ma magari in questo modo riesci a ottenere una 
connessione ssh utilizzabile per la risoluzione del problema.
-- 
Paolo opg
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--

 comandi discretamente verbosi come iptables -nvL...) ?
1) TCP MSS
2) window scaling
-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/

 
mi hai tolto la frase dalle dita..
S.


Già provato... non funziona.. putroppo devo aprire la connessione da 
quel server e quindi devo farlo tramite una connessione verso quel 
server.
Quando dal tunnel riesco ad entrare in ssh è già tardi... si pianta 
tutto al primo comando. Veramente non so che diavolo accada.
-- 
Mauro D.

 Davide
Dove posso verificarlo? le interfacce hanno tutte MTU 1500
Mauro
-- 
Mauro D.


Tutti i pacchetti che transitano (fino alla morte della connessione 
sono al massimo lunghi 300 bytes, fonte WireShark) non capisco..
-- 
Mauro D.

 2) window scaling
Mi correggo.. la connessione ssh rimane in piedi... con Wireshark vedo 
che per ogni carattere che invio mi ritorna l'ACK da parte del server 
SSH, solo che la console rimane piantata.
Con questo nuovo dettaglio vi viene in mente qualcosa?
-- 
Mauro D.

 router Pirelli con il port forwarding della sola 22.
C'è solo il firewall attaccato al Pirelli?
Nel senso: usano il Pirelli solo per ssh visto che tutte le altre porte sono 
chiuse? Non mi dire che non usano internet.
Nicola.
-- 
chi va pian va san e va lontan

 Nicola.
C'è il Pirelli, poi c'è il firewall con due schede di rete e poi c'è la 
rete.
La mia bassa conoscenza di reti mi suggerisce che il Pirelli fa il NAT 
della rete privata in cui c'è solo il firewall che a sua volta fa il 
NAT della sua rete privata che poi è quella aziendale.
C'è modo di ricevere qualche attacco dall'esterno verso la rete 
aziendale se non metto regole di blocco sul firewall dato che l'unica 
porta in forward è quella per SSH mappata all'esterno su una porta tipo 
2476?
Mauro
-- 
Mauro D.

 locale.
leggi questo.
http://embraceubuntu.com/2006/02/03/keeping-ssh-sessions-alive/
io l'ho dovuto abilitare altrimenti mi freezavano le connessioni 
dall'interno della rete aziendale a server esterni.
e c'e' sempre il pirellone di mezzo.
e' un parametro da impostare sul client ssh
 

 e' un parametro da impostare sul client ssh
Ma non è quello.
Il freeze avviene dopo un grosso output, non dopo inattività.
Succede anche a me, tra parentesi ed il problema non è ne il windows 
scaling nè l'MSS.

 Il freeze avviene dopo un grosso output, non dopo inattività.
ah giusto... e dire che stamattina stavo per rispondere come ho fatto e 
ho lasciato perdere


Quindi qual'è il problema?
Tu ne sei venuto a capo?
-- 
Mauro D.

 più nulla.
  Con che client ti colleghi? Su alcuni server è capitata una cosa simile, 
cambiando versione/tipo di client ssh però la connessione funziona bene; la 
cosa strana è che il comportamento è casuale (a volte va male putty, a volte 
openssh, a volte securecrt ... )
-- 
Non pretendo che comprendiate il significato di quello che ho scritto senza 
averlo riletto un certo numero di volte. Personalmente, vi riterrei degli 
stupidi se lo faceste. Io l'ho letto sei volte ed ancora non l'ho capito.

 openssh, a volte securecrt ... )
Ho provato sia Putty che OpenSSH 5.5 ma niente da fare. Quando decide 
di piantarsi si pianta.
Quello che non capisco è che la connessione sembra rimanere in piedi e 
i caratteri che premo vengono spediti al server.
Mauro
-- 
Mauro D.

 caratteri che premo vengono spediti al server.
Forse è un problema del terminale eseguito sulla macchina remota, prova magari a 
lanciare un'altro tipo di shell o verifica i settaggi della console
Rizio
-- 
Si vis pacem para bellum

 Rizio
Buona idea, purtroppo hanno il brutto vizio di spegnere tutte le 
macchine dell'ufficio quando non lavorano... come il venerdì 
pomeriggio!!
Lunedì faccio subito la prova di cambiare la shell di default 
dell'utente con il quale mi connetto e vediamo se migliora.
Grazie
-- 
Mauro D.

 4.3p2
  Mi viene in mente anche un'altra cosa: hai possibilità di accedere alla 
macchina ed aggiornare quantomeno l'sshd? (e magari di verificare se vi 
siano bug sull'sshd segnalati per quella versione di ubuntu)


 Tu ne sei venuto a capo?
No, non mi sono molto posto il problema.
L'ho solo sperimentato.

 router Pirelli con il port forwarding della sola 22.
il firewall del pirelli e' disattivato?


Non c'è firewall sul router Pirelli .. Alice.
Puoi solo impostare che ip sono nattati e se vuoi dei virtual server.
-- 
Mauro D.

 Puoi solo impostare che ip sono nattati e se vuoi dei virtual server.
ok, su quello che ho qui c'e'...

control, ecc..
Ho sperimentato lo stesso sintomo con lo stesso setup, ma con connessioni
uscenti (Windows --> Pirelli --> TI --> Wind --> casa mia --> Linux); non
che debba necessariamente fare differenza.
Dato che apparentemente pacchetti piccoli passavano, ma il primo paccotto
grosso piantava tutto, ho imputato il problema alla MTU. E in effetti con
MTU = 1499, trovata per bisezione[1], **mi pare** funzionasse.
Leonardo S.E.&O.
[1] <murphy>1499 è il caso peggiore se si parte da 1000 e 1500</murphy>
-- 
Enough, enough!  But, stranger, ere we part,
Glancing farewell to each nefarious bier,
This warning would I beg you take to heart:
There is an end to e'en the worst career!

Mandi! Mauro D.
  In chel dì si favelave...
MD> Cosa diavolo devo controllare (tenendo conto che non posso eseguire 
MD> comandi discretamente verbosi come iptables -nvL...) ?
/usr/share/doc/ppp/README.Debian.gz, alla voce 'MSS clamping'.
Risolto queso, ti resterebbe il problema delle connessoni idle che
vengono troncate perchè il roter ha una tabella di nat limitata, ma
con questa ci sopravvivi... ;-)))
-- 
  Io credo nella chimica tanto quanto Giulio Cesare credeva nel caso...
  mi va bene fino a quando non riguarda me :)	(Emanuele Pucciarelli)

 2476?
Oh, beh, non sono un cracker. Io per sicurezza ho un filtro positivo di IP 
esterni abilitati ad entrare sulla 22. Tutti gli altri li sego.


 2) window scaling
Quoto. :)