Live data from Hacker News

SSH Multiplexing & other OpenSSH Tricks

symkat.com

11–20 of 24 posts

Re: SSH Multiplexing & other OpenSSH Tricks

#11
post #3

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.

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

Re: SSH Multiplexing & other OpenSSH Tricks

#13
post #6
post #3

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.

What about in your config file: Host *.whatever.com ServerAliveInterval 900 Host *.whatsup.com ServerAliveInterval 60

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

Re: SSH Multiplexing & other OpenSSH Tricks

#14
For the proxy thing you may want to configure your applications to proxy DNS requests as well. Some do not do it by default and would leak the hostnames you're connecting to.

In firefox the about:config variable is "network.proxy.socks_remote_dns". Set it to true.

Re: SSH Multiplexing & other OpenSSH Tricks

#15
post #3

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.

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

Re: SSH Multiplexing & other OpenSSH Tricks

#16
post #11
post #3

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.

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

"It" being your shell. Some do.

Re: SSH Multiplexing & other OpenSSH Tricks

#17
post #10

just to be clear, multiplexing happens on the client side, right? What's the difference between multiplexing and ssh-proxy?

Multiplexing is multiplexing. That is, encoding multiple data streams across one channel. In our case, thats having a singular SSH connection from a to b, but having multiple streams of bidirectional data flowing across that singular connection. https://secure.wikimedia.org/wikipedia/en/wiki/Multiplexing So no, multiplexing is started on the client side, and then it happens on server side too. There has to be a multiplex ( many to 1 ) and demultiplex ( 1 to many ) in order for "multiplexing" to occur.

Re: SSH Multiplexing & other OpenSSH Tricks

#18
post #15
post #3

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.

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

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

Re: SSH Multiplexing & other OpenSSH Tricks

#19
post #15

Earlier quoted context omitted.

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

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

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 * 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

Re: SSH Multiplexing & other OpenSSH Tricks

#20
post #15
post #3

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.

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

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).
Post reply on HN