Another "Server refused our key after upgrade to vyos 1.3.x" issue

Creating a new topic since the other thread seems to have a different trajectory. Symptoms are similar.
After upgrade from 1.2.x to 1.3.x:

  • ssh logins are refused (both public key + password logins)
  • password reset from option in boot-menu doesn’t help
  • boot-process ends with “configure failed” (system/most services come back up but login isn’t possible)

After going back to 1.2.x, pulling config.boot and trying to load/commit in fresh 1.3.1-S1-install it turns out that there are 2 problems.

  1. user/login-configs can’t be commited due to: “User root can’t be created, conflict with local system account!” Apparently that doesn’t only affect the root user but the entire “system login” node in the config.
  2. wireguard interfaces can’t be commited due to: “Wireguard private-key not found”

The latter isn’t too much of an issue (can be fixed manually after the upgrade). But the login issue MUST NOT happen imho. I would actually rate that as a rather serious bug - even if the problem results from config-nodes that have been deprecated long ago (history of the config goes back to Vyatta 6.1 days).


  • is there any way to access logs from another version (like accessing configs with “copy file 1.2.1://config/config.boot to…”)
  • what’s the recommended process to get the update done after a failure - switch back to working version, delete failed image, delete root from “system login” config node, re-add image?

answering the questions myself - for trouble-free upgrade:

  • switch back to previous 1.2.x version
  • delete failing image: delete system image 1.3.x
  • delete root-user from config - in config-mode run: delete system login user root
  • copy wireguard keys into 1.3.x default key directory and set permissions:
    sudo mkdir /config/auth/wireguard/default
    sudo chmod o-rx /config/auth/wireguard/default
    sudo cp /config/auth/wireguard/*.key /config/auth/wireguard/default/
    sudo chmod 640 /config/auth/wireguard/default/*.key
  • run upgrade again

Hi @lauratech,

thanks for the answer of your question. The reson is VyOS 1.3 does not allow CLI login names which conflict with basic Linux standard account names, e.g. root.


I’ve no doubt there are good reasons for the behaviour. Would still be helpful if the scenario was handled better by the upgrade-mechanism. A disclaimer in the release notes/docs would also do (might have saved me a trip to the office).