« Posts tagged ssh

Drive Backup over SSH Compressed with Gzip

October 2, 2010 / posted in Infrastructure, Planet CDOT, Security / 2 Comments

If you’ve worked hard to configure your Linux machine and can’t afford to lose it due to drive failure, try creating an image of it using dd periodically.

It wouldn’t make much sense to store the image of the drive on the drive itself, but luckily dd is smart and you can combine it with ssh and gzip to store your stuff off-site.

# dd if=/dev/sda | ssh user@backup.remotehost.com dd of=/backup/drive.img.gz

At this point the drive.img.gz file is quite large. If you’re going over the internet this will take a really long time and kill your bandwidth.

Try this:

# dd if=/dev/sda | gzip | ssh user@backup.remotehost.com dd of=/backup/drive.img.gz

Notice the gzip pipe right before the ssh command compressing the stream before it gets sent to backup.remotehost.com.

You can also tell dd to create an image of a specific partition only (specify /dev/sda2 as the input stream)

To restore a drive image, log into backup.remotehost.com and type:

# dd if=/backup/drive.img.gz | gzip -d | ssh root@livecd.host dd of=/dev/sda

You should only restore to a drive that is not in use (possibly an OS running off of a Live CD?).

Warning: These commands are not idiot-proof and it’s all too easy to wipe the wrong drive!

I was able to reduce my drive.img.gz by almost 75% using gzip! You may find other compression tools to be better or worse depending on the data you are imaging.

Recently I was working on a project where we configured secure MySQL replication between Fedora host A and Fedora host B. There was no RAID or any kind of redundancy and me being paranoid I quickly imaged drive B to drive A and vice-versa.

Warning: keep in mind that creating an image of an OS that uses logical volumes (LVM) may not restore to a new drive properly.

SSH RSA1 Publickey Authentication Issues

September 21, 2010 / posted in Planet CDOT / No Comments

Recently I’ve had to do some basic publickey authentication using Fedora 13 x86/x64, so I started by creating the id file using ssh-keygen -t rsa. After copying the *.pub file to the remote host and making sure the permissions are properly set, I tried connecting.

The pubkey authentication failed and the remote /var/log/secure wasn’t showing anything interesting. On the client I typed the following to troubleshoot further:

slave$ ssh -vvv user@master
Connecting to master…
...
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa type -1
debug3: Not a RSA1 key file /home/user/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '---- BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
...
debug2: key_type_from_name: unknown key type '---- END'
debug3: key_read: missing keytype
...
[pubkey auth fails]
slave$

I looked for an answer on Google, but nothing seemed to help. I was puzzled because I had accomplished the exact same thing on the exact same distro days earlier.

Well it turns out there is a bug in the openssh 5.4p1 (build 1) package that is shipped with the live CD image.

This fixed the issue immediately:

slave# yum update openssh

OpenSSH 5.4p1 (build 3) will be downloaded and everything should be fine.

To figure out exactly what fixed it, I downloaded the source RPM for build 3 and exacted it. The .spec file’s %changelog referenced the bug: #595935 which documents the same problem I encountered.

If you are building from source I’ve attached the .patch to this post. Good luck!

Download OpenSSH patch #595935