Come determinare la causa della tubatura rotta SSH

Question

Come determinare la causa della tubatura rotta SSH

#1 da (1 voti)
#2 da (0 voti)

0

Nell'ultima settimana, la mia connessione SSH a un'istanza di Amazon EC2 continua a essere disconnessa con

Write failed: Broken pipe

Leggendo alcuni siti, ho pensato che non fosse impostato alcun timeout, quindi ho creato un file ~/.ssh/config come segue basato su

### Stop timing out connections
ServerAliveInterval 120  
ServerAliveCountMax 20  

TCPKeepAlive yes

### SSH Connection pooling for faster additional connections to a machine
ControlMaster auto  
ControlPath /tmp/ssh_mux_%h_%p_%r

Host *  
  ControlMaster auto  
  ControlPath ~/.ssh/control/%r@%h:%p  
  ControlPersist 3600  

### Make it so ssh-ing from one server to another passes keys around automagically
Host *
ForwardAgent yes

### Get rid of SSH connection delays
GSSAPIAuthentication no

### Use less encryption on servers I cant get to off-network
Host 10.* 172.* 192.168.*  
Ciphers blowfish-cbc

Queste impostazioni non sembravano avere un effetto, eppure mi sono reso conto che quando sono non a casa, la connessione rimane inattiva come ha fatto per l'ultimo anno. Ho eseguito l'ssh nell'istanza su due reti separate diverse dalla mia rete Wi-Fi, quindi suppongo che ci sia qualcosa che è successo a casa nelle ultime due settimane per cambiare il comportamento della connessione SSH.

Usando Wireshark o altrimenti come posso seguire / diagnosticare quale / dove si verifica il problema dei tubi SSH danneggiati sulla mia rete domestica?

con

Mac OS 10.7.5
OpenSSH_5.6p1, OpenSSL 0.9.8r 8 febbraio 2011
Amazon EC2 AMI t1.micro

wifi ssh

posta phwd 19.06.2013 - 15:38

fonte

2 risposte

Leggi altre domande sui tag wifi ssh

Il Finder non ritorna dopo l'arresto o "killall" [chiuso] Impossibile avviare il file di classe Java all'avvio

score 1 · Answer 1

Controlla le impostazioni di keep alive locali sul tuo Mac. Questi erano i miei ...:

sysctl -a | grep tcp.keep
net.inet.tcp.keepidle: 3600
net.inet.tcp.keepintvl: 150
net.inet.tcp.keepinit: 75000
net.inet.tcp.keepcnt: 8

Avevo bisogno di cambiare l'impostazione di keepintvl con un valore più alto:

sudo sysctl -w net.inet.tcp.keepintvl=7500

Quindi i messaggi di errore ssh "write failed: Broken pipe" sono scomparsi.

score 0 · Answer 2

Non si indica quale sistema operativo è in esecuzione sulla propria istanza EC2. Supponiamo che sia una variante di Linux.

La prima cosa che dovresti fare è aumentare la quantità di logging fornita dal tuo SSHD. Hai due modi per farlo. È possibile modificare le opzioni in modo che SSHD inizi sempre con i flag di debug oppure è possibile avviare un'altra istanza su una porta non standard. Ad ogni modo, il segreto per ottenere l'output di debug è usare -d. Dalla pagina man su un server Mint (variante Ubuntu)

-d Debug mode. The server sends verbose debug output to standard error, and does not put itself in the background. The server also will not fork and will only process one connection. This option is only intended for debugging for the server. Multiple -d options increase the debugging level. Maximum is 3.

Dal tuo client, puoi usare le opzioni dettagliate per ssh TO sul server, come ssh -vvv [email protected] -p port che hai usato per il tuo sshd.

Un'altra cosa che ti suggerisco è di eliminare la maggior parte degli elementi nel tuo file di configurazione, solo per assicurarti di non aggiungere al problema.

Nessuna di queste cose è una risposta, ma potrebbero farti avvicinare ad una.