Is syncing private keys a good idea?
Ubuntu One storage is not encrypted with a user cryptographic key
Like Dropbox, Ubuntu One store is not encrypted with a special passphrase. Therefore, it would be technically possible for someone to get access to your data, either by an untrustworthy employee or by a security breach. See this bug report about UbuntuOne storage data encryption it is still a wishlist.
So I would not synced my ~/.ssh folder to the cloud. Unless you set an encrypted container which is then sent over to the cloud, but then for ssh keys, it is not always that handy. But I give you still handy ways of encrypting your data:
- Safeguarding your storage on Ubuntu One
- Using Cloud storage safely
More information
Ubuntu One is using encryption for the connection (as said in the fact), it means that basically the data are transmitted over some sort of HTTPS. You can use a really well done animation of what is visible to eavesdropper when using HTTPS, courtesy of the EFF (Electronic Frontier Foundation).
By clicking on the HTTPS button on the EFF animation, you will be able to see what is visible to everybody when you put your SSH keys in a Dropbox or Ubuntu One container. As the animation tells, many persons at site.com (e.g. one.ubuntu.com) would be able to view your data (and many more). Even if you would use something like Tor to route all your traffic, it would still mean that people at site.com can access the data.
So you have to encrypt the data before it leaves your computer. So it arrives encrypted at site.com with credentials they don't know about. Of course, you would have to use a strong encryption mechanism so that it would make it extremely slow for the people at site.com to crack it.
Of course in case of a bank, you can not encrypt your money, as you pay the bank to handle it for you. So you have no choice but to trust the bank to make their IT system as secure as their physical vaults so that only a small subset of employees (the ones managing your account) can view and modify your data.
I am quite anxious about putting my ~/.ssh/id_dsa up in the cloud.
Well, one solution is what I do with my ssh and gpg private keys with Dropbox: encrypt them into an archive, and delete the "raw" originals. Whenever needed, I temporarily extract it and then delete it when done.
I use p7zip (uses AES-256 encryption), but you could use a number of other tools. That way, all that gets synced is the encrypted archive, and even if the cloud storage is compromised, no one can extract the private keys unless they know the passphrase for the archive.
To make life easier for stuff you do frequently (say, gpg decryption), you can have a simple bash script handle the temporary decryption/use/deletion part; it should also disable any sync daemons temporarily so that the extracted keys aren't accidentally synced over.
You can save your keys on U1 through the backup tool Deja-dup. If you set a password the backup files are encrypted automatically on U1. No need to do this manually.
There are different available metrics for defining risk, but you need to take into account the value of the data or systems which the key could give access to. If the key is lost, and some entity can use it gain access, what will be compromised? Is the fear going to be exposure of confidential data, data loss, the possibility of compromising accounts from an administrative or account level, etc.? If you can recreate data that isn't confidential, and if you have confidential data stored securely (e.g., encrypted), this is less pressing. I think that enumerating workarounds for different weaknesses in the system is part of defining your over-all risk. Pragmatically, it's unlikely that storing your .id_rsa will be a problem, especially if you rotate keys at some interval. This relies on several assumptions, but nevertheless, I would not store the .ssh data unencrypted if that's a viable option.