website/bugs/cssh-connection-timeout.mdwn

   1 [[!meta title="Monkeysphere interferes with clusterssh"]]
   2
   3 clusterssh is a package that allows you to control multiple ssh xterm
   4 sessions at the same time.
   5
   6 When the monkeysphere-ssh-proxycommand is enabled and I launch 5 or more
   7 cssh sessions, intermittently one or two out of every five will fail
   8 with: Connection timed out during banner exchange.
   9
  10 I tried to debug by running:
  11
  12     MONKEYSPHERE_LOG_LEVEL=debug cssh -D -d <server1> <server2> etc.
  13
  14 However, while it produced some private data, it didn't give me any
  15 insight into what was going wrong. Also, it didn't output any
  16 Monkeysphere debugging info.
  17
  18 I had no luck with google and the error message being output.
  19
  20 This isn't a huge priority (it's not hard to disable the
  21 monkeysphere-ssh-proxycommand before running cssh), however, it would be
  22 nice to figure out why it's not working.
  23
  24 ---
  25
  26 What do you mean by "produced some private data" when you set the log
  27 level to DEBUG?  Monkeysphere does not output any "private" data in
  28 the sense of private keys or passwords or anything like that.  Maybe
  29 you mean the cssh debug mode outputs private data?  or do you just
  30 mean "info that you don't want to post here"?  It might be useful to
  31 see some output, so maybe you could just block out the nasty bits?
  32 But I'm not sure it will help.
  33
  34 The problem may be due to the locking of the known\_hosts file while
  35 the proxycommand is running.  At the moment, the
  36 monkeysphere-ssh-proxycommand can only be run serially, since each
  37 invocation will lock the known\_hosts file while it updates it.  I
  38 think this is required, since we obviously can't have two invocations
  39 modifying the file at the same time.  However, it's probably possible
  40 to decrease the amount of time it takes to update the file.  It's not
  41 done very efficiently at the moment.  The file is locked basically at
  42 the very begining, and is locked while all gpg interactions are done,
  43 which are slow.  I think it should be possible to take the gpg
  44 interactions out of the loop.
  45
  46 I just tried cssh and it doesn't seem to work very well with my ssh
  47 setup at all.  For instance, the simultaneous ssh connections cause
  48 simultaneous calls to the agent to get my permission to use the key,
  49 which don't interact very well with each other.  This of course is not
  50 a monkeysphere problem but a general problem with trying to make
  51 simultaneous ssh connections with an agent that want key use
  52 confirmation.
  53
  54 -- jrollins
  55
  56 ---
  57
  58 I can get cssh to work fine with a confirmation-required agent if i
  59 turn off the monkeysphere proxycommand:
  60
  61     cssh -l username -o '-oProxyCommand=none' $(cat hostlist.txt)
  62
  63 with the proxycommand, i definitely get the "Connection timed out
  64 during banner exchange" message.
  65
  66 However, i'm also able to get the cssh connection to work if i assert
  67 that a longer connection timeout is acceptable:
  68
  69     cssh -l username -o '-oConnectTimeout=30' $(cat hostlist.txt)
  70
  71 Perhaps this is an acceptable workaround?
  72
  73 -- dkg
  74
  75 ---
  76
  77 Sorry for not being more clear. Monkeysphere debug does not reveal personal
  78 information - but cluster cssh -d -D exposes the hosts in my ssh config file.
  79
  80 dkg's approach seems to work. His suggestion, as written, didn't work for me.
  81 But that's because I ran cssh -u > $HOME/.csshrc, which generates a default
  82 cssh config file (that specifies ConnectTimeout=10). That file seems to
  83 override the command linke (perhaps a cssh bug?). I changed the ConnectTimeout
  84 to 30 in my ~/.csshrc file and now everything works.
  85
  86 I think jrollins' assessment is probably right - the extra delay due to locking
  87 causes the timeout. I think tweaking ConnectTimeout parameter via the .csshrc
  88 file or via the command line is a reasonable fix for this bug, so I'm closing
  89 as [[bugs/done]].
  90
  91 -- Sir Jam Jam
  92
  93 I just [posted the cssh bug in debian](http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498968).