[GH-ISSUE #114] -osh selfPlaySession doesn't play saved sessions on CentOS

BreizhHardware commented

2026-05-07 00:17:40 +02:00

Owner

Originally created by @extrad on GitHub (Jan 10, 2021).
Original GitHub issue: https://github.com/ovh/the-bastion/issues/114

Thank you, guys, you're doing a fantastic job here.
There are small issues that are not working meanwhile:
I'm playing with a fresh CentOS 7 bastion installation (the-bastion-3.01.03), CentOS Linux release 7.9.2009.
The ttyrec-sessions are saved nicely and can be viewed locally through ttyplay but -osh selfPlaySession always returns "There were no terminal recording for this session" (the ids of the saved session on the disk system and returned via "selfListSessions" - are the same.

Originally created by @extrad on GitHub (Jan 10, 2021). Original GitHub issue: https://github.com/ovh/the-bastion/issues/114 Thank you, guys, you're doing a fantastic job here. There are small issues that are not working meanwhile: I'm playing with a fresh CentOS 7 bastion installation (the-bastion-3.01.03), CentOS Linux release 7.9.2009. The ttyrec-sessions are saved nicely and can be viewed locally through ttyplay but -osh selfPlaySession always returns "There were no terminal recording for this session" (the ids of the saved session on the disk system and returned via "selfListSessions" - are the same.

BreizhHardware closed this issue

2026-05-07 00:17:41 +02:00

BreizhHardware commented

2026-05-07 00:17:42 +02:00

Author

Owner

@speed47 commented on GitHub (Jan 11, 2021):

Hello @extrad , thanks for taking the time to post this issue.

The "There were no terminal recording for this session" message you get appears when we don't have any ttyrec file name stored in the account's local sqlite database for a given session. This is expected if the session was not an ssh connection but just an osh command, for example "--osh help" or such. However if you're trying to play an ssh session, and you can find a file on the local file system with the same ID, this is unexpected.

For a given session ID where you can reproduce the problem (you get the "no terminal recording" message but can find the ttyrec file on the local filesystem), could you dump the sqlite row for this database, this way:

bastion# sqlite3 -readonly -line /home/ACCOUNT/ACCOUNT-log-202101.sqlite "select * from connections where uniqid='SESSIONID'"

Of course replacing ACCOUNT and SESSIONID with the proper values you have.

You should get an output like this:

              id = 35
       timestamp = 1607610655
   timestampusec = 169187
         account = test
         cmdtype = ssh
         allowed = 1
        hostfrom = localhost
          ipfrom = 127.0.0.1
        portfrom = 46764
       bastionip = 127.0.0.1
     bastionport = 22
          hostto = localhost
            ipto = 127.0.0.1
          portto = 22
            user = foo
          plugin = 
      ttyrecfile = /home/test/ttyrec/127.0.0.1/2020-12-10.14-30-55.141676.02d2f398d502.test.foo.127.0.0.1.22.ttyrec
      ttyrecsize = 
          params = ttyrec -f /home/test/ttyrec/127.0.0.1/2020-12-10.14-30-55.141676.02d2f398d502.test.foo.127.0.0.1.22.ttyrec -F /home/test/ttyrec/127.0.0.1/%Y-%m-%d.%H-%M-%S.#usec#.02d2f398d502.test.foo.127.0.0.1.22.ttyrec -- /usr/bin/ssh 127.0.0.1 -l foo -p 22 -i /home/test/.ssh/id_rsa4096_private.1607606589 -q -o PreferredAuthentications=publickey
    timestampend = 1607633292
timestampendusec = 20212
     returnvalue = -9999
         comment = signal_HUP
          uniqid = 02d2f398d502

The ttyrecfile column is what selfPlaySession uses to find the ttyrec file name to play from the local filesystem.

@speed47 commented on GitHub (Jan 11, 2021): Hello @extrad , thanks for taking the time to post this issue. The "There were no terminal recording for this session" message you get appears when we don't have any ttyrec file name stored in the account's local sqlite database for a given session. This is expected if the session was not an ssh connection but just an osh command, for example "--osh help" or such. However if you're trying to play an ssh session, and you can find a file on the local file system with the same ID, this is unexpected. For a given session ID where you can reproduce the problem (you get the "no terminal recording" message but can find the ttyrec file on the local filesystem), could you dump the sqlite row for this database, this way: `bastion# sqlite3 -readonly -line /home/ACCOUNT/ACCOUNT-log-202101.sqlite "select * from connections where uniqid='SESSIONID'"` Of course replacing ACCOUNT and SESSIONID with the proper values you have. You should get an output like this: ``` id = 35 timestamp = 1607610655 timestampusec = 169187 account = test cmdtype = ssh allowed = 1 hostfrom = localhost ipfrom = 127.0.0.1 portfrom = 46764 bastionip = 127.0.0.1 bastionport = 22 hostto = localhost ipto = 127.0.0.1 portto = 22 user = foo plugin = ttyrecfile = /home/test/ttyrec/127.0.0.1/2020-12-10.14-30-55.141676.02d2f398d502.test.foo.127.0.0.1.22.ttyrec ttyrecsize = params = ttyrec -f /home/test/ttyrec/127.0.0.1/2020-12-10.14-30-55.141676.02d2f398d502.test.foo.127.0.0.1.22.ttyrec -F /home/test/ttyrec/127.0.0.1/%Y-%m-%d.%H-%M-%S.#usec#.02d2f398d502.test.foo.127.0.0.1.22.ttyrec -- /usr/bin/ssh 127.0.0.1 -l foo -p 22 -i /home/test/.ssh/id_rsa4096_private.1607606589 -q -o PreferredAuthentications=publickey timestampend = 1607633292 timestampendusec = 20212 returnvalue = -9999 comment = signal_HUP uniqid = 02d2f398d502 ``` The `ttyrecfile` column is what `selfPlaySession` uses to find the ttyrec file name to play from the local filesystem.

BreizhHardware commented

2026-05-07 00:17:42 +02:00

Author

Owner

@extrad commented on GitHub (Jan 11, 2021):

Yes, for some reason the 'ttyrecfile' field is empty in that case (though the correct filename can still be seen in 'params').
I don't know if it's related but in my case 'timestampend', 'timestampendusec' and 'returnvalue' are empty when comparing your output to mine.

@extrad commented on GitHub (Jan 11, 2021): Yes, for some reason the 'ttyrecfile' field is empty in that case (though the correct filename can still be seen in 'params'). I don't know if it's related but in my case 'timestampend', 'timestampendusec' and 'returnvalue' are empty when comparing your output to mine.

BreizhHardware commented

2026-05-07 00:17:43 +02:00

Author

Owner

@speed47 commented on GitHub (Jan 12, 2021):

Interesting, this would mean the bastion couldn't log those values at the end of the connection. Was the connection terminated in an "abrupt way"? Do you have a returnvalue and comment, or are those empty too?

In any case, the ttyrecfile column is filled at the beggining of the connection, not at the end, so if the "params" is filled, the "ttyrecfile" column should be too. I'll try to dig in the code around that part to see why it could happen. Do you have this behaviour often? all the time? only on rare cases?

EDIT: what version are you using? The latest stable release or the latest commit on the main branch?

@speed47 commented on GitHub (Jan 12, 2021): Interesting, this would mean the bastion couldn't log those values at the end of the connection. Was the connection terminated in an "abrupt way"? Do you have a returnvalue and comment, or are those empty too? In any case, the ttyrecfile column is filled at the beggining of the connection, not at the end, so if the "params" is filled, the "ttyrecfile" column should be too. I'll try to dig in the code around that part to see why it could happen. Do you have this behaviour often? all the time? only on rare cases? EDIT: what version are you using? The latest stable release or the latest commit on the main branch?

BreizhHardware commented

2026-05-07 00:17:44 +02:00

Author

Owner

@extrad commented on GitHub (Jan 12, 2021):

Latest commit on the main branch. I'm getting this behaviour every time.
sqlite3 -line /home/ACCOUNT/ACCOUNT-log-202101.sqlite "select * from connections where uniqid='25afc639433e'" id = 83 timestamp = 1610457171 timestampusec = 767349 account = ACCOUNT cmdtype = ssh allowed = 1 hostfrom = x.x.x.x ipfrom = x.x.x.x portfrom = 63275 bastionip = y.y.y.y bastionport = 22 hostto = chantal ipto = z.z.z.z portto = 22 user = root plugin = ttyrecfile = ttyrecsize = params = ttyrec -f /home/ACCOUNT/ttyrec/x.x..12.22/2021-01-12.08-12-51.766201.25afc639433e.ACCOUNT.root.x.x..12.22.22.ttyrec -F /home/ACCOUNT/ttyrec/x.x..12.22/%Y-%m-%d.%H-%M-%S.#usec#.25afc639433e.ACCOUNT.root.x.x..12.22.22.ttyrec -- /usr/bin/ssh x.x..12.22 -l root -p 22 -i /home/keykeeper/keyoperators/id_ed25519_operators.1610288534 -o PreferredAuthentications=publickey timestampend = timestampendusec = returnvalue = comment = uniqid = 25afc639433e

@extrad commented on GitHub (Jan 12, 2021): Latest commit on the main branch. I'm getting this behaviour every time. `sqlite3 -line /home/ACCOUNT/ACCOUNT-log-202101.sqlite "select * from connections where uniqid='25afc639433e'" id = 83 timestamp = 1610457171 timestampusec = 767349 account = ACCOUNT cmdtype = ssh allowed = 1 hostfrom = x.x.x.x ipfrom = x.x.x.x portfrom = 63275 bastionip = y.y.y.y bastionport = 22 hostto = chantal ipto = z.z.z.z portto = 22 user = root plugin = ttyrecfile = ttyrecsize = params = ttyrec -f /home/ACCOUNT/ttyrec/x.x..12.22/2021-01-12.08-12-51.766201.25afc639433e.ACCOUNT.root.x.x..12.22.22.ttyrec -F /home/ACCOUNT/ttyrec/x.x..12.22/%Y-%m-%d.%H-%M-%S.#usec#.25afc639433e.ACCOUNT.root.x.x..12.22.22.ttyrec -- /usr/bin/ssh x.x..12.22 -l root -p 22 -i /home/keykeeper/keyoperators/id_ed25519_operators.1610288534 -o PreferredAuthentications=publickey timestampend = timestampendusec = returnvalue = comment = uniqid = 25afc639433e `

BreizhHardware commented

2026-05-07 00:17:44 +02:00

Author

Owner

@speed47 commented on GitHub (Jan 12, 2021):

OK, this is a regression from a commit between the latest release and the current release candidate (just out 1 hour ago), thanks for the report, fortunately the fix is easy!

BTW, it's advised to always use the latest stable tagged version, as outlined in the install doc, you're less likely to bump into little bugs like that, the main branch is always usable and should never be completely broken, but as some big code chunks are merged, it can take some time to stabilize and catch the few bugs that made it past the tests ;)

Now if course if you did it on purpose, that's also fine: it helps squashing potential bugs between releases! I'm preparing the fix.

@speed47 commented on GitHub (Jan 12, 2021): OK, this is a regression from a commit between the latest release and the current release candidate (just out 1 hour ago), thanks for the report, fortunately the fix is easy! BTW, it's advised to always use the latest stable tagged version, as outlined in the [install doc](https://ovh.github.io/the-bastion/installation/basic.html#install-basic-get-the-code), you're less likely to bump into little bugs like that, the main branch is always usable and should never be completely broken, but as some big code chunks are merged, it can take some time to stabilize and catch the few bugs that made it past the tests ;) Now if course if you did it on purpose, that's also fine: it helps squashing potential bugs between releases! I'm preparing the fix.

BreizhHardware commented

2026-05-07 00:17:44 +02:00

Author

Owner

@speed47 commented on GitHub (Jan 12, 2021):

#119 should be merged soon.

@speed47 commented on GitHub (Jan 12, 2021): #119 should be merged soon.

BreizhHardware commented

2026-05-07 00:17:45 +02:00

Author

Owner

@speed47 commented on GitHub (Jan 14, 2021):

v3.01.99-rc2 is out, with a fix for this

@speed47 commented on GitHub (Jan 14, 2021): v3.01.99-rc2 is out, with a fix for this

BreizhHardware commented

2026-05-07 00:17:45 +02:00

Author

Owner

@extrad commented on GitHub (Jan 14, 2021):

Can confirm that it's working fine now, thanks for the prompt updates.

@extrad commented on GitHub (Jan 14, 2021): Can confirm that it's working fine now, thanks for the prompt updates.

Rows
Columns

[GH-ISSUE #114] -osh selfPlaySession doesn't play saved sessions on CentOS #27