On: SSH Multiplexing & other OpenSSH Tricks

[mst]

I do wish keepalive could be turned on/off more dynamically - most of the locations I connect from it's a disadvantage so I don't have it configured, and having to edit the config file when I'm in one where it's useful just annoys me.

I suppose I should just write a script that perl -pi -e 's/KeepAlive yes/KeepAlive no/' .ssh/config or similar, but it still seems ... annoying.

[slug → mst]

You can create 'fake' hosts but with the same hostname:

  ~/.ssh/config
  Host serverWith
      HostName server.home.net
      OptionBLA yes

  Host serverWithout
      HostName server.home.net
      OptionBLA no

It also has autocomplete, so you can type ssh server<TAB>

[JoachimSchipper → slug]

"It" being your shell. Some do.

[slug → JoachimSchipper]

You are right, but who is the masochist that uses one that doesn't have that functionality ? ;)

[joeshaw → mst]

You might be able to provide it with the -o option:

ssh -o "KeepAlive no" example.com

[pafy → mst]

What about in your config file:

  Host *.whatever.com
  ServerAliveInterval 900
  Host *.whatsup.com
  ServerAliveInterval 60

[mst → pafy]

It's about where I am, not about where they are. slug's comment looks like a great idea though.

[est → mst]

> I do wish keepalive could be turned on/off more dynamically

PuTTY can do that. It's GUI though.

[njn → mst]

I'm curious why you would want multiple connections to the same host in the first place. Why not use a terminal multiplexer?

[lars512 → njn]

It removes the latency if you need to interact with the remote server, for example with remote repositories. I tried some experiments today with Bitbucket, and using connection multiplexing halved the time of most of my common mercurial operations (8s -> 4s).

[danohuiginn → njn]

it's convenient if you want to pipe the output of a command on a remote machine into another command on a local machine

ssh server remotecommand | localcommand

[danohuiginn → danohuiginn]

And some reasons why you might want to do that:

* set up a machine with all packages installed on some (debian/ubuntu) server: ssh server dpkg --get-selections| cut -f1 | xargs sudo apt-get install

* compare output of commands on two machines diff <(command) <(ssh server command)

* test/configure software on a local machine, plugging in its input from the roduction machine where it will be installed once ready

* avoid installing software on the server entirely; pull in the remote output and wrangle it locally (obv. not so good for high volumes)

* think a bug can be fixed by upgrading some software? try it on a test machine, pipe in the required input, and see