Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Ubuntu One's Security FAQ indicates that Canonical encrypts connections and restricts access to user data. This all well and fine, and I do trust SSL for online banking and other things more valuable than my private keys.

That said, I am quite anxious about putting my ~/.ssh/id_dsa up in the cloud. Obviously, no system is totally secure. Could some knowledgeable party, then, pragmatically quantify the risks?

share|improve this question
I've updated my answer, hopefully giving you a better understanding of the risk. – Huygens Jun 10 '12 at 17:29
up vote 6 down vote accepted

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:

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 (e.g. 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 can access the data.

So you have to encrypt the data before it leaves your computer. So it arrives encrypted at 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 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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Simple solution. Sort of. If you can't use something like a USB flash drive, put a passphrase on your SSH key. Instant two-factor authentication (sort of). You don't even have to upload a new public key.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.