1

I have a Linux server with a single, static IPv4 address and several DNS entries pointing to the IP. The server hosts several Docker container, and listens on port 22 for incoming SSH connections.

There are three different use cases, where SSH connections to the server are made:

  • access to git repositories (git.myserver.tld, username is always git, access is realized by using different keys)
  • access to files using sftp (data.myserver.tld, username is always data, access is realized by using different keys)
  • direct access to the server (myserver.tld, username corresponds to local unix user)

The first two servers (git and data) are each running inside a Docker container. My question is: Is it somehow possible to redirect incoming SSH connections to the SSH servers of the Docker containers, if Git or Data is required, or handle it directly if not? Could this be realized by looking at the username (redirect if it is git or data, handle it otherwise) or the hostname (is there some equivalent to SNI for TLS)?

Using another port than 22 is not an option, as the access should be allowed from environments, where only a few ports are allowed for outgoing connections.

The user management is handled by the appropriate Docker container services; there is no static list of SSH keys used to connect, but no connection ever uses password authentication.

The server runs Debian Linux with OpenSSH.

[Edit]

I do not think that this is a duplicate, because my questions was not only about the possibility to define hostname-based virtual SSH servers. I also asked if it is possible to differ on a per-user basis, which is not handled by the linked question. The username is transmitted during the SSH session, so there might be a possibility..

muffel
  • 302
  • 7
  • 20
  • Related: [Is there a name based virtual host SSH reverse proxy?](http://serverfault.com/q/34552/4276) and [“Virtual hosts” for SSH](http://serverfault.com/q/329529/4276) – Cristian Ciupitu May 24 '15 at 12:18
  • It is impossible to do with current SSH client implementations. But with a minor protocol extension on the client side, it would become possible. Yesterday I send a path implementing this to the OpenSSH mailing list. My previous answer has more details: http://serverfault.com/a/610971/214507 – kasperd May 24 '15 at 12:55
  • 1
    Start using IPv6 so you don't have to worry about things like this. – Michael Hampton May 24 '15 at 15:00
  • @MichaelHampton I am using IPv6 everywhere I can. The reason I am concerned with this is that 95% of the people who need IPv6 cannot get it because of insufficient competition among the ISPs. And I am interested in this particular feature being added to the SSH protocol because it is preventing me from adding SSH support to one of the services I have deployed in order to smooth the transition to IPv6: http://v4-frontend.netiter.com/ – kasperd May 24 '15 at 16:18
  • @MichaelHampton I'd love to, but the largest German ISPs don't provide IPv6, and neither do our cell phone providers :( – muffel May 24 '15 at 17:01
  • @muffel Germany is way ahead of most countries. According to the stats from Google, there are only two countries in the world with higher percentage of IPv6 users than Germany. So on the client side you have better odds than most people. On the server side there is little excuse for not running IPv6. There is plenty of competition in the hosting market, you will still have a lot of vendors to chose from you ignore all of those with no IPv6 support. I have personally moved services to be hosted in Germany in order to get IPv6 support. – kasperd May 24 '15 at 21:43
  • 1
    @muffel I am curious whether the latest edit of [my answer](http://serverfault.com/a/610971/214507) is useful in your scenario. If you need some help for testing it out, we can do it in chat. – kasperd May 26 '15 at 19:54
  • @kasperd it's interesting, and I'll play around with it for sure, but it requires client-side modifications, which is unfortunately unfavorably for my scenario. – muffel May 28 '15 at 09:27
  • @muffel An unmodified client will send the exact same sequence of bytes to the proxy regardless of which hostname was used. That makes it impossible for the proxy to choose a server based on hostname. So something has to be changed on the client side. Depending on what other constraints you have, the changes on the client side could be either a change of the SSH client or the use of an external ProxyCommand like supported by OpenSSH. – kasperd May 28 '15 at 09:55
  • Username is sent but it is encrypted. This means the proxy wouldn't be able to see it. Moreover it is only sent after key exchange, but the proxy need to pick a server before performing the key exchange. You could work around this by having the proxy perform a full MITM on the SSH connection. That would mean users would see the host key of the proxy rather than the server behind it. You could update the known_hosts file on each client to contain the public key of the proxy, but you'd be reducing security by no longer having end-to-end security between client and server. – kasperd May 28 '15 at 10:06
  • Even if you decided that the reduced security due to clients allowing the proxy to MITM the traffic was acceptable, that doesn't end the problems. Once the proxy perform such a MITM, client and server will no longer have the same session identifier. This breaks public key authentication. So you'd also have to revert back to a less secure authentication method such as a password. Forcing users to send their password in clear through a connection known to be subject to MITM doesn't sound like a good plan. – kasperd May 28 '15 at 10:09
  • @kasperd I would not agree that this results in less security, if proxy and target server are within the same system / network. Many infrastructure do for example communicate using unencrypted HTTP internally, and have a single web server that acts as HTTPS endpoint, removes the encryption and forwards the plain HTTP to the target application server. I thought of such a solution. I do know that the username is encrypted, and having a full key exchange done seems good to me. My idea was to somehow forward the connection to the target server, and reinitiate the authorization / key exchange – muffel May 29 '15 at 08:27
  • @muffel In many situations the most secure authentication you could use would be public key. Such a MITM would break public key authentication. It might be possible to let the proxy hold a secret key and add the corresponding public key to every authorized_keys file on the backends. But that would make the proxy a much more valuable target to an attacker than it would otherwise have been. – kasperd May 29 '15 at 08:40

0 Answers0