-osh selfPlaySession doesn't play saved sessions on CentOS

[extrad]

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.

[speed47]

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.

[extrad]

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.

[speed47]

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?

[extrad]

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

[speed47]

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]

#119 should be merged soon.

[speed47]

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

[extrad]

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