on my PC, I have my private SSH key, encrypted with a good password. As I control this environment, I make sure this is the only copy of my private key, and all backup copies are encrypted with other passwords.
On my VPS that I use as a jumphost, I have my public key in .ssh/authorized_keys. So my login does not even have a password on that server.
When I'm logged in to the VPS, I can do
ssh -A email@example.com with this command, the server 126.96.36.199 authenticates me through my public key, and the VPS acts as the SSH agent proxy. So, if that server has my public key in .ssh/authorized_keys, I'm easily in, and no security breach on the VPS would affect my security.
II. Secure data on a foreign machine ==========================
so, your VPS is in an untrusted environment, and you need to store sensitive data on it (e.g. VPN configuration and keys).
You create a cryptfs folder, mount it with a manually entered password, and store your sensitive data on it. As long as the server is running, your processes can access the data. If the server reboots, it needs to notify the operator via email or SMS, and the operator logs in and mounts the cryptfs again.
Of course depending on the virtualization technology, your provider may log in from the VM console and see your data. So, you either trust your provider, or use a physical machine like pcengines. On the latest DENOG meeting, there was an interesting report that offline RAM chips still hold traces of your data for few hours, so be careful with that too :)
As an alternative to cryptfs, you can mount a RAM disk and initialize its content from your home location via an SSH tunnel. If you use Git, you can also do incremental updates to the running system.
III. Off-site backups ==============
what I do is let my home NAS pack the data directory, encrypt it with AES256, and push towards the VPS server. So, nightly I transfer a few hundred megabytes. It works fine as long as I keep the footprint within reasonable limits.
As an alternative, there was somewhere a project that modifies rsync in a way that it can work with encrypted data on the remote site.
did I miss something?
>________________________________ > From: Silvan Gebhardt <gebhardt@open...> >To: swinog@list... >Sent: Saturday, June 2, 2012 11:50 AM >Subject: Re: [swinog] hosting for 1 powersupply with lan port > > >Good Morning! > > >The cloud is completely anonymous, that makes the feeling to do something (as a provider) much lower in my opinion. Knowing someone, even the face, is much better. Since I know this point I did not call it "physical security" but "security through obscurity" on purpose. Since such a plug PC makes extraction of data a bit more complex - possible always - I gain time. Time when the box is offline to revoke my keys ;) > > >I do have to trust the people I will be hosting it with, there is a reason I do it in switzerland. (Yes, I belive after beeing the nation of money we will be the *data bankers* soon) > > >@Stanislav: Interesting flag with SSH -A - I will have to read there futher, is this something like PFS with IPSEC? never heard about that flag. > > >I think we are creating a topic for next swinog here. "Networking for Mobile workers (Mosh) with paranoia" > > > > >Am 02.06.2012 08:57, schrieb Viktor Steinmann: >Interesting topic, especially looking at the current cloud trends. We've been discussing this internally and came to the conclusion, that as long as someone has physical access to a server, he will always be capable of reading the data on that server with more or less effort. >> >>Even using a high level of physical security to ensure, nobody has physical access to the box can be broken with enough time and effort, especially from the people housing the box. >> >>In the end, all you need is trust. If you trust the people housing your box and if you trust their ability to keep the bad guys physically away, everything is fine. If you can't trust them you are lost in any case. >> >>Kind regards, >>Viktor >> >>Am 02.06.2012 01:05, schrieb Stanislav Sinyagin: >>security by obscurity? >>>you know, with a JTAG adapter and a bit of knowledge, one can read the onboard flash from those plugs too. >>>so, probably a better approach is to have a system which doesn't expose your data when the disk is compromised. The simplest example is SSH with public key authentication and authentication forwarding (-A flag). >>> >>> >> >> >> >>_______________________________________________ swinog mailing list swinog@list...http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog > > >_______________________________________________ >swinog mailing list >swinog@list... >http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog > > >