6 ms·

> Side question: does anyone know of a SSH "loadbalancer", working like HTTPS SNI so that multiple domains can have ssh on the same IP and port? I think the te

> Side question: does anyone know of a SSH "loadbalancer", working like HTTPS SNI so that multiple domains can have ssh on the same IP and port? I think the term you're looking for is "bastion host" or "jump host". Basically you SSH into the bastion server and then run another SSH command to get to the destination server; newer versions of the SSH client apparently support a -J option to do this automatically.

beagle3 9y ago
But that's not loadbalancing - you still have to trust any host you get to through the jump host; with a new enough ssh and sshd, you can use a CA to sign host or client keys, and get an experience similar to https. (There is even a DNS record for that, iirc) Any TCP loadbalancer will do as long as all the hosts share the host key, which is considered bad practice but isn't worse than e.g. Sharing a TLS certificate, which is not considered a horrible practice.
- wolfgang42 9y ago
  They weren't looking for load balancing in the "keep it even between identical hosts" sense, but rather in the manner that you might use a "load balancer" appliance to look at the SNI and direct the request to the correct machine for the given hostname. (See our conversation elsewhere on the thread for why they wanted to do this.)
  - beagle3 9y ago
    The SNI thing breaks down, because an SNI redirector (which is what GGP is after - not load balancer) strips the SSL and continues in plain http beyond; I think you have to specially compile sshd these days if you want it to accept plaintext connections, and it is highly discouraged (for very good reasons).
j605 9y ago
I was not aware of -J, thanks for the comment :)
mschuster91 9y ago
Thanks for -J, that helps a bit but is not what I want to avoid :( More context: the server in question is running gitlab in a docker container, and users should also be able to SSH into the server. Now I have to run either gitlab or the host sshd on a different port, which confuses users and often enough leads to problems with git clone (the syntax is [git@git.my.tld:22222]:path/torepo.git, which is accepted by bash but people insist on zsh and other shells which break on the brackets)...
- wolfgang42 9y ago
  Why not use the URL syntax? Then you can do git clone ssh://git@gitlab.example.com:2222/path/torepo.git which shouldn't be mangled by the shell. (In fact, this is the syntax that GitLab gives you by default.) Alternatively, each user could put into their ~/.ssh/config: Host gitlab Hostname gitlab.example.com Port 2222 User git and then use "gitlab:path/torepo.git" instead. (In this particular scenario a bastion host probably isn't useful, since you'd have to copy the SSH keys out of gitlab into the bastion and make sure you get the management/security right. A web search for "ssh forward git user" turns up a number of people struggling with your problem; none of them seem to have entirely satisfactory answers.)
  - mschuster91 9y ago
    Because gitlab does not provide this syntax (if you do know how to get it that way, please tell me!), and people like to copy-paste... and getting people to set up their .ssh/config, tried that and failed, I would not ask if that were an option :(
    - wolfgang42 9y ago
      My GitLab CE instance (also docker) provides the URL syntax, so I did some spelunking through GitLab's source to figure out what might be different with your instance and found build_gitlab_shell_ssh_path_prefix: https://gitlab.com/gitlab-org/gitlab-ce/blob/c946ee1282655d332da4ba99c448d6f68cf87cee/config/initializers/1_settings.rb#L37 https://gitlab.com/gitlab-org/gitlab-ce/blob/c946ee1282655d3... The gist of it is that it looks like you probably have "git.my.tld:22222" set somewhere in your config file, which should be removed and replaced with: gitlab_rails['gitlab_shell_ssh_port'] = 22222 Alternatively, you may have gitlab_shell['ssh_path_prefix'] set which would cause the same symptoms.

beagle3 9y ago

But that's not loadbalancing - you still have to trust any host you get to through the jump host; with a new enough ssh and sshd, you can use a CA to sign host or client keys, and get an experience similar to https. (There is even a DNS record for that, iirc) Any TCP loadbalancer will do as long as all the hosts share the host key, which is considered bad practice but isn't worse than e.g. Sharing a TLS certificate, which is not considered a horrible practice.

wolfgang42 9y ago
They weren't looking for load balancing in the "keep it even between identical hosts" sense, but rather in the manner that you might use a "load balancer" appliance to look at the SNI and direct the request to the correct machine for the given hostname. (See our conversation elsewhere on the thread for why they wanted to do this.)
- beagle3 9y ago
  The SNI thing breaks down, because an SNI redirector (which is what GGP is after - not load balancer) strips the SSL and continues in plain http beyond; I think you have to specially compile sshd these days if you want it to accept plaintext connections, and it is highly discouraged (for very good reasons).

j605 9y ago

I was not aware of -J, thanks for the comment :)

mschuster91 9y ago

Thanks for -J, that helps a bit but is not what I want to avoid :( More context: the server in question is running gitlab in a docker container, and users should also be able to SSH into the server. Now I have to run either gitlab or the host sshd on a different port, which confuses users and often enough leads to problems with git clone (the syntax is [git@git.my.tld:22222]:path/torepo.git, which is accepted by bash but people insist on zsh and other shells which break on the brackets)...

wolfgang42 9y ago
Why not use the URL syntax? Then you can do git clone ssh://git@gitlab.example.com:2222/path/torepo.git which shouldn't be mangled by the shell. (In fact, this is the syntax that GitLab gives you by default.) Alternatively, each user could put into their ~/.ssh/config: Host gitlab Hostname gitlab.example.com Port 2222 User git and then use "gitlab:path/torepo.git" instead. (In this particular scenario a bastion host probably isn't useful, since you'd have to copy the SSH keys out of gitlab into the bastion and make sure you get the management/security right. A web search for "ssh forward git user" turns up a number of people struggling with your problem; none of them seem to have entirely satisfactory answers.)
- mschuster91 9y ago
  Because gitlab does not provide this syntax (if you do know how to get it that way, please tell me!), and people like to copy-paste... and getting people to set up their .ssh/config, tried that and failed, I would not ask if that were an option :(
  - wolfgang42 9y ago
    My GitLab CE instance (also docker) provides the URL syntax, so I did some spelunking through GitLab's source to figure out what might be different with your instance and found build_gitlab_shell_ssh_path_prefix: https://gitlab.com/gitlab-org/gitlab-ce/blob/c946ee1282655d332da4ba99c448d6f68cf87cee/config/initializers/1_settings.rb#L37 https://gitlab.com/gitlab-org/gitlab-ce/blob/c946ee1282655d3... The gist of it is that it looks like you probably have "git.my.tld:22222" set somewhere in your config file, which should be removed and replaced with: gitlab_rails['gitlab_shell_ssh_port'] = 22222 Alternatively, you may have gitlab_shell['ssh_path_prefix'] set which would cause the same symptoms.