[GH-ISSUE #156] Sync ttyrec files #36

Closed
opened 2026-05-07 00:17:55 +02:00 by BreizhHardware · 2 comments

Originally created by @jonathanmarsaud on GitHub (Mar 8, 2021).
Original GitHub issue: https://github.com/ovh/the-bastion/issues/156

Hi,

It seems that ttyrec files stored in /home/<user>/ttyrec/* are not synced between slaves and master. So in a HA setup, when a user reach a slave, his session is only recorded locally on the slave, and not available on every machines of the cluster.

Is this intended? What is the workflow to see all recorded sessions of a user?

Thanks,

Originally created by @jonathanmarsaud on GitHub (Mar 8, 2021). Original GitHub issue: https://github.com/ovh/the-bastion/issues/156 Hi, It seems that `ttyrec` files stored in `/home/<user>/ttyrec/*` are not synced between slaves and master. So in a HA setup, when a user reach a slave, his session is only recorded locally on the slave, and not available on every machines of the cluster. Is this intended? What is the workflow to see all recorded sessions of a user? Thanks,
BreizhHardware 2026-05-07 00:17:55 +02:00
  • closed this issue
  • added the
    question
    label
Author
Owner

@speed47 commented on GitHub (Mar 16, 2021):

Hello,

You're right, ttyrec files are not synchronized. In our setups, we have between 2 and 8 machines in each bastion cluster, and some of these clusters receive millions of connections per day, so synchronizing all the ttyrec files between all the instances would produce a big overhead and would not be very efficient.

Our workflow is the following:

  • A session is recorded on a bastion instance, it's stored locally as a ttyrec file, as you have seen.
  • After a few days/weeks (configurable, depends on each cluster), the old ttyrec files are compressed and encrypted (to .gpg files), and moved locally to another folder. At that point, the ttyrec file can no longer be accessed by the user with the selfPlaySession command. It can still be decrypted/viewed by somebody with local access to the bastion (and access to the gpg key and password, of course). At the same time, those files are also pushed to a remote escrow filer. This is now possible because the files are encrypted, so there is no security/confidentiality concern getting those out of the bastion.
  • After a few more days/weeks, the local copiess of these compressed-encrypted ttyrec files, that have already been pushed to the escrow filer, are deleted, to ensure we always have room for the fresh ttyrecs that are continually produced.

So, the workflow to check all the ttyrec of an user, for example, is either to have a look at the escrow filer, where we have everything, or, if the time window is recent, check on the bastions directly. We know where to look because every command or access is logged to syslog, and this is pushed to a centralized location, so we can make queries to know exactly what ttyrec files have been produced, and where those are stored.

The script we use to compress/encrypt/rotate/push/delete ttyrec files is bin/cron/osh-encrypt-rsync.pl, with its corresponding configuration found at /etc/bastion/osh-encrypt-rsync.conf.

<!-- gh-comment-id:800383960 --> @speed47 commented on GitHub (Mar 16, 2021): Hello, You're right, ttyrec files are not synchronized. In our setups, we have between 2 and 8 machines in each bastion cluster, and some of these clusters receive millions of connections per day, so synchronizing all the ttyrec files between all the instances would produce a big overhead and would not be very efficient. Our workflow is the following: - A session is recorded on a bastion instance, it's stored locally as a ttyrec file, as you have seen. - After a few days/weeks (configurable, depends on each cluster), the old ttyrec files are compressed and encrypted (to `.gpg` files), and moved locally to another folder. At that point, the ttyrec file can no longer be accessed by the user with the `selfPlaySession` command. It can still be decrypted/viewed by somebody with local access to the bastion (and access to the gpg key and password, of course). At the same time, those files are also pushed to a remote escrow filer. This is now possible because the files are encrypted, so there is no security/confidentiality concern getting those out of the bastion. - After a few more days/weeks, the local copiess of these compressed-encrypted ttyrec files, that have already been pushed to the escrow filer, are deleted, to ensure we always have room for the fresh ttyrecs that are continually produced. So, the workflow to check all the ttyrec of an user, for example, is either to have a look at the escrow filer, where we have everything, or, if the time window is recent, check on the bastions directly. We know where to look because every command or access is logged to syslog, and this is pushed to a centralized location, so we can make queries to know exactly what ttyrec files have been produced, and where those are stored. The script we use to compress/encrypt/rotate/push/delete ttyrec files is `bin/cron/osh-encrypt-rsync.pl`, with its corresponding configuration found at `/etc/bastion/osh-encrypt-rsync.conf`.
Author
Owner

@jonathanmarsaud commented on GitHub (Mar 18, 2021):

Thanks for your answer @speed47, we will design a similar workflow.
And thanks for The Bastion anyway!

<!-- gh-comment-id:801809593 --> @jonathanmarsaud commented on GitHub (Mar 18, 2021): Thanks for your answer @speed47, we will design a similar workflow. And thanks for The Bastion anyway!
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/the-bastion#36
No description provided.