ssh file access variations

ssh can play a role in a variety of file access mechanisms. You might classify them into two categories:

1) commands that natively incorporate ssh as their network transport vehicle (you don't explicitly invoke the command "ssh"), e.g.
  scp - secure copy (like cp)
  sftp - secure ftp (like ftp)
  sshfs - ssh file system (like nfs network file sharing)
  rsync - remote filesystem syncronizer

2) constructed pipes which include the command "ssh" explicitly
  piping through ssh/sshd as a bridge between a filedump copy of cat and a file-redirect copy of cat (constructed equivalent of scp)
  piping through ssh/sshd between any command on client to a file-redirect "cat > file" on server
  piping through ssh/sshd as a bridge between 2 copies of tar for secured backup

You will exercise a few of these, interacting with a target server identified by your instructor. You will move files to the server and/or utilize files that reside there.

It is assumed that you have previously performed ssh key setup on the server, placing a key belonging to some user on your computer into the authorized_keys2 file of some other user on the other computer. You can therefore log in without a password. You can also do other things unattended or with no password request interruption. Check to make sure that mechanism is in place by making sure you can log in:

ssh studentXX@<server>

Once you're in, get back out:

exit

Copying a file securely with a) scp and b) constructed pipe

Copying "securely" means the datastream carrying the file's content is encrypted. If ssh is used, as in both techniques here, the datastream is secured implicitly. That's what ssh does. First, create two files on your computer.

echo "one for the money" > one.txt
echo "two for the show" > two.txt

(... three to get ready
      now go, cat, go...)

Move the first one using scp:

scp  one.txt  studentXX@<server>:/home/studentXX

The file is copied over into the home directory of studentXX on the other machine. 

cat  two.txt  |  ssh  studentXX@<server>  "cat  >  duo.txt"

The content of two.txt is received by ssh which transports it securely to sshd on the other machine. Becuase a to-be-executed remote command is supplied on the ssh command line, sshd runs "cat  >  duo.txt" on the remote machine, handing it the incoming data (after decrypting). The content of two.txt lands in duo.txt on the far side, effectively copying two.txt. Check to make sure by dumping the remote duo.txt's content to your screen and confirming it's the same content you placed in two.txt in the first place:

ssh  studentXX@<server>  "cat duo.txt"

Copying interactively with sftp

sftp is very similar to command-line ftp. It places you in an interactive environment with a prompt. You have a limited command set similar to that of ftp, for similiar purposes.

sftp  studentXX@<server>

At the sftp prompt, examine the available commands:

help

Then observe your remote current directory, note what files it contains, delete one of the, and bring another to your local computer:

pwd
ls
rm two.txt
get duo.txt
exit

You would use nearly these same commands in regular ftp (ftp wants "del" rather than "rm"). But sftp is secure while ftp, notoriously, is not. Check to make sure by dumping the local duo.txt's content to your screen and confirming it's the same content that you placed in two.txt, send across to the other side, then retrieved back to this side.

cat duo.txt

Note that neither remote nor local copies of transfered files, as residing on disk before or after the transfer, are encrypted. Only the datastream, while it flows in transit, is in encrypted form.

Mounting a remote filesystem securely with sshfs

Before doing this make sure you have sshfs on your system. If not you can install it:

yum  install  fuse-sshfs

Then:

cd
mkdir  mymountpoint
ls  mymountpoint
sshfs  studentXX@<server>:/home/studentXX  mymountpoint
ls  mymountpoint
umount  mymountpoint
ls  mymountpoint

This ties the content of the files of a specified remote directory to a local one. In this case, the local reference "mymountpoint" resolves to a reference to the content of the remote directory /home/studentXX on <server>. You can treat it as if local. Note there is no transfer of files between the two computers' filesystems. You use the files that reside on the server in place. Go ahead, cat them, vi them, rm them, cp them to some local directory. Pretend they're on your computer and ignore the fact they're not. It's transparent.

In the above sequence, you create a directory to be used as a mounpoint and confirm that, as a virgin directory, it's empty. After mounting a remote directory on it, the same command shows it now has content. Then after severing the tie with umount, you again find it empty.