3 ms·
The ssh transaction/repl log thing is frightening to me. I get it, but when I've needed to get creds for a user to log into a service, one of my go-tos has been
by chaps 4y ago
The ssh transaction/repl log thing is frightening to me. I get it, but when I've needed to get creds for a user to log into a service, one of my go-tos has been to pull shell history on all the hosts they log into since they've almost definitely typed their password prematurely at some point. So, logging all that sounds like a really fun way of making a password store!
- tptacek 4y agoThe trick here is not having any passwords that anyone ever types.
- NovemberWhiskey 4y agoRight - for example: openssh supports GSSAPI, which you can make work (e.g.) with your Active Directory or other Kerberos implementation.
- SoftTalker 4y agoAlso set your shell config so they don't save history persistently. Anything that you use history for should be set as an alias or shell function or script.
- tptacek 4y agoThe concern being raised here is that transcript-level SSH audit logs are the equivalent of permanent shell histories for everyone, and they are. But if you're giving team members a reason to ever type a password into an SSH session, you're got a bigger gap to close. We already have to do secrets management at scale, because it's a feature we provide to our customers, and so we already have a process for loading secrets into environments for host work.
- anarazel 4y agoI'd be more worried (but not terrified) that the session transcripts can teach an attacker a fair bit about how systems work, should an attacker get access to those. Of course only a small subset of attackers is going to care...