3 ms·
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/s
by candiddevmike 2y ago
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/ 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.
- g-b-r 2y ago“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?
- candiddevmike 2y agoSure, but this is all happening over HTTPS (Etcha only listens on HTTPS), it's just an added form of protection/expiration.
- artificialLimbs 2y agoI don’t understand why this is more secure than limiting SSH to local network only and doing ‘normal’ ssh hardening.
- candiddevmike 2y agoNone 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.