Hacker News Reader

Comment by mschuster91 | Hacker News Reader

> A self-signed cert could be supported and effectively trust on first use like SSH and have the same trust model as a DV cert.

No, it can not. Self-signed certs, if not verified prior to first visit to a site or being trusted in case of company intranet sites, are vulnerable to a MITM attack - which is why browsers are warning if they can't detect a valid trust path.

Also, SSH is only secure on first use if you verify the fingerprints (and that is why ssh will ask you if you know/trust the hash on first connect).

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?

View on HN

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

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.

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.)

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).

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)...

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.)

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 :(

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/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.

I have never had to use the brakets like that when referring to a remote path in shell (bash or zsh). Is it because of the port number? Perhaps I never used a port number in the string, but im pretty sure I've needed it at some point (jenkins ran on :8080).

> Is it because of the port number?

yep, exactly. ssh normally does not need a portnumber if you are running gitlab-ssh on standard tcp/22.

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

Reply on news.ycombinator.com