You may already be familiar with NFS and Samba for sharing files over a network. While these are both great distributed filesystem solutions, they require extra configuration and setup overhead in order to get them to work. If you want quick and easy access to a remote filesystem then SSHFS may be your best shot.

SSHFS (Secure SHell FileSystem) is a file system for Linux capable of operating on files on a remote computer using just a secure shell login. It is based on sftp (SSH File Transfer Protocol). Setup is easy on the server side, since most servers support SSH out of the box there is nothing to do. On the client side, mounting the filesystem is as easy as logging in with SSH. The end user can seamlessly and securely interact with remote files as if they were local to your machine.

Advantages of SSHFS over NFS/Samba:

• Utilizes SSH and is therefore very secure.
• Allows secure access to remote filesystems outside of your local network.
• Requires no special configuration on the server side.

Disadvantages:

• Slightly slower, although the difference is fairly small.
• Does not show filesystem usage statistics.
• Requires a user account on the server side.
• Not a true distributed file system, single point to point sharing.

Setup

The first step is to install SSHFS.

In Ubuntu:

$ sudo apt-get install sshfs

or in Gentoo:

$ sudo emerge -av sshfs-fuse

Create the mount point on your local machine. This is where you are going to access the remote filesystem.

$ sudo mkdir /mnt/share

Your user must have permission to access this mountpoint.

$ sudo chown ryan /mnt/share

Start Sharing

Now use the sshfs command to mount the remote filesystem. If the username is different on the server you are connecting, use the “username@host:” format, otherwise you can simply specify “host:”.

$ sshfs ryan@fileserver:/remote/share /mnt/share

If you are not using keys with SSH you will be prompted for a password.

ryan@fileserver's password:

Once you are finished you can easily unmount the filesystem.

as regular user:

$ fusermount -u /mnt/share

or as root:

$ sudo umount /mnt/share

Configuration

You can add an entry for this share to /etc/fstab to make the mounting process more seamless.

sshfs#ryan@fileserver:/remote/share /mnt/share fuse user,noauto 0 0

user – allow any user to mount this share.
noauto – stop the shared directory from being automatically mounted at startup.

If you want it automatically mounted, ensure that your SSH configuration uses keys and not passwords so it doesn’t ask for a password at startup. Once keys are in use you can safely remove the noauto option.

With fstab updated you can now mount the share as a normal user with this simple mount command. Again, if ssh is configured to use passwords you will still be prompted for one.

$ mount /mnt/share

No related posts.

At various times it is necessary to restrict the users which can access a certain host. If your network relies on SSH it is as simple as changing an option in the sshd_config configuration file. You will of course need root access to make the necessary changes to this file and eventually reset the SSH daemon.

This configuration file is usually located here.
/etc/ssh/sshd_config

Open the file as root in order to make changes.

$ sudo vim /etc/ssh/sshd_config

You need to set the AllowUsers keyword followed by the users you want to have access to the machine.

AllowUsers	ryan joe

If you want to do something more complex here is the output from the man page:

AllowUsers
This keyword can be followed by a list of user name patterns, separated by spaces. If specified, login is allowed only for user names that match one of the patterns. ‘*’ and ‘?’ can be used as wildcards in the patterns. Only user names are valid; a numerical user ID is not recognized. By default, login is allowed for all users. If the pattern takes the form USER@HOST then USER and HOST are separately checked, restricting logins to particular users from particular hosts.

Another helpful to set the PermitRootLogin to ‘no’ so that the root account is inaccessible.

PermitRootLogin  no

When these settings have been changed go ahead and restart the SSH daemon.

$ sudo /etc/init.d/sshd restart

There are of course ways around this if other users have access to sudo or the root account. But for the most part it is a good way to restrict user access.

No related posts.

The ability to remotely SSH into a machine running an Ubuntu LiveCD can come in handy in many situations. The LiveCD supports a large variety of hardware and can be used to troubleshoot system problems on a machine where you have limited or no access. A user with limited skills can easily setup remote access and allow a trusted friend to troubleshoot the system from another location.

The first thing to start the process is to open a terminal. Follow these menus:

Applications -> Accessories -> Terminal

In the terminal install the ssh server on your LiveCD system.

$ sudo apt-get install openssh-server

The server is started automatically after installing.

To login remotely, you’ll need to set the password for the default ubuntu user.

$ sudo passwd ubuntu
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully

You should now be able to login to the system running the LiveCD. But first you need to find the IP address of the machine so you can connect to it.

The ifconfig command will list your network interfaces and along with it your IP address.

$ ifconfig

eth0      ...
          inet addr:192.168.1.1  Bcast:192.168.2.255  Mask:255.255.255.0
          ...

The inet addr entry is your IP address which you need to log into the LiveCD system. As you an see above the IP address begins with “192.168” which indicates that the IP address is only valid on the local network. It was an address assigned to the machine by the router. This is fine if you plan on logging in from another machine on this local network.

If you need to access the machine from outside your local network you have a couple of options. The first is to remove any router between you and the Internet. This should give you a valid IP address which is accessible from outside your local network. You may also be able to access your router’s administration panel and tell it to pass SSH traffic to the IP address of the LiveCD system. You will then use the router’s IP address instead for the next step.

If your IP address already begins with something other than “192.168” then you are safe as well. You should be able to access the LiveCD system from any location, local or not.

Using the IP address from the previous step you can now log into the LiveCD system as the ubuntu user. Use the password you created earler.

$ ssh ubuntu@<IP Address>

Related posts

1. Installing Ubuntu 9.10 on the Dell Zino HD The Dell Inspiron Zino HD is the perfect machine if...

SSH allows secure (encrypted and authenticated) connections between two hosts. These connections include terminal sessions, file transfers, TCP port forwarding, as well as X window forwarding which I will be covering here. X forwarding is a form of tunneling that allows you to run a GUI application on a remote machine but let you view and interact with it on your local machine.

To try this out you will need both X and SSH installed on your local and remote machines. Make sure that you are able to log into the the remote machine over SSH before you continue.

Simple SSH command, ensure that this works before continuing. You may have to enter a password for the user before it will allow you access.

$ ssh user@remotehost

The next step is to add the ‘-X‘ option. This will turn on X forwarding and allow you to remotely run X programs. In this case we will run xclock.

$ ssh -X user@remotehost xclock

You should see the xclock window appear on your screen. You can interact with it like any other local application window. Close it when you are done.

If you have a slower connection you can turn on compression by adding the ‘-C‘ option to the command above. This will compress all data communications with the gzip algorithm.

$ ssh -C -X user@remotehost xclock

If you are experiencing any problems turn on verbose output with the ‘-v‘ option. This will give you a lot more output and tell you what is going on underneath.

$ ssh -v -X user@remotehost xclock

If you are still having issues look in the ssh configuration file here/etc/ssh/ssh_config, and make sure that you don’t have X forwarding settings disabled.

No related posts.

scp allows you to securely copy files locally or remotely across a network. It uses SSH for data transfer and uses the same authentication. If you do not have public key authentication enabled you will be prompted for a password.

This basic format for scp is this.

scp [options] [[user@]src_host1:]file1 [[user@]dest_host2:]file2

Assuming the remotehost has a username which matches username on the local host, this command will copy a a local file into the /tmp directory on remotehost. Notice that the colon separates the host from the location.

$ scp file.txt remotehost:/tmp/

You will be presented with the real-time statistics about the file transfer.

$ scp file.txt remotehost:/tmp/

file.txt                                      100%   22KB  21.9KB/s   00:00

This command is similar but the period instructs the file to be placed in the users home directory.

$ scp file.txt remotehost:.

You can specify another user and login using their username. This will copy the file to ryan’s home directory.

$ scp file.txt ryan@remotehost:.

Alternatively you can copy a remote file to your local host. The period in the destination path refers to the current working directory in this case.

$ scp ryan@remotehost:file.txt .

Likewise, you can copy to any other local path you have access, such as the /tmp directory.

$ scp ryan@remotehost:file.txt /tmp/

Copying directories is similar except that the ‘-r’ option is required. This command will copy a directory from the current working directory to the users home directory on remotehost.

$ scp -r mydir/ remotehost:.

You can even copy from one remote host to another.

$ scp remotehost1:file.txt remotehost2:file.txt

Use the -p option to preserve modification times, access times, and modes from the original file.

$ scp -p remotehost1:/tmp/file.txt remotehost2:/tmp/file.txt

No related posts.