mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-08-26 11:55:50 -05:00
[GH-ISSUE #5322] Bitwarden Android Beta (2024.12.0 (19597)) fails to sync with SSH keys #35070
Reference in New Issue
Block a user
Originally created by @segln on GitHub (Dec 23, 2024).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/5322
Vaultwarden Support String
Your environment (Generated via diagnostics page)
EXPERIMENTAL_CLIENT_FEATURE_FLAGS=ssh-key-vault-item,ssh-agent
Config & Details (Generated via diagnostics page)
Show Config & Details
Environment settings which are overridden: ADMIN_TOKEN
Config:
Vaultwarden Build Version
v1.32.7
Deployment method
Official Container Image
Custom deployment method
No response
Reverse Proxy
nginx/1.27.2
Host/Server Operating System
Linux
Operating System Version
6.12.4-arch1-1 x86_64 GNU/Linux
Clients
Android
Client Version
Android Beta 2024.12.0 (19597)
Steps To Reproduce
Expected Result
Sync success
Actual Result
Sync failed
Logs
Bitwarden Android Beta:
adb logcatlogThe log reports
Network Error: https://api.bitwarden.com/syncbut I'm connecting to Vaultwarden so that can be ignored.Screenshots or Videos
No response
Additional Context
Details
Bitwarden Android Beta requires
ciphers.sshKey.keyFingerprint, but Vaultwarden's/api/syncdoes not return this property.This bug does not occur if the SSH key is not in the vault.
Vaultwarden's SSH key feature works well with the Desktop client.
@BlackDex commented on GitHub (Dec 23, 2024):
Vaultwarden doesn't have anything special for this except that it returns the json blob exactly as received. It probably means the stored data is not valid i think. But i haven't checked it.
Does the fingerprint show in the desktop client?
@segln commented on GitHub (Dec 23, 2024):
Yes, on desktop client with Linux and Windows SSH key features (add, list, edit, etc...) works well.
@BlackDex commented on GitHub (Dec 23, 2024):
Could you check the database for this specific key and what is in the data column?
@segln commented on GitHub (Dec 23, 2024):
Here is the data for the SSH key row.
@BlackDex commented on GitHub (Dec 23, 2024):
Not sure how your export was done because of the double
"", but it sure looks like the data is there.Ill have to check my self how this is returned to the client then.
But as you can see here it should return this as-is.
https://github.com/dani-garcia/vaultwarden/blob/ed4ad67e732c213beaec78970cdb68e48bee3dc1/src/db/models/cipher.rs#L346...L356
@segln commented on GitHub (Dec 23, 2024):
I've corrected it by changing the export format.
And yes, the data exists. I've reinstalled the Android Bitwarden Beta app multiple times and tried on different devices, but it's still the same. I'm not sure what the problem is.
@BlackDex commented on GitHub (Dec 23, 2024):
You could try to install the dev version of the Android client which should output the request and response data of the http call. Which in turn should show if the data is there or not.
@segln commented on GitHub (Dec 23, 2024):
I completely wiped all SSH key rows from the database and reimported keys, and the symptoms disappeared.
I'm still not sure why the error occurred. For now, the problem has been resolved.
@Dubzer commented on GitHub (Jan 3, 2025):
hi there. I'm having the same problem and I've found the cause of it
here's a log from the app:
turns out that
keyFingerprintis null for an SSH key that I don't even have... or so I thought, until I looked in the Trash from the browser extension and there were some keys with no fields other than the name!I'm not sure when these keys were created. maybe there was a bug in some client that was fixed. or in the SSH agent
either way, I don't think it makes sense for the backend to allow such keys, since clients will reject anything that appears to be an invalid key
@BlackDex
@BlackDex commented on GitHub (Jan 3, 2025):
The problem is, that we actually do not care what the data object is and how this is formed.
It does manifest these kind of issue unfortunately though.
The main reason for us to not care on what the clients are sending as data blob, is that new features or additions which are done via that data blob will just work out-of-the-box, without us having to update it every time.
It has the downside of these kind of issue. What we currently do is fix the output of the sync.
But, we have not yet done this for invalid ssh-keys, so those could cause an issue it seems.
But, yes this is because of the clients not sending the correct data back to the server, and could be a faulty client indeed.