[walrus01]

> Teleport Proxy itself doesn't have access to much, so exposing it to the Internet is fine.

yeah this is a bad idea in general. If you have critical stuff you need to SSH into from the public internet, keep it all in private IP space and have an openvpn gateway (or IPSEC VPN) with a public interface, and a private interface facing inwards towards the hosts.

you should not even be able to route to the IP of the thing you want to SSH to unless you've authenticated to the VPN and your client device has been handed out an IP in your RFC1918 IP space.

a machine like an openvpn gateway can also serve the purpose of getting you access into an OOB network (example: a public facing IP on a 100Mbps DIA circuit you've bought from a totally diverse ISP in the same colo, with a static /30), which has access into internal IP space devices such as serial console servers and ssh bastion hosts.

authenticate the clients by a unique public/private key pair per client device. Easy to revoke a specific device's key from the server side if needed.

[alexk]

> yeah this is a bad idea in general. If you have critical stuff you need to SSH into from the public internet, keep it all in private IP space and have an openvpn gateway

This is not a bad idea in general. In fact, teleport proxy implements this exact model you have just described, where only proxy is available and acts as a jump host to the set of machines available only on the private net. The only difference is that instead of open VPN gateway it uses SSH jumphost model.

Teleport proxy uses OpenSSH cert auth, in addition to that teleport node also does cert auth.

Not everyone needs to always set up VPN, sometimes jumphosts + cert auth are perfectly fine.

[walrus01]

I encourage all of my competition to allow access to relay to critical internal things with only SSH based authentication on a bastion/proxy, and nothing else.

[anon263626]

Critical infrastructure demands solid, understandable security (ie defense-in-depend). Throwing around shiny, new, unprovens things to "give the emperor new clothes" increases risks for major security breaches.

Plus, this commercial thing doesn't do anything pam ldap and config mgmt can't do. Just reinventing the wheel yet again to charge people money for proprietary "solutions."

[alexk]

This is not how SSH jumphosts and Teleport Proxy work. With jumphost ssh client goes through the authentication and authorization twice:

* first when connecting to the jumphost public ip and requesting to execute a subsystem to allow proxying to some internal IP/host

Jumphost does not terminate the SSH and in fact it is MITM capabilities are very limited.

* Second time authentication and authorization happens when ssh client connects to the target SSH node.

This pattern is in fact quite modern and is being expanded in the beyond corp architecture.

https://research.google.com/pubs/pub43231.html

It deprecates perimeter security model that you mention via VPN gateways and replaces it with on-demand end to end access via controlling gateway.

[throw049483498]

Yeah but the security model it implements is vulnerable to any new remote code execution that pops up for OpenSSH.

With the VPN as your boundary, you can configure it so the VPN doesn't even respond to packets unless they are TLS authenticated. A huge security win, you're not exposed to random attempts to do remote code execution against your open sockets!

[russjones]

Hi walrus01,

If exposing Teleport (or OpenSSH or any piece of software to be honest) to the internet is a significant concern, the solution I recommend is to put it behind spiped. Spiped has a very small and well written code base and well suited for this problem.

Because Teleport is fully interoperable with OpenSSH you just follow the instructions in the README to get it working: https://www.tarsnap.com/spiped.html

[rsync]

"yeah this is a bad idea in general. If you have critical stuff you need to SSH into from the public internet, keep it all in private IP space and have an openvpn gateway (or IPSEC VPN) with a public interface, and a private interface facing inwards towards the hosts."

That's a ton of complexity when you could just run knockd on public facing sshds and make them disappear that way.

It's extremely tight, simple code - consisting of a single binary - and it never crashes or hangs.

No, I am not suggesting that you get rid of all of your keys and passwords and rely only on the knock for your security. (I have to write that because response-comment-numero-uno will strawman that to death). Keep your keys and passphrases in place and add the knock.

Port knocking is just the best thing.

[walrus01]

Port knocking, what is this, 2002? Security through obscurity is not any form of security at all. Properly implemented public / private key crypto is not rocket science anymore.

[rsync]

As predicted.

The idea is, in addition to the normal security measures you use with sshd you also hide the service with port knocking.

Nobody anywhere, at any time, has ever suggested using port knocking as the sole means of securing your sshd.

[anon263626]

Port knocking and some even obscurity are valid additional layers of defense-in-depth if combined fundamentals of A3E.

State actors can afford millions to spend on build/buying sploits for [insert technology]. For example, use different standard for OS at edges where possible to reduce attack surface. Preferably scrub network traffic at edges (not just web traffic) and really lock down traffic to remote access boxes.

[anon263626]

Yup. Open ports to the world is a terrible idea for anything real. This is why SSH jumpboxes (say a roundrobin pair of OpenBSD VMs with ssh rbash &| strongswan. Add secure portknocking to the pf firewall for bonus points.)

Plus, there's already plenty of ways to AAA OpenSSH using puppet/chef, PAM, RFC 4255, google authenticator (via pam plugin). It's really easy to set up if you've done it before.

[detaro]

Just to make sure I understand your reasoning right: VPN + SSH is better than just an SSH jump host because if someone finds a critical bug in OpenSSH, they still have to break the VPN, and vice-versa, someone breaking into your VPN still needs to also break SSH?

[walrus01]

That, and the usage of unique per device public/private X.509 PKI key pairs per client, for connection to the VPN. A typical person might have 3 sets of keys:

a) laptop

b) home office desktop

c) android or ios device (phone/tablet)

then, of course, once connected to the vpn, to authenticate to ssh the person will probably be using their per person ssh public/private key pair from their workstation.

So we have the ability to revoke an individual client device's vpn keys separately. In event of total compromise we can revoke both vpn keys for device(s) and the person's ssh key.

[detaro]

Don't people normally have per-device SSH keys as well? I basically never copy them between devices... But I guess that could be harder to manage if you have tons of devices you might SSH into, especially if they are not all centrally managed servers.