Ability to record non-interactive sessions

[moisesmejia1200]

What would you like Teleport to do? Customer noticed "non-interactive" in one of their session recording. We have let them know this occurs when a user executes commands such astsh ssh root@moises echo hello world. However, admin would like to enable Teleport to record all session to ensure they are tracking all activity the engineers are executing.

What problem does this solve? Admin would like the ability to view ALL login session even if they are just executing tsh ssh commands.

If a workaround exists, please include it. At the moment I have told them they can view the commands by reviewing the audit logs and searching for Command Execution" in the Web UI

gz#5546

[zmb3]

@moisesmejia1200 just to clarify, the request here is to implement session recording for non-interactive sessions (so in this case the recording would contain hello world) - is that correct?

[moisesmejia1200]

@zmb3 Yes they would like to ensure they are able to track all activity users do even if its an non-interactive session such as tsh ssh commands . Customer wants to disable the ability for engineers to have non-interactive sessions. It has been requested that Teleport audit everything they did and saw and should be recorded.

[zmb3]

There's quite a few requests here and each comment seems to include more.

They want to record non-interactive sessions, be able to disable them, or both?

[moisesmejia1200]

Correct, the customer would like to prevent Teleport from creating non-interactive sessions. Non-interactive session does not create a recording, this prevents the customer from viewing the engineers activity.

[eriksw]

(Customer here.)

Being able to disable non-interactive ssh commands was a suggestion/ask made in the context of whether it's an option for an emergency mitigation. We would much rather the lack of input/output recording be addressed ASAP.

The only reason we are a Teleport customer is to have audit recording of everything done on our systems by engineers. The fact that Teleport does not capture inputs to and outputs from non-interactive commands is therefore, from our perspective, in the most serious category of faults.

If it's possible we could be given a version of teleport that blocks non-interactive commands even just a couple days before one that records the sessions, we would be very interested in such. This lack of recording is that serious an issue for us.

[jb-capgemini]

The only reason we are a Teleport customer is to have audit recording of everything done on our systems by engineers. The fact that Teleport does not capture inputs to and outputs from non-interactive commands is therefore, from our perspective, in the most serious category of faults.

Any update on this one? I have a client which has thousands of "non-interactive" sessions for a particular user, and it is hard to see if this is a teleport bug or a serious issue or not. And not being able to see what is happening in the session really ruins the whole point of teleport. There for we would like to know what can be done about:

1. disabling non-interactive sessions - is a solution in place for this now?
2. when will non-interactive sessions leave a recording as well (at least as can be enabled or not) - I see cases where you might not want the logs/recording, but in most cases you would demand it per default.

Looking forward to an update.

[galbeniluz]

Hi, is there any update on this? this is a major major flaw in teleport

[klizhentas]

Just to clarify for everyone. When non-interactive session is started, teleport tracks the exec command in the audit log, but does not show it in the "active sessions". Usually those sessions are launched automated, so showing them in the sessions list will pollute it to the point of being un-usable. However they are in the audit log.

In addition to that, if user launches tsh ssh root@host myscript.sh there is a need to see what actions have been executed by the script. To achieve that, customers can use BPF session recording that gives advanced insights on the syscall level:

https://goteleport.com/docs/server-access/guides/bpf-session-recording/#ssh-session-recording

Let me know if there is anything else missing.

[eriksw]

@klizhentas Does the bpf recording feature capture every byte sent from the client to the remote command, and every byte of output sent from the remote command to the caller? If not, that's irrelevant to this issue. (And even if it was, unless there's a control to make access conditional on bpf recording working, it still wouldn't be a workaround.)

[klizhentas]

Does the bpf recording feature capture every byte sent from the client to the remote command

BPF recording feature captures syscalls, and does not capture all the data sent over the wire. It is similar to how auditd works.

[eriksw]

BPF recording feature captures syscalls, and does not capture all the data sent over the wire. It is similar to how auditd works.

@klizhentas It is unfortunately irrelevant to this issue, then. Thank you for clarifying.

This issue is about having a complete record of the input to and output from all sessions.

The distinction between interactive and non-interactive sessions might mean something to the developers of Teleport as a technicality, but it absolutely does not matter in any way to our needs as customers who operate systems that hold sensitive information. We need the ability to have a complete record of everything that is seen and done on our sensitive systems.

We need to be able to answer with absolute certainty whether an engineer did or did not exfiltrate a given piece of data during their access to a sensitive system. We need to know exactly what code was input into an interpreter executed with flags to accept code via stdin. We need the ability to review exactly what the contents of the data sent to or received from a tar ... -f - command was. And so on...

From our perspective, the presence of a loophole to bypass session recording is something CVE-worthy. The fact that this issue has already languished for so long, without obvious work towards a solution, is rather disheartening.

At an absolute minimum, can we expect to see some kind of effective stop-gap mitigation soon, such as the ability to disable non-interactive sessions?