Access for Infrastructure: SSH

Re:Access for Infrastructure: SSH by candiddevmike on Wednesday October 23, 2024 @08:09PM (#41930545)

I built a config management tool, Etcha, that uses short lived JWTs. I extended it to offer a full shell over HTTP using JWTs:

https://etcha.dev/docs/guides/shell-access/

It works well and I can "expose" servers using reverse proxies since the entire shell session is over HTTP using SSE.

[ Parent | on HN ]

Re:Access for Infrastructure: SSH by g-b-r on Wednesday October 23, 2024 @09:01PM (#41930862)

“All JWTs are sent with low expirations (5 seconds) to limit replability”

Do you know how many times a few packets can be replayed in 5 seconds?

[ Parent | on HN ]

Re:Access for Infrastructure: SSH by candiddevmike on Wednesday October 23, 2024 @09:43PM (#41931098)

Sure, but this is all happening over HTTPS (Etcha only listens on HTTPS), it's just an added form of protection/expiration.

[ Parent | on HN ]

Re:Access for Infrastructure: SSH by artificialLimbs on Wednesday October 23, 2024 @11:03PM (#41931515)

I don’t understand why this is more secure than limiting SSH to local network only and doing ‘normal’ ssh hardening.

[ Parent | on HN ]

Re:Access for Infrastructure: SSH by candiddevmike on Thursday October 24, 2024 @07:36AM (#41934522)

None of that is required here? Etcha can be exposed on the Internet with a smaller risk profile than SSH:

- Sane, secure defaults

- HTTP-based--no fingerprinting, requires the correct path (which can be another secret), plays nicely with reverse proxies and forwarders (no need for jump boxes)

- Rate limited by default

- Only works with PKI auth

- Clients verify/validate HTTPS certificates, no need for SSHFP records.

[ Parent | on HN ]