Imagine the following situation: you have to compile some Linux/Unix application or kernel module that requires kernel source present at your hard drive, say, in /usr/src/kernels/kernel-2.6.21-i386/ or elsewhere. But there is not enough disk space to copy these sources or install kernel-devel or linux-source packages (in Fedora/RedHat or Ubuntu/Debian distros respectively)… Sounds familiar? Believe me, sometimes it happens

As a solution you can mount the directory of some remote PC that contains needed kernel source. It can be done via several protocols like smb, ftp etc. In this article we will mount remote directory using ssh protocol that is one the most popular for remote and secure access to Linux boxes over the network.

Below are the steps which should be taken to get the ball rolling. We need two packages: sshfs and fuse-utils.

1. Install necessary packages:

a. Ubuntu/Debian:

sudo aptitude install fuse-utils sshfs

b. Fedora/Centos/RedHat:

yum install fuse-sshfs fuse fuse-libs

c. Other Linux: download and compile sshfs/fuse from sources

2. Check that kernel module fuse is loaded:

lsmod | grep fuse

There should be the line containing “fuse” in the output (of not try modprobe fuse).

3. Mount remote filesystem using something like this (two commands):

mkdir -p /mnt/sshfs/
sshfs remote-user@remote-machine:/some/directory /mnt/sshfs

where remote-user is the username allowed to login remote-machine via ssh protocol. It will ask you to type the password so just type it and press return

4. That’s it. Good luck!

1) Start some utility updating the screen before leaving ssh session untouched. I usually use watch -n 1 ‘date’ that shows current date every second. Other simple way is to send icmp requests to some host, e.g. ping google.com.

2) Increase ssh session idle time by

echo “7200″ > /proc/sys/net/ipv4/tcp_keepalive_time

I’ve checked these tips with Fedora Core, CentOS, Debian and Ubuntu but I’m completely sure that it applicable also for other Linux distributions. First tip (ping) can be used in Unix also.

You may also be interested in:
Secure shell (ssh) connection without password
Keep ssh session saved (Unix “screen” utility)
Moving Linux to remote server (over ssh via third server)

After it’s done we should generate public RSA key at client machine and copy it to the list of authorized keys at server.

At client machine execute (leave passphrase empty):

ssh-keygen -t rsa

this would create public key at /home/your_login/.ssh/id_rsa.pub.

Then copy generated key to server (for example by ’scp’ command):

scp /home/your_login/.ssh/id_rsa.pub server_login@server_ip_address:/tmp

After client’s public key is copied to /tmp/id_rsa.pub, login to server and perform the following operation. Add client’s key to authorized keys list by executing command:

mkdir /home/server_login/.ssh #only if it’s needed

cat /tmp/id_rsa.pub >> /home/server_login/.ssh/authorized_keys

When it’s done try to login to server from client:

ssh server_login@server_ip_address

Please note it’s important to copy client’s public key to user’s directory you’re going to login with (in this example it’s sever_login).

Good luck, mates!

Little update: it’s also necessary to uncomment lines in /etc/ssh/sshd_config at server:

RSAAuthentication yes
PubkeyAuthentication yes

And then restart ssh daemon e.g. by command:

/etc/init.d/ssh restart

To prevent this just start ’screen’ utility and run needed command after this. In case of disconnection you’ll need to type ’screen -r’ (-r means restore) and come back to operations you were performing before being disconnected.

This utility is rather powerful and besides allows to create several virtual windows and switch between them by means of hot keys.

Here are some of useful hot keys:

CTRL-a c Create a new window
CTRL-a spacebar Go to next window
CTRL-a backspace or del Go to previous window
CTRL-a 2 Go to window 2
CTRL-a w list windows

First of all it’s necessary to get all servers to be accessible to each other via ssh. Read your distribution’s manual to find out how to achieve it.

There are several possible ways to move Linux to another server by means of using dump/restore utilities over ssh. I’ve chosen this one: I’ve saved source server’s filesystem backup to third server over ssh and then restored this backup to target server (again over ssh).

To do this I’ve installed dump 0.4b41 onto source server and performed the following commands to save it’s /boot and / filesystems backups to third server (both in one line):

dump -0uan -f – /boot | ssh -c aes256-cbc @ dd of=/home/artemn/backup/dump/dump-boot-l0.bak

and

dump -0uan -f – / | ssh -c aes256-cbc @ dd of=/home/artemn/backup/dump/dump-root-l0.bak

It took several hours to transmit 20Gb over Internet in my case. If you’re performing these operations remotely I recommend to use utility screen to be sure that transmitting won’t be stopped when ssh session to source server is closed. To use it just login to source server over ssh and type screen and then dump command with necessary agruments (see below). In case you’ve been disconnected just ssh again and restore screen session by command screen -r.

You can control above mentioned dump command activity by watching file size of dump-root-l0.bak and dump-boot-l0.bak files at third server.

After dump is finished you can check backup at third server by performing restore -i -f dump-root-l0.bak and walking through directories in backup file (use ls command). For further information read restore manual (interactive restore section): man restore.

Then login to target server and partake hard disk in the same way as it’s done at source server. In my case I’ve created three partitions /dev/sda1 for /boot, /dev/sda2 for / and /dev/sda3 for swap. Target server can be running Live CD like Knoppix and have only one hardware drive.

When partitioning is done create filesystems at every partition:

mkfs -t ext2 /dev/sda1

mkfs -t ext2 /dev/sda2

mkswap /dev/sda3

Then set volume labels to just created filesystems by commands:

tune2fs -L “/boot” /dev/sda1

and

tune2fs -L “/” /dev/sda2

Labels should be the same as at source server (you can see them by executing tune2fs -l /dev/sda1 and tune2fs -l /dev/sda2 at source server). Sometimes it’s also necessary to set up volume label for swap filesystem.

When it’s done mount created filesystems by commands:

mount /dev/sda1 /mnt/sda1

and

mount /dev/sda2 /mnt/sda2

(be sure that /mnt/sda1 and /mnt/sda2 are created).

To restore filesystem from backed up copy, ‘cd‘ to destination directory and restore data by commands:

cd /mnt/sda1

and

ssh @ “cat /home/artemn/backup/dump/dump-boot-l0.bak” | restore -r -f -

then

cd /mnt/sda2

and

ssh @ “cat /home/artemn/backup/dump/dump-root-l0.bak” | restore -r -f -

In case of success /mnt/sda1 and /mnt/sda2 will contain the same files at /boot and / directories at source server.

When filesystems restoration is done we should install boot loader onto hard drive of target sever: start grub console by typing grub and then type root (hd0, 0), then setup (hd0). After this boot loader will be installed and target server can be booted from hard disk.

Note: be sure that dump and restore commands run at source and target servers are of same versions as it causes problems sometimes. I’ve used 0.4b41 at Fedora Core 1 (source) and Knoppix (target server).

Another note: I’ve spent a day to solve the problem with kernel panic when booting into target server’s hard disk. The problem was in volume labels. So don’t forget to set them.

Hope it helps somebody! Good luck, mates!