I am not sure to understand what this is this achieving compared to just assigning a ip + port per vm?

▲ CGamesPlay 4 days ago | parent | next [-]

Using nonstandard ports would break the `ssh foo.exe.dev` pattern.

This could also have been solved by requiring users to customize their SSH config (coder does this once per machine, and it applies to all workspaces), but I guess the exe.dev guys are going for a "zero-config, works anywhere" experience.

▲ hrmtst93837 4 days ago | parent | next [-]

Zero-config usually means the complexity got shoved somewhere less visible. An SSH config is fine for one box, but with a pile of ephemeral workspaces it turns into stale cruft fast and half the entries is for hosts you forgot existed.

The port issue is also boringly practical. A lot of corp envs treat 22 as blessed and anything else as a ticket, so baking the routing into the name is ugly but I can see why they picked it, even if the protocool should have had a target name from day one.

	▲	CGamesPlay 4 days ago \| parent [-]
		SSH configs support wildcards, so if you couple it with a ProxyCommand you can an arbitrary level of dynamism for a host pattern (like *.exe.dev). But yeah, everything is a trade-off.

▲ KomoD 4 days ago | parent | prev | next [-]

Too bad most SSH clients don't seem to support SRV records, they would've been perfect for this:

  ;; Domain:     mydomain.com.
  ;; SSH running on port 2999 at host 1.2.3.4

  ;; A Record
  vm1928.mydomain.com. 1 IN A 1.2.3.4

  ;; SRV Record
  _ssh._tcp.vm1928.mydomain.com. 1 IN SRV 0 0 2999 vm1928.mydomain.com.

If supported it would result in just being able to do "ssh vm1928.mydomain.com" without having to add "-p 1928"

▲ 4 days ago | parent | prev | next [-]

[deleted]

▲ w-ll 4 days ago | parent | prev [-]

-p ?

▲ otterley 4 days ago | parent | prev [-]

Not needing a different port. Middleboxes sometimes block ssh on nonstandard ports. Also, to preserve the alignment between the SSH hostname and the web service hostname, as though the user was accessing a single host at a single public address. Usability is key for them.

▲

Dylan16807 4 days ago | parent | next [-]

Why would anyone configure it to do that?

Like, I understand the really restrictive ones that only allow web browsing. But why allow outgoing ssh to port 22 but not other ports? Especially when port 22 is arguably the least secure option. At that point let people connect to any port except for a small blacklist.

▲

josephcsible 4 days ago | parent | next [-]

Middlebox operators aren't known for making reasonable or logical decisions.

▲

9dev 4 days ago | parent | prev | next [-]

Asking back, when I limit the outgoing connections from a network, why would I account for any nonstandard port and make the ruleset unwieldy, just in case someone wanted to do something clever?

▲

Dylan16807 4 days ago | parent [-]

A simple ruleset would only block a couple dangerous ports and leave everything else connectable. Whitelisting outgoing destination ports is more complicated and more annoying to deal with for no benefit. The only place you should be whitelisting destination ports is when you're looking at incoming connections.

▲

9dev 4 days ago | parent [-]

I definitely block outgoing ports on all our servers by default; Established connections, HTTP(S), DNS, NTP, plus infra-specific rules. There is really no legitimate reason to connect to anything else. The benefit is defence against exfiltration.

▲

Dylan16807 3 days ago | parent [-]

If you're allowing direct https out, how are you stopping exfiltration?

Maybe https is routed through a monitoring proxy, but in the situation of allowing ssh the ssh wouldn't be going though one. So I still don't see the point of restricting outgoing ports on a machine that's allowed to ssh out.

▲

9dev 3 days ago | parent [-]

You can't, reasonably. It's just a heuristic against many exploits using non-standard ports to avoid detection by proxies or traffic inspection utilities.

	▲	otterley 2 days ago \| parent [-]
		You can, but you need additional components to do it, like an SSH session broker (i.e. a gateway or proxy). Some of these, like SSH Communications' PrivX suite, can record all traffic running through the proxy. It's not all that different from HTTPS security and auditing proxies.

▲

otterley 4 days ago | parent | prev [-]

I’m not a network security expert, so I don’t know the threat model. I just know that this is a thing companies do sometimes.

▲

Charon77 4 days ago | parent | prev | next [-]

They don't want each vm to have different public IP

	▲	4 days ago \| parent [-]
		[deleted]

▲

gsich 4 days ago | parent | prev [-]

Middleboxes are not relevant in this scenario.

▲

otterley 4 days ago | parent [-]

Uh, why not? Unless your SSH client is on the same network as theirs, there are going to be middleboxes somewhere in the path.

▲

gsich 3 days ago | parent [-]

Because your ISP should (and most do not) alter traffic.

▲

otterley 3 days ago | parent [-]

But you’re not considering the many business environments that do.

▲

gsich 3 days ago | parent [-]

I don't because that would be impossible. Every business has different rules. But if you (as a business) want to to use this, you will find a way to make the changes to those "middleboxes". It's not your network, it's your business's network.

▲

otterley 3 days ago | parent [-]

Large multi-national corporations, by way of their sheer size, tend to force their vendors to bend towards their needs, not to adapt to meet their vendors' unusual networking requirements.

▲

gsich 2 days ago | parent [-]

Thankfully SSH on non-22 is not unusual.

▲

otterley 2 days ago | parent [-]

Of all the SSH servers in the world, what percentage are listening on a port other than 22? To answer this question, you can visit https://data-status.shodan.io/ports.html and see for yourself.

By "unusual," I literally mean "not usual/not typical." Not "never happens."

▲

gsich 2 days ago | parent [-]

I fail to see how this is relevant.

▲

otterley 2 days ago | parent [-]

I'll explain it once again, then leave this thread:

Companies frequently put egress network policies in place that confine certain protocols like SSH and HTTP to certain ports. They do this in order to achieve compliance with regulations, to achieve security or operational certifications, or simply because they're paranoid. It's not necessarily the least restrictive means of accomplishing their goals, but that's what they do. And if they're big enough, they're going to use the size of the deal and their brand equity to persuade their vendors, who might ordinarily prefer to offer a service on a nonstandard port, to provide it on the customer's preferred port instead.

If you still don't understand, I'm sorry, but I cannot assist further.

	▲	gsich a day ago \| parent [-]
		Companies might do that. They have the right to do so. If they still want to use that service, they will find a way to use it. Be it by vendor-coercing or simpler methods. Just because those companies exist, does not mean that their shitty practices have any imapct on real internet connections. If you as a paying ISP customer want to use a custom port or whatever, it is going to work. So you as a developer don't have any restriction (which you don't know anyway beforehand) if you are developing a solution for a problem. "Middleboxes" is a hackernews meme that is thrown around because people here work at places who restrict stuff and they can't bother to change that situation but instead complain about it. The fact that games exist and they use all kind of ports is proof that this is not a problem for normal networks.