session_id problem : KeyError: 8873498640803430656

[doudz]

I'm trying to use smbprotocol to connect to a AS400 share but I get the following error :

Python 3.8.10 (default, Jun 22 2022, 20:18:18)
[GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import smbclient
>>> smbclient.register_session('10.0.1.1', username='xxxxxx', password='xxxxxxx')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/srv/vitanet_env/lib/python3.8/site-packages/smbclient/_pool.py", line 383, in register_session
    session.connect()
  File "/srv/vitanet_env/lib/python3.8/site-packages/smbprotocol/session.py", line 324, in connect
    self.connection.session_table[self.session_id] = self.connection.preauth_session_table.pop(self.session_id)
KeyError: 8873498640803430656

Could you help me to fix this ?

[jborean93]

This is interesting, this happens just after the authentication attempt is completed but it seems like the pre authentication session id is not matching up with the final session id causing this key error. Is it possible for you to either send through a network capture or debug logs from smbprotocol of this failed exchange. This does technically have the authentication has and potentially some environment details so you are free to send it through to my email rather than posting it here. If you cannot do this then it would be great to know these 3 things on each of the message headers exchanged

• Command
• SessionId
• NT Status - this is only on the reply from the server

[doudz]

[doudz]

[doudz]

[doudz]

[jborean93]

Ok I think I might understand what's going on. Can you share the the negotiated dialect was in the Negotiate Response.

If it is 3.1.1 then the server isn't acting the way it should. The intermediate Session Setup Response with STATUS_MORE_PROCESSING_REQUIRED should have the session id allocated by the server which smbprotocol uses to track the messages for the pre auth hash calculation. It may be possible to still handle this but I would need to look at the code.

[doudz]

I don't see any Negotiate Protocol request or Negotiate Protocol response in Wireshark

[doudz]

[doudz]

I tried to connect the shared folder using Windows and now Wireshark is catching a Negotiate Protocol Response

Looks like dialect is 2.0.2

[doudz]

I sent you the full debug log by email

[jborean93]

Thanks for the info, I believe I understand what the problem is now and https://github.com/jborean93/smbprotocol/pull/203 should fix this issue for you. It would be great if you could test out the changes in that PR as I do not have a host I can test this scenario with to prove it works.

[doudz]

I'm sorry but it doesn't work, now I have another error

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/sramage/.local/lib/python3.8/site-packages/smbclient/_pool.py", line 402, in register_session
    session.connect()
  File "/home/sramage/.local/lib/python3.8/site-packages/smbprotocol/session.py", line 393, in connect
    raise SMBException(
smbprotocol.exceptions.SMBException: SMB encryption or signing was required but session was authenticated as a guest which does not support encryption or signing

[jborean93]

This error is raised by https://github.com/jborean93/smbprotocol/blob/a8853569790a5d973d2a9288d4860f32def8371a/src/smbprotocol/session.py#L393. It should only occur if the SESSION SETUP RESPONSE has one of the following flags

• SMB2_SESSION_FLAG_IS_GUEST - If set, the client has been authenticated as a guest user.
• SMB2_SESSION_FLAG_IS_NULL - If set, the client has been authenticated as an anonymous user.

The connection is by default setup to require signing and because a guest or anon user do not have the required session context needed to sign or encrypt messages this fails. You can opt out of signing by registering the session first with require_singing=False like so

smbclient.register_session('10.0.1.1', username='xxxxxx', password='xxxxxxx', require_signing=False)

You should really look into seeing if your server can support at least signing because this leaves you susceptible to man in the middle and relay attacks, hence why the default is True. You might find that it is using the Guest account which is simply the host accepting any username and ignoring the password. Maybe the username and password you used were not correct and need to be updated.

[jborean93]

The fact that you got to that part shows the session is being created, you just now have another problem. As the original issue is fixed I'm closing the issue. If you do have any further problems please open a new issue and we can move forward from there.