ok, more to the details.
I. SSH auth. forwarding
=================
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 ssinyagin@1.2.3.4
with this command, the server 1.2.3.4 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 <gebha...@openfactory.ch>
>To: swinog@lists.swinog.ch
>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@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
>
>
>_______________________________________________
>swinog mailing list
>swinog@lists.swinog.ch
>http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
>
>
>
_______________________________________________
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
