Warpgate: Smart SSH bastion that works with any SSH client | Hacker News Reader

Warpgate: Smart SSH bastion that works with any SSH client

github.com

120 pointstodsacerdoti22 comments

At a previous role I made something similar [0] in Golang, but used SSH certificates to manage authentication. This had the added benefit of logging the user connection information in each server’s auth.log based on the generated private key and signed (but short lived) certificate used for auth in the session. At one point I had changes that would sign certificates from Vault [1] directly.

I had it so that a user needed to login to the service with their GSuite account every 24H, and each login required 2fa as well. SSH sessions were recorded in asciicast format (which seems to be used here as well) and there was an audit log to track connections. They could be joined in real time and disconnected from a simple admin interface. The ACL system was a pretty basic method of using regex for defining auth rules.

Worked pretty well and helped with compliance audits we were completing at the time. I think the benefits here of being in Rust is definitely performance and memory safety. Granted, The Go implementation was pretty fast and safe as well. Go made it pretty easy to implement due to the SSH implementation in the standard library.

[0] https://github.com/notion/bastion

[1] https://www.vaultproject.io/docs/secrets/ssh/signed-ssh-cert...

hmmm... it might be written in Rust, but I'd still rather use an instance of good-old OpenSSH as a suitably configured bastion host.

OpenSSH has been battle-tested to death and comes from a good stable (OpenBSD, LibreSSL).

I'm very weary indeed of re-implementations of SSH servers.

Personally, I’m weary of software written in languages without memory safety that are more likely to have long living exploits only known to certain government authorities.

Just because the OP didn't use unsafe {} anywhere in their code doesn't mean it's not used in any dependencies. Just glancing at some of the deps I can already see there is a lot of unsafe usage deep down that are "wrapped" in safe interfaces. Rust is not some kind of silver bullet for safety. It just makes it more explicit.

Also, I'm less concerned about the memory safety than the _complete reimplementation of SSH_ from scratch. So give me OpenSSH any day for things that are actually important.

Id trust old software written in a memory unsafe language that has a sterling track record over new software written in a safer language that has not much of a track record at all.

The Rust authors condemned the world to play their stupid game of semantics when they created the `unsafe` keyword.

The feature turns off extra compile time checks. That’s it. It doesn’t mean the program is correct.

This program still allows potentially damaging things like `rm -rf /`. So, it’s not data safe. It’s unknown whether it’s secure safe either, since it’s not been audited and it’s still “alpha”.

Please educate yourself.

https://www.openbsd.org/security.html

https://www.openssh.com/history.html

I think this is fulfilling a slightly different niche - further down in the README it talks specifically about opening a separate connection to the host and recording the session for audit purposes.

Which offers a little more than a simple SSH bastion would, unless there are features like this in OpenSSH I'm not aware of.

> I'm very weary indeed of re-implementations of SSH servers.

The security properties of this are a little scary, too: the recommended configuration here has all hosts trusting the bastion, which kind of undoes the point. Pwn the bastion host, and pwn everything.

It's trickier, but a decent ssh jumphost requires the user to authenticate to the bastion and the host behind.

> OpenSSH has been battle-tested to death

So have wet paper bags ;]

Very reminiscent of the Teleport access proxy which started out as a SSH proxy but now also supports a bunch of other protocols: https://github.com/gravitational/teleport

Unfortunately Teleport locks SSO behind an “enterprise contact us” price.

To be clear: I don’t like contact us pricing.

But SSO support does feel like an enterprise feature that people typically pay for.

I can’t think of any other feature gate that would work as well for software such as this. Though it typically is the largest hinderance to SSO adoption.

I think security and therefore SSO should not be an optional feature. See https://sso.tax/

Obviously big companies will pay for SSO because they must have SSO. At my scale I skip products that are overpricing SSO or I put them behind a oauth2-proxy when I can.

From the roadmap, it looks like they are reimplementing the same/similar feature set.

> You'll need nightly Rust (will be installed automatically), NodeJS and Yarn

Is Rust unable to provide a suitable back end - the need for node seems offputting

That's just for building the frontend: https://github.com/warp-tech/warpgate/tree/main/warpgate-adm...

Not used or needed at runtime

Nice to see this! There are surprisingly few solutions that support SSH session recording.

There are at the session level, yeah. We use sudosh and a restricted shell on our jump boxes.

https://linux.die.net/man/1/sudosh

This doesn't record port-forwarded traffic tho, and warpgate does

I believe this is Privileged Access Management (PAM) product.

Yes it is. This overlaps with functionality of CyberArk PWA PAM

Reply on news.ycombinator.com