This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Bug: SSH keys disappear when Admin has 2-Factor authentication enabled

There may be a bug in SFOS regarding SSH keys.

we noticed on 2 different SFOS firewalls, one XG430 (SFOS 19.0.1 MR-1-Build365) and one XGS136 (SFOS 19.5.1 MR-1-Build278) that SSH Keys you add here:

after you have enabled Multi Factor Authentication or 2FA for the admin

disappear from the config and can no longer be used after a HA-failover. Probably a normal reboot also recreates the issue. i have not tested if it is related to HA but both systems are in HA.

To confirm the issue I have already seen on the 19.0.1 machine, on the 19.5.1 machine I logged on with my normal pesonal admin user, not the admin, added one SSH key.

I needed to confirm it with the admin password.

Then logged in as admin and enabled 2FA / MFA for the admin user. logged out.

Then later I logged in with my personal admin, not the admin user, user again and added a second SSH key.

I needed to confirm it now with admin password+2FA code.

I rebooted the HA primary node hours later -> the AUX node becomes primary -> HA fallback was enabled so when the rebooted node was online again, it became the new primary again. When the HA-resync was complete I logged in Webadmin and found that the second SSH Key was gone.

Can someone confirm that please?



This thread was automatically locked due to age.
Parents
  • Hi  ,

    I tried to simulate this on a XGS116 (SFOS 19.5.1 MR-1-Build278) but on a standalone setup. 

    What I tested:

    -setting up an MFA for default 'admin' + SSH keys - SSH Keys does not disappear on my case

    -setup MFA for a personal admin account + SSH Keys - SSH Keys does not disappear as well.

     

    Can you confirm that your scenario only happened on HA setups and not on standalones? 

    Also, If your case still persist, kindly open a support ticket to have this further investigated and please share caseID with us and we'll be glad to follow along internally on the progress. 

    Thanks for your time and patience and thank you for choosing Sophos

    Cheers,

    Raphael Alganes
    Community Support Engineer | Sophos Technical Support
    Sophos Support Videos Product Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.

  • Thanks for answering  

    I tested again with a 3rd cluster on that SFOS

    I can tell, adding a key when logged in as admin when 2FA is active works and remains after reboot.

    Adding a second key with a different local admin user works but the key disappears after reboot.

    I'm sure, you can reproduce the issue this way, too.

    .

    Screenshots to prove:

    I add the second test ssh key as different admin user "backup_admin":

    log confirms it - between both key additions, there was one reboot

    Key is shown in GUI:

    reboot device

    after reboot logged in with backup_admin

    confirmed when logged in as admin

  • update: the second SSH key added as admin will remain on the machine even after reboot.

    So the bug is only happening when you add the keys as a different admin user than the admin.

    Steps to recreate:
    1. Create a second admin user. We call it "backup_admin".
    2. login with the admin user
    3. enable 2FA/MFA for the admin user and the backup_admin
    4. login as "backup_admin" enable Public key authentication for admin and add a RSA SSH key to the list and click apply
    5. you need to enter the password+2FA for the admin user - do that
    6. I notice it takes a long time loading and the green success banner is not shown
    7. when the spinning circle disappears, you can see the SSH RSA key added. Reload the page, it is still shown.
    8. check log viewer in the Admin logs - it shows Public Key Authentication were changed by 'backup_admin' from '172.16.xxx.xxx' using 'GUI'
    9. test login with the SSH RSA key you added - it works
    10. reboot the machine
    11. after reboot login with any admin user and check the SSH RSA keys - the key you added before is no longer shown.
    12. you cannot login with SSH RSA Key anymore

Reply Children
  • someone requested the log files already, talking of an already existing Gira ID.
    probably the

    sync_entity: rmsync.c:520:sync_opcode:sshkey_validate: write opcode data 54

    is in relation - because it is always logged when I recreated the issue.

    added the TESTKEY-rsa-key-20230323 to one exiting key

    csc.log

    MESSAGE   Mar 23 16:21:20Z  [worker:9082]: {"request":{"method":"opcode","name":"apiInterface","version":"1.8","type":"json","length":1269,"data":{ "Entity": "PublicKeyAuth", "___serverport": 4444, "allowpubkeyauth": "1", "___component": "GUI", "transactionid": "666", "mode": 2501, "currentlyloggedinuserid": 6, "sshkey": [ "ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxTgUlZ8NRYZn8C\/3Zfls9D7ZbJbI2i+vwNQ== xxxxxxxxxxxxxx_rsa-key-xxxxxxxxxxx", "ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAuYTwwbg8ERK5710rC0c2HsbOxxxxxxxxxxxxxxxxxxxxxxxvYHz3LDjWt0\/hZiOWes4xJHLWTM2081ew== TESTKEY-rsa-key-20230323" ], "APIVersion": "1905.1", "___serverprotocol": "HTTP", "Event": "UPDATE", "___username": "backup_admin", "___meta": { "sessionType": 1 }, "___serverip": "127.0.0.1", "currentlyloggedinuserip": "172.16.xxx.xxx", "username": "backup_admin", "password": "****" }}}
    DEBUG     Mar 23 16:21:53Z  [worker:9712]: # OPCODE Called: 'sshkey_validate'
    MESSAGE   Mar 23 16:21:53Z  [worker:9712]: {"request":{"method":"opcode","name":"sshkey_validate","version":"1.8","type":"json","length":835,"data":{ 'keys' : '["ssh-rsa AAAAB3NzaC1yc2EAAAAxxxxxxxxxxxxxxxxxxxxxUlZ8NRYZn8C/3Zfls9D7ZbJbI2i+vwNQ== xxxxxxxxxxxxxx_rsa-key-xxxxxxxxxxx","ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAuxxxxxxxxxxxxxxxxxYHz3LDjWt0/hZiOWes4xJHLWTM2081ew== TESTKEY-rsa-key-20230323"]'}}}
    DEBUG     Mar 23 16:21:53Z  [worker:9712]: ### insert_uuid: hdr: len=835 content=0 method=0 name=sshkey_validate
    DEBUG     Mar 23 16:21:53Z  [sshkey_validate:9712]: init_db_handle_pl: Initializing DBI DB handle
    --
    DEBUG     Mar 23 16:21:53Z  [sshkey_validate:9712]: log_exec: Command: /bin/ssh-keygen -l -f /tmp/validkey
    INFO      Mar 23 16:21:53Z  [sshkey_validate:9712]: csc_execve: Child exited with status 0
    INFO      Mar 23 16:21:53Z  [sshkey_validate:9712]: create_act_out_perl_obj: varname=keyvalid
    INFO      Mar 23 16:21:53Z  [sshkey_validate:9712]: create_act_out_perl_obj: keyvalid.status=0
    INFO      Mar 23 16:21:53Z  [sshkey_validate:9712]: create_act_out_perl_obj: TEXT keyvalid.output=2048 SHA256:koF18MyzVMV3ZN+JE779ydRTqS4F/5MLQB9zzkjSpWU TESTKEY-rsa-key-20230323 (RSA)
    INFO      Mar 23 16:21:53Z  [sshkey_validate:9712]: opcode 'sshkey_validate': time taken: 0.178596277 seconds
    DEBUG     Mar 23 16:21:53Z  [worker:9712]: sync_op_service: syncing 'sshkey_validate'
    DEBUG     Mar 23 16:21:53Z  [worker:9712] sync_entity: req: opcode name  sshkey_validate
    DEBUG     Mar 23 16:21:53Z  [worker:9712] sync_entity: rmsync.c:467:sync_opcode:sshkey_validate:read len 70 clen 887 rlen 1024
    DEBUG     Mar 23 16:21:53Z  [worker:9712] sync_entity: rmsync.c:494:sync_opcode:sshkey_validate:len 70 infolen 54
    ERROR     Mar 23 16:21:53Z  [worker:9712] sync_entity: rmsync.c:520:sync_opcode:sshkey_validate: write opcode data 54
    DEBUG     Mar 23 16:21:53Z  [worker:9712] sync_entity: rmsync.c:541:sync_opcode:sshkey_validate: infolen 54 blen 54 reply:
    DEBUG     Mar 23 16:21:53Z  [worker:9712] sync_entity: res: opcode name  sshkey_validate
    DEBUG     Mar 23 16:21:53Z  [worker:9712]: {"Sync Result":{"method":"opcode","name":"sshkey_validate","version":"1.10","type":"text","length":0,"statusCode":200,"statusStrlen":2,"statusString":"OK"}}
    DEBUG     Mar 23 16:21:53Z  [worker:9712]: {"response":{"method":"opcode","name":"sshkey_validate","version":"1.8","type":"text","length":64,"data":{ "status": "200", "is_ed25519": "0", "invalid_key_count": "0" },"statusCode":200,"statusStrlen":2,"statusString":"OK"}}
    DEBUG     Mar 23 16:21:53Z  [worker:9712]: # OPCODE Exited: 'sshkey_validate' with Status: '200'
    DEBUG     Mar 23 16:21:53Z  [readobject:9751]: do_prep_query: PREPSTMT without ARGS: select sshkey as sshkey from tblsshpubkey
    Readobject Executing PREPSTMT Query=select sshkey as sshkey from tblsshpubkey INFO      Mar 23 16:21:53Z  [readobject:9751]: opcode 'readobject': time taken: 0.264141579 seconds
    DEBUG     Mar 23 16:21:53Z  [apiInterface:9082]: do_prep_query: PREPSTMT with ARGS: insert into tblsshpubkey (sshkey) values (?)
    DEBUG     Mar 23 16:21:53Z  [apiInterface:9082]: do_prep_query: PREPSTMT with ARGS: insert into tblsshpubkey (sshkey) values (?)
    DEBUG     Mar 23 16:21:53Z  [readobject:9753]: do_prep_query: PREPSTMT without ARGS: select sshkey as sshkey from tblsshpubkey

  • Hello

    Thanks for providing this  appreciate it. will follow along on our side with regards to progress on the case. 

    Thanks for your time and patience and thank you for choosing Sophos

    Cheers,

    Raphael Alganes
    Community Support Engineer | Sophos Technical Support
    Sophos Support Videos Product Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.

  • Hi  We have raised an investigation with the Dev team for the reported case ID - 06366767, the Investigation ID with Dev is NC-116880, and will keep you posted on the case based on the further investigation from GES/Dev. 

    Regards,

    Vishal Ranpariya
    Technical Account Manager | Sophos Technical Support

    Sophos Support Videos | Knowledge Base  |  @SophosSupport | Sign up for SMS Alerts |
    If a post solves your question use the 'This helped me' link.

  • excellent communication updates on all channels.

    I really appreciate it. I hope it can be ruled out and get fixed in the next version.

    Thanks!

  • Hi  ,

    This issue has been identified as bug and will be fixed in v20.0 EAP0.