From: Richard S. <hob...@gm...> - 2012-12-11 03:40:00
|
Just a shameless plug here... I was "upgrading" my old Fedora 14 MythTV box to CentOS 6.3 which didn't go so well on the MythTV front, but that's another story. Well when that didn't work I decided to go with Fedora 17. In both cases I have a /var lvm partition but since all my pictures, movies, and music are on it I went in manually and deleted everything except those folders. Well when I did this for Fedora 17, I accidentally deleted my pictures folder, arguably the worst one to lose! Well after getting the system up I went in and logged in as the backuppc user, killed the IP from known_hosts (since it generated a new rsa key on install) and did a ssh-copy-id (much easier then doing the key exchange by hand) an voila! Went into the cgi interface and started a restore and it worked the first time 100%. About 19GB worth of pictures (and short movie clips recorded by the digital camera). I think the wife would have put me in the hospital if I had lost them permanently! Thanks, Richard |
From: Tyler J. W. <ty...@to...> - 2012-12-11 11:08:28
|
On 2012-12-11 03:39, Richard Shaw wrote: > Well after getting the system up I went in and logged in as the > backuppc user, killed the IP from known_hosts (since it generated a > new rsa key on install) and did a ssh-copy-id (much easier then doing > the key exchange by hand) an voila! Consider: root@venkman:~# cat /var/lib/backuppc/.ssh/config Protocol 2 HashKnownHosts no StrictHostKeyChecking no > Went into the cgi interface and started a restore and it worked the > first time 100%. About 19GB worth of pictures (and short movie clips > recorded by the digital camera). Fantastic! BackupPC has saved my butt many, many times. Not only will it safe you from disaster, it acts as a great poor man's version control. Regards, Tyler -- "[...] we are not attacking the corporations, but endeavoring to do away with any evil in them. We are not hostile to them; we are merely determined that they shall be so handled as to subserve the public good. We draw the line against misconduct, not against wealth." -- Theodore Roosevelt |
From: Holger P. <wb...@pa...> - 2013-03-25 02:54:15
|
Hi, [for the archives] Tyler J. Wagner wrote on 2012-12-11 11:08:17 +0000 [Re: [BackupPC-users] Thank you BackupPC!!!]: > [...] > Consider: > > root@venkman:~# cat /var/lib/backuppc/.ssh/config > Protocol 2 > HashKnownHosts no > StrictHostKeyChecking no actually, don't. StrictHostKeyChecking is on by default for a good reason. Without it, you're vulnerable to MITM attacks, like the message says, or in the case of BackupPC even to substitution of your backup target. You think it's ssh, but it isn't, unless you are certain that you are connecting to the correct target. I've used 'StrictHostKeyChecking no' myself, but only ever for a specific host (or config file entry) when I know *in advance* that the key will be changing legitimately. The message and the fact that ssh won't connect are a nuisance, and that's not because the authors of the software like annoying people, it's because it's crucial. The message doesn't mean "hey, you should remember to update your settings", it means "this connection is insecure (or at least can be)". Once you get into the habit of taking security lightly, you won't treat it seriously when you need to. As for HashKnownHosts, what is the point of switching it off? Try 'ssh-keygen -R host' and 'ssh-keygen -R ip'. Then again, for the backuppc user it's probably evident anyway to which hosts connections are established, so there may not be much point in hashing known_hosts. Regards, Holger |
From: Tyler J. W. <ty...@to...> - 2013-03-25 09:51:26
|
On 2013-03-25 02:53, Holger Parplies wrote: > actually, don't. StrictHostKeyChecking is on by default for a good reason. > Without it, you're vulnerable to MITM attacks, Which in the case of SSH key authentication, means only that the data crossing the SSH tunnel could be read. While that's bad, especially if backing up /etc/shadow on an older server with md5 password hashes, it's not nearly as dangerous as a MITM attack with password authentication. Don't do it if you don't understand the risks. In this case, I think it's a fair trade - convenience versus a very rare risk. Regards, Tyler -- "Privacy has to be viewed in the context of relative power. For example, the government has a lot more power than the people. So privacy for the government increases their power and increases the power imbalance between government and the people; it decreases liberty. Forced openness in government – open government laws, Freedom of Information Act filings, the recording of police officers and other government officials, WikiLeaks – reduces the power imbalance between government and the people, and increases liberty." -- Bruce Schneier |