Added ssh_gateway_port option

[rheostat]

This pull request enables a configurable gateway port, separate from the test server ssh port. The gateway port defaults to port 22. Also, removed is the :keys_only restriction when an :ssh_key is provided so that the local ssh agent can provide the key for the gateway host.

[rheostat]

The failing tests are related to the removal the :keys_only restriction. My use case is kitchen-docker where the docker host is remote and I'd prefer not to leave a bunch of ports open to allow the SSH connection to the docker container. I think it makes sense to check with the SSH agent when using a gateway as there is no guarantee that both hosts will allow the same key and currently it's not possible to specify multiple keys. In my case, docker-machine generated the gateway key and kitchen-docker generated the test container key.

[coderanger]

👎 The plan on the kitchen-docker side is to remove the usage of SSH entirely. I think this is probably too specific to the weird needs of kitchen-docker's remote mode to justify core inclusion. Even if we did want to keep SSH for docker, this could go in a transport plugin in kitchen-docker itself.

[rheostat]

It seems like the original author of SSH gateway support thought it would be useful: https://github.com/test-kitchen/test-kitchen/blob/master/lib/kitchen/transport/ssh.rb#L151

The current SSH gateway support is pretty limited in its current state.

What's the plan if SSH is going away?

[rheostat]

I looked into implementing a custom ssh_gateway transport by subclassing the core ssh transport. Unfortunately this would involve duplicating much of the code and functionality of the existing ssh transport. This was the best alternative I could come up with that wouldn't leak the transport details into driver configurations.

[rheostat]

A note on the ssh transport implementation:

I think you would need to be able to hook session creation in order to effectively subclass it and do anything interesting in the way of tunnelling. However, session creation is handled in a private method which would not be advisable to override.

[ytsarev]

That would be useful for my use case too. The test suite should be fixed and extended before the merge though.