Session recording for Tailscale SSH in beta | Hacker News Reader

Session recording for Tailscale SSH in beta

tailscale.com

157 pointsgeoffeg32 comments

Many folks don’t realize it, but sudo offers a sudoreplay[0] to do something similar. Obviously this won’t cover things they do outside of a sudo session, but you could construct permissions on the machine such that you would require them to use it for things you care about.

This isn’t to trivialize the work of Tailscale (like the famous Dropbox comment). I just wanted to point out a cool thing that sudo does that most people don’t know about.

[0] https://www.sudo.ws/docs/man/1.8.13/sudoreplay.man/

This is a deceptively valuable feature for regulated/compliance-trained companies, because a lot of things you want a detailed audit trail for are accessed via shells (most notably: the consoles for app frameworks).

Here at LargeTelco with a legally privileged and regulated safety-critical utility status, absolutely every administrative interaction with a production host goes through a bastion that, on top of enforcing access privileges, also records _everything_. Also, LargeTelco is a complex hell of subnetting. I can very well see the enterprisey attraction of having not just Tailscale's low cost and extraordinary ease, but also session records like it is just a cherry on top !

What do you use to log sessions?

I use script(1) daily for creating papertrails:

  script -ec "command args" ~/$(date +%Y-%m-%d-%H%M%S_$$_script.txt)

Works out of the box on almost every *nix system.

The recordings end up as textfiles with the control sequences in, you can use commands like cat -v, grep or less -R on them. If you also record a timing file, you can replay it 1:1 on you terminal.

A very valid use-case not mentioned in the article is to save all your personal terminal interactions to a database so you can search it in the future. Your terminal's input (and output) value per byte is enormous so really everyone should be saving it all.

I'll be horsing around with this tonight -- I hope ts sshing to my local computer will just work so I can get local recording as well without a separate mechanism.

I've thought about this too - if you use tmux, you can use `tmux capture-pane` to grab all the output and scrollback in the current window.

The value is enormous but the security sensitivity is too, so it's important to only store it in secure places.

And on a company laptop with automagic backups to the cloud of your home directory, what's secure? At a previous company I disabled persistent shell history, and lost count of the number of times this prevented a sensitive password or key from being added to the treasure trove of secrets that are backup archives. (The backup app nominally supported exclusions, but 1) I don't trust the correctness of corporate bloatware, and more importantly 2) I don't trust that IT or an update wouldn't reset those exclusions.)

Now, shell sessions from a bastion host scream (hopefully!) security sensitive to IT. Moreover, at that point you shouldn't be entering any passwords or keys; one should trust least the integrity of application servers and similar end nodes. But dumps from company laptop home directories where 99% is crap from sales and management... no way that is going to be treated with proper care, no matter how much customer PII it might contain.

In this day an age, are workstation backups really necessary? I can't think of anything important I do on my work machine that would need it. Maybe a days worth of code edits that haven't been pushed to GitHub.

If its windows and you use weird certs for external interaction like most power pools do, its pretty important, especially thw solutions that spin up a vm in the cloud foe you quickly.

For me personally yes absolutely.

But I'm not much into the whole cloud movement for privacy reasons.

On a company laptop this all sounds like the company's problem, not mine.

The real problem here is you are typing those "sensitive password or key" into termianl. Instead of type it directly, Use `read password` and `mysql -p$password` is the right way. Additionally, most programs can use environment variables directly, so you can even avoid showing them in the command line arguments.

If you entered something in terminal directly, I won't call it sensitive.

This project was mentioned recently here - it does this locally, saving to sqlite.

https://news.ycombinator.com/item?id=35839470

https://github.com/ellie/atuin

And it looked amazing, until another user pointed out that if you install it, whitespace-prefixed commands will start being saved in your bash history, and they refuse to document this behaviour

Ooh, didn't see that.

Does mcfly also have this behavior? https://github.com/cantino/mcfly

Answering my own question, McFly does not have record whitespace prefixed commands.

Maybe slightly off-topic, but does anybody here know how to record an(or any) SSH session(s)? On a debian server, for example?

I remember seeing someone do a demo on this but the result, after only 2 minutes where insane. There was so much data to go through that you might aswell just give up on trying to get anything useful.

In the old days I played with something like this: https://github.com/desaster/kippo

But a more modern alternative seems to be the container based approach outlined here. https://lwn.net/Articles/848291/

PuTTY has very expensive logging options ranging from visible output only to full control codes and even packets.

I always assumed OpenSSH offers this too but I've never had a need to actually check. I guess you can just 'tee' it anyway.

I wrote an eBPF application that is launched and killed by a PAM session script. It uses the PPID to only record commands and arguments associated with that session. My application was heavily influenced by execsnoop:

https://github.com/iovisor/bcc/blob/master/tools/execsnoop.p...

The `script` command is available and pre installed on most Linux distros.

Looks nice.

However if I scp a script to an audited server, then execute it, would I be able to retrieve the content of the script to have a proper audit trail ?

In other words is the file transfer protocol audited ?

Semi related, does anyone else feel that the higher tier of tailscale is priced crazy high? I was investigating tailscale for a company and was really sold until I realized we needed SSH logins and that'd cost $18/user. That seems crazy expensive to me. I'd really expected it to be closer to $10/user. Am I crazy? Is this the cost of VPN + basic access control these days?

> until I realized we needed SSH logins and that'd cost $18/user

What do you mean? You can use Tailscale SSH in the free plan.

Like I said, this is for a company implementation, we'd need more than three users

So $6/user then?

Look at their pricing page, it says $18/user/month if you want SSH. The $6/user/month plan doesn't include it. They don't include Funnel in their basic plan either.

This seems pretty nice, but having too many logs is yet another attack surface.

Also reviewing these logs is a pain as soon as you get non-shell things running (i.e. someone spawns a vim session).

Reply on news.ycombinator.com