Using Amazon's Elastic Cloud EC2 and Rsync to back up data files

[bene-Gk2boCrsRs1AfugRpC6u6w at public.gmane.org (Ben Eisenbraun)]

I got curious about this whole thing and ended up reading the 
thread, and then the linked how to article, and then Amazon EC2 docs...
so now I have an opinion, and you get to read it!  Yay! </sarcasm>

On Wed, Jan 28, 2009 at 01:55:56PM -0500, James Kramer wrote:
> The only way that I could get the script to work without interactively
> responding to the ssh prompts is to set up the passkey without a
> passphrase which is the way that it is set up in the HowTo.  This
> reduces the security of ssh and makes is easier for man-in-the-middle
> attacks.

I don't see how a passphraseless ssh key increases your risk for MITM
attacks.  And in this particular instance, I don't think you're losing much
security for your backups either, since your backups are transiting through
the host running the backup script in the first place.  If the account 
running the script gets compromised, I assume your backups would be
compromised as well.

Maybe I'm not fully grokking the set up, but the passphraseless bit
wouldn't concern me.

> It was also necessary for me to modify the ssh commands
> which were described in the HowTo by adding an additional option to
> the ssh command:
> 	'ssh -o StrickHostKeyChecking=no .....'
> This further reduces the security of the system, but I can see no
> other way to run the scripts.

No, it doesn't.  You are basically connecting to a "new" sshd on every
single backup run; the value of host key checking is negated by that fact,
not the fact that you have decided to ignore the useless keys.  

>From my reading of the Amazon docs, you have two options for this.  You can
use "ec2-get-console-output instance_id" to read the boot messages for the 
instance, and the sshd server key fingerprint is output in those boot
messages.  You can find it and add it to your known hosts file in your
backup script.  This is still a new key every time, but the ec2 tools give
you an out-of-band (kinda) method for checking the validity of the
fingerprint.

I think your only workaround for this "new key fingerprint every time"
problem is to create your own AMI instance, which can have a static sshd
key.

> Another concern that I have is that the 'known-hosts' file which
> stores the host fingerprints will become increasingly large with each
> run of the script.

Why is that a concern?  Are there known issues with overly large
known_hosts files?  Since the server key fingerprint is useless in the
default set up, you can just define a separate known_hosts file that you 
periodically delete.  That should keep your main known_hosts file from 
getting cluttered up with the garbage entries.

-ben

--
love of meat prevents any real change.	             <douglas coupland>