oldwiki.scinet.utoronto.ca - User contributions [en-gb]

Data Management

2013-04-04T19:19:18Z

Kzuberi: put shell command example in <pre> block to fix wiki formatting breakage

=='''Storage Space'''==
SciNet's storage system is based on IBM's [http://en.wikipedia.org/wiki/IBM_General_Parallel_File_System GPFS] (General Parallel File System). There are two main systems for user data: <tt>/home</tt>, a small, backed-up space where user home directories are located, and <tt>/scratch</tt>, a large system for input or output data for jobs; data on <tt>/scratch</tt> is not only not backed up (a third storage system, /project, exist only for groups with LRAC/NRAC allocations). Data placed on scratch will be deleted if it has not been accessed in 3 months. SciNet does not provide long-term storage for large data sets.

===Overview of the different file systems===

{|border="1" cellpadding="10" cellspacing="0"
|-
! {{Hl2}} | file system
! {{Hl2}} | purpose
! {{Hl2}} | quota
! {{Hl2}} | block size
! {{Hl2}} | backed up
! {{Hl2}} | purged
! {{Hl2}} | access
|-
| /home
| development
| 10 GB
| 256 KB
| yes
| never
| read-only on compute nodes (r/w on login, devel and datamover1)
|-
| /scratch
| computation
| 20 TB
| 4 MB
| no
| files > 3 month
| read/write on all nodes
|-
| /project
| computation
| by allocation
| 256 KB
| yes
| never
| read/write on all nodes
|}
project is included in scratch

===Home Disk Space===

Every SciNet user gets a 10GB directory on <tt>/home</tt> in a directory <tt>/home/G/GROUP/USER</tt>, which is regularly backed-up. Home is visible from <tt>login.scinet</tt> nodes, and from the development nodes on [[GPC_Quickstart | GPC]] and the [[TCS_Quickstart | TCS]]. However, on the compute nodes of the GPC clusters -- as when jobs are running -- <tt>/home</tt> is mounted '''''read-only'''''; thus GPC jobs can read files in /home but cannot write to files there. <tt>/home</tt> is a good place to put code, input files for runs, and anything else that needs to be kept to reproduce runs. On the other hand, <tt>/home</tt> is not a good place to put many small files, since
the block size for the file system is 256KB, so you would quickly run out of disk quota and you will make the backup system very slow.

If your application absolutely insists on writing material to your home account and you can't find a way to instruct it to write somewhere else, an alternative is to create a link pointing from your account under /home to a location under /scratch.

===Scratch Disk Space===

Every SciNet user also gets a directory in <tt>/scratch</tt> called <tt>/scratch/G/GROUP/USER</tt>. Scratch is visible from the <tt>login.scinet</tt> nodes, the development nodes on [[GPC_Quickstart | GPC]] and the [[TCS_Quickstart | TCS]], and on the compute nodes of the clusters, mounted as read-write. Thus jobs would normally write their output somewhere in <tt>/scratch</tt>. There are '''NO''' backups of anything on <tt>/scratch</tt>.

There is a large amount of space available on <tt>/scratch</tt> but it is purged routinely so that all users running jobs and generating large outputs will have room to store their data temporarily. Computational results which you want to keep longer than this must be copied (using <tt>scp</tt>) off of SciNet entirely and to your local system. SciNet does not routinely provide long-term storage for large data sets.

===Scratch Disk Purging Policy===

In order to ensure that there is always significant space available for running jobs '''we automatically delete files in /scratch that have not been accessed or modified for more than 3 months by the actual deletion day on the 15th of each month'''. Note that we recently changed the cut out reference to the ''MostRecentOf(atime,mtime)''. This policy is subject to revision depending on its effectiveness. More details about the purging process and how users can check if their files will be deleted follows. If you have files scheduled for deletion you should move them to a more permanent locations such as your departmental server or your /project space (for PIs who have either been allocated disk space by the LRAC or have bought diskspace).

On the '''first''' of each month, a list of files scheduled for purging is produced, and an email notification is sent to each user on that list. Furthermore, at/or about the '''12th''' of each month a 2nd scan produces a more current assessment and another email notification is sent. This way users can double check that they have indeed taken care of all the files they needed to relocate before the purging deadline. Those files will be automatically deleted on the '''15th''' of the same month unless they have been accessed or relocated in the interim. If you have files scheduled for deletion then they will be listed in a file in /scratch/t/todelete/current, which has your userid and groupid in the filename. For example, if user xxyz wants to check if they have files scheduled for deletion they can issue the following command on a system which mounts /scratch (e.g. a scinet login node): '''ls -1 /scratch/t/todelete/current |grep xxyz'''. In the example below, the name of this file indicates that user xxyz is part of group abc, has 9,560 files scheduled for deletion and they take up 1.0TB of space:

<pre>
[xxyz@scinet04 ~]$ ls -1 /scratch/t/todelete/current |grep xxyz
-rw-r----- 1 xxyz root 1733059 Jan 12 11:46 10001___xxyz_______abc_________1.00T_____9560files
</pre>

The file itself contains a list of all files scheduled for deletion (in the last column) and can be viewed with standard commands like more/less/cat - e.g. '''more /scratch/t/todelete/current/10001___xxyz_______abc_________1.00T_____9560files'''

Similarly, you can also verify all other users on your group by using the ls command with grep on your group. For example: '''ls -1 /scratch/t/todelete/current |grep abc'''. That will list all other users in the same group that xxyz is part of, and have files to be purged on the 15th. Members of the same group have access to each other's contents.

'''NOTE:''' Preparing these assessments takes several hours. If you change the access/modification time of a file in the interim, that will not be detected until the next cycle. A way for you to get immediate feedback is to use the ''''ls -lu'''' command on the file to verify the atime and ''''ls -la'''' for the mtime. If the file atime/mtime has been updated in the meantime, coming the purging date on the 15th it will no longer be deleted.

===Project Disk Space===

Investigators who have been granted allocations through the [http://www.scinet.utoronto.ca/resources/Account_Allocations.htm LRAC/NRAC Application Process] may have been allocated disk space in addition to compute time. For the period of time that the allocation is granted, they will have disk space on the <tt>/project</tt> disk system. Space on project is a subset of scratch, but is not purged and is backed up. All members of the investigators groups will have access to this disk system, which will be mounted read/write everywhere.

===How much Disk Space Do I have left?===

The <tt>'''/scinet/gpc/bin6/diskUsage'''</tt> command, available on the login nodes, datamovers and the GPC devel nodes, provides information in a number of ways on the home, scratch, and project file systems. For instance, how much disk space is being used by yourself and your group (with the -a option), or how much your usage has changed over a certain period ("delta information") or you may generate plots of your usage over time. Please see the usage help below for more details.
<pre>
Usage: diskUsage [-h|-?| [-a] [-u <user>] [-de|-plot]
-h|-?: help
-a: list usages of all members on the group
-u <user>: as another user on your group
-de: include delta information
-plot: create plots of disk usages
</pre>
Notes:
* information on usage and quota is only updated hourly!
* contents of project count against space and #files limits on scratch

===Performance===

[http://en.wikipedia.org/wiki/IBM_General_Parallel_File_System GPFS] is a high-performance filesystem which provides rapid reads and writes to large datasets in parallel from many nodes. As a consequence of this design, however, '''the file system performs quite ''poorly'' at accessing data sets which consist of many, small files.''' For instance, you will find that reading data in from one 4MB file is enormously faster than from 100 40KB files. Such small files are also quite wasteful of space, as the blocksize for the filesystem is 4MB. This is something you should keep in mind when planning your input/output strategy for runs on SciNet.

For instance, if you run multi-process jobs, having each process write to a file of its own is not an scalable I/O solution. A directory gets locked by the first process accessing it, so all other processes have to wait for it. Not only has the code just become considerably less parallel, chances are the file system will have a time-out while waiting for your other processes, leading your program to crash mysteriously.
Consider using MPI-IO (part of the MPI-2 standard), which allows files to be opened simultaneously
by different processes, or using a dedicated process for I/O to which all other processes send their
data, and which subsequently writes this data to a single file.

===Local Disk===

The compute nodes on the GPC '''do not contain hard drives''' so there is no local disk available to use during your computation. You can however use part of a compute nodes RAM like a local disk ('ramdisk') but this will reduce how much memory is available for your
program. This can be accessed using <tt>/dev/shm/</tt> and is currently set to 8GB. Anything written
to this location that you want to keep must be copied back to the <tt>/scratch</tt> filesystem as <tt>/dev/shm</tt> is wiped after each job and since it is in memory will not survive through a reboot of the node. More on ramdisk usage can be found [[User_Ramdisk | here]].

Note that the absense of hard drives also means that the nodes cannot swap memory, so be sure that your computation fits within memory.

=='''Data Transfer'''==
{{:Data_Transfer}}

=='''File/Ownership Management (ACL)'''==
* By default, at SciNet, users within the same group have read permission to each other's files (not write)
* You may use access control list ('''ACL''') to allow your supervisor (or another user within your group) to manage files for you (i.e., create, move, rename, delete), while still retaining your access and permission as the original owner of the files/directories.
* '''NOTE''': We highly recommend that you never give write permission to other users on the top level of your home directory (/home/G/GROUP/[owner]), since that would seriously compromise your privacy, in addition to disable ssh key authentication, among other things. If necessary, make specific sub-directories under your home directory so that other users can manipulate/access files from those.
* If you need to set up permissions across groups [mailto:support@scinet.utoronto.ca contact us] (and the other group's supervisor!).



===Using mmputacl/mmgetacl===
* You may use gpfs' native '''mmputacl''' and '''mmgetacl''' commands. The advantages are that you can set "control" permission and that [http://publib.boulder.ibm.com/infocenter/clresctr/vxrx/index.jsp?topic=%2Fcom.ibm.cluster.gpfs.doc%2Fgpfs31%2Fbl1adm1160.html POSIX or NFS v4 style ACL] are supported. You will need first to create a /tmp/supervisor.acl file with the following contents:
<pre>
user::rwxc
group::----
other::----
mask::rwxc
user:[owner]:rwxc
user:[supervisor]:rwxc
</pre>

Then issue the following 2 commands:
<pre>
1) $ mmputacl -i /tmp/supervisor.acl /project/g/group/[owner]
2) $ mmputacl -d -i /tmp/supervisor.acl /project/g/group/[owner]
(every *new* file/directory inside [owner] will inherit [supervisor] ownership by default as well as
[owner] ownership, ie, ownership of both by default, for files/directories created by [supervisor])

$ mmgetacl /project/g/group/[owner]
(to determine the current ACL attributes)

$ mmdelacl -d /project/g/group/[owner]
(to remove any previously set ACL)

$ mmeditacl /project/g/group/[owner]
(to create or change a GPFS access control list)
(for this command to work set the EDITOR environment variable: export EDITOR=/usr/bin/vi)
</pre>

NOTES:
* There is no option to recursively add or remove ACL attributes using a gpfs built-in command to existing files. You'll need to use the -i option as above for each file or directory individually. [[Data_Management#bash_script_that_you_may_adapt_to_recursively_add_or_remove_ACL_attributes_using_gpfs_built-in_commands | Here is a sample bash script you may use for that purpose]]

* mmputacl/setfacl will not overwrite the original linux group permissions for a directory when copied to another directory already with ACLs, hence the "#effective:r-x" note you may see from time to time with mmgetacf/getfacl. If you want to give rwx permissions to everyone in your group you should simply rely on the plain unix 'chmod g+rwx' command. You may do that before or after copying the original material to another folder with the ACLs.

For more information on using [http://publib.boulder.ibm.com/infocenter/clresctr/vxrx/index.jsp?topic=%2Fcom.ibm.cluster.gpfs.doc%2Fgpfs31%2Fbl1adm11120.html <tt>mmputacl</tt>] or [http://publib.boulder.ibm.com/infocenter/clresctr/vxrx/index.jsp?topic=%2Fcom.ibm.cluster.gpfs.doc%2Fgpfs31%2Fbl1adm11120.html <tt>mmgetaclacl</tt>] see their man pages.

===Appendix (ACL)===
====bash script that you may adapt to recursively add or remove ACL attributes using gpfs built-in commands====
Courtesy of Agata Disks (http://csngwinfo.in2p3.fr/mediawiki/index.php/GPFS_ACL)

<pre>
#!/bin/bash
# USAGE
# - on one directory: ./set_acl.sh dir_name
# - on more directories: ./set_acl.sh 'dir_nam*'
#

# Path of the file that contains the ACL
ACL_FILE_PATH=/agatadisks/data/acl_file.acl

# Directories onto the ACLs have to be set
dirs=$1

# Recursive function that sets ACL to files and directories
set_acl () {
curr_dir=$1
for args in $curr_dir/*
do
if [ -f $args ]; then
echo "ACL set on file $args"
mmputacl -i $ACL_FILE_PATH $args
if [ $? -ne 0 ]; then
echo "ERROR: ACL not set on $args"
exit -1
fi
fi
if [ -d $args ]; then
# Set Default ACL in directory
mmputacl -i $ACL_FILE_PATH $args -d
if [ $? -ne 0 ]; then
echo "ERROR: Default ACL not set on $args"
exit -1
fi
echo "Default ACL set on directory $args"
# Set ACL in directory
mmputacl -i $ACL_FILE_PATH $args
if [ $? -ne 0 ]; then
echo "ERROR: ACL not set on $args"
exit -1
fi
echo "ACL set on directory $args"
set_acl $args
fi
done
}
for dir in $dirs
do
if [ ! -d $dir ]; then
echo "ERROR: $dir is not a directory"
exit -1
fi
set_acl $dir
done
exit 0

</pre>

==[[HPSS|'''High Performance Storage System (HPSS)''']]==

==More questions on data management?==

Check out the [[FAQ#Data_on_SciNet_disks|FAQ]].

Ssh keys

2011-12-05T18:57:21Z

Kzuberi: trivial typo fix

[[Ssh | SSH]] has an alternative to passwords to authenticate your login; you can generate a key file on a trusted machine and tell a remote machine to trust logins from a machine that presents that key. This can be both convenient and secure, and may be necessary for some tasks (such as connecting directly to compute nodes to use [[Using_Paraview | some visualization packages]]). Here we describe how to setup keys for logging into SciNet.

==SSH Keys and SciNet==

[[Ssh | SSH]] is a secure protocol for logging into or copying data to/from remote machines. In addition to using passwords to [http://en.wikipedia.org/wiki/Authentication authenticate] users, one can use cryptographically secure keys to guarantee that a login request is coming from a trusted account on a remote machine, and automatically allow such requests. Done properly, this is as secure as requiring a password, but can be more convenient, and is necessary for some operations.

On this page, we will assume you are using Linux, Mac OS X, or a similar environment such as [http://www.cygwin.com/ Cygwin] under Windows. If not, the steps will be the same, but how they are done (for instance, generating keys) may differ; look up the documentation for your ssh package for details.

==Using SSH keys==
===How SSH keys work===

SSH relies on [http://en.wikipedia.org/wiki/Public-key_cryptography public key cryptography] for its encryption. These cryptosystems have a private key, which must be kept secret, and a public key, which may be disseminated freely. In these systems, anyone may use the public key to encode a message; but only the owner of the private key can decode the message. This can also be used to verify identities; if someone is claiming to be Alice, the owner of some private key, Bob can send Alice a message encoded with Alice's well-known public key. If the person claiming to be Alice can then tell Bob what the message really was, then that person at the very least has access to Alice's private key.

To use keys for authentication, we:
* Generate a key pair (Private and Public)
* Copy the public keys to remote sites we wish to be able to login to, and mark it as an authorized key for that system
* Ensure permissions are set properly
* Test.

===Generating an SSH key pair===

{|border="1"
|
Note: This describes creating ssh key pairs on '''your''' machine, not on SciNet. On SciNet, you already have key pairs generated, sitting in <tt>${HOME}/.ssh/</tt>, and modifying them is likely to cause problems.
|}

The first stage is to create an SSH key pair. On most systems, this is done using the command

ssh-keygen

This will prompt you for two pieces of information: where to save the key, and a passphrase for the key. The passphrase is like a password, but rather than letting you in to some particular account, it allows you to use the key you've generated to log into other systems.

There are a series of possible options to <tt>ssh-keygen</tt> which allow increasingly cryptographically secure keys (by increasing the number of bits used in the key), or by choosing different encryption systems. The defaults are fine, and we won't discuss other options here.

The default location to save the private key is in <tt>${HOME}/.ssh/id_rsa</tt> (for an RSA key); unless you have some specific reason for placing it elsewhere, use this option. The public key will be <tt>id_rsa.pub</tt> in the same directory.

Your passphrase can be any string, and of any length. It is best not to make it the same as any of your passwords.

A sample session of generating a key would go like this:

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (${HOME}/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in ${HOME}/.ssh/id_rsa.
Your public key has been saved in ${HOME}/.ssh/id_rsa.
The key fingerprint is:
79:8e:36:6a:78:7d:cf:80:94:90:92:0e:74:0b:f1:b7 USERNAME@YOURMACHINE

====Don't Use Passphraseless Keys!====

If you do not specify a passphrase, you will have a completely "exposed" private key. '''This is a terrible idea.''' If you then use this key for anything it means that anyone who sits down at your desk, or anyone who borrows or steals your laptop, can login to anywhere you use that key (good guesses could come from just looking at your history) without needing any password, and could do anything they wanted with your account or data. Don't use passphraseless keys.

We should note that we do, in fact, have one necessary and reasonable exception here -- the keys used within SciNet itself. The SciNet key used for within-scinet operations (you already have one in your account in <tt>~/.ssh/id_rsa</tt>) is passphraseless, for two good reasons. One is that, once you are on one SciNet machine (like the login node), you already have read/write access to all your data; all the nodes mount the same file systems. So there is little to be gained in protecting the SciNet nodes from each other. The second is practical; ssh is used to login to compute nodes to start your compute jobs. You obviously can't be asked to type in a passphrase every time one of your jobs starts; you may not be at your computer at that moment. So passphraseless keys are ok ''within'' a controlled environment; but don't use them for remote access.

===Copying the Public Key to SciNet (and elsewhere)===

Now that you have this SSH "identity", you use the public (''not'' the private) key for access to remote machines. The public key must be put as one line in the file <tt>/home/USERNAME/.ssh/authorized_keys</tt>. Do not delete the lines already there, or you may end up with strange problems using SciNet machines.

You can copy your new public key to the SciNet systems
<pre>
scp /home/LOCAL_USERNAME/.ssh/id_rsa.pub SCINET_USERNAME@login.scinet.utoronto.ca:newkey
</pre>
Then login to SciNet and copy&paste the contents from <tt>~/newkey</tt> into <tt>~/.ssh/authorized_keys</tt>.
<pre>
cat ~/newkey >> ~/.ssh/authorized_keys
</pre>

===<tt>.ssh</tt> Permissions===

Note that <tt>SSH</tt> is very fussy about file permissions; your <tt>~/.ssh</tt> directory must only be accessible by you, and your various key files must not be writable (or in some cases, readable) by anyone else. Sometimes users accidentally reset file permissions while editing these files, and problems happen. If you look at the <tt>~/.ssh</tt> directory itself, it should not be readable at all by anyone else:

ls -ld ~/.ssh
drwx------ 2 USERNAME GROUPNAME 7 Aug 9 15:43 /home/USERNAME/.ssh

and <tt>authorized_keys</tt> must not be writable:

$ ls -l ~/.ssh/authorized_keys
-rw-r--r-- 1 USERNAME GROUPNAME 1213 May 29 2009 /home/USERNAME/.ssh/authorized_keys

===Testing Your Key===

Now you should be able to login to the remote system (say, SciNet):

$ ssh USERNAME@login.scinet.utoronto.ca
Enter passphrase for key '/home/USERNAME/.ssh/id_rsa':
Last login: Tue Aug 17 11:24:48 2010 from HOMEMACHINE

===================================================

This SciNet login node is to be used only as a
gateway to the GPC and TCS.

[...]
scinet04-$

If this doesn't work, you should be able to login using your password, and investigate the problem. For example, if during a login session you get an message similar to the one below, just follow the instruction and delete the offending key on line 3 (you can use vi to jump to that line with ESC plus : plus 3). That only means that you may have logged in from your home computer to SciNet in the past, and that key is obsolete.
<pre>
$ ssh USERNAME@login.scinet.utoronto.ca

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@**@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@**@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle
attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
53:f9:60:71:a8:0b:5d:74:83:52:**fe:ea:1a:9e:cc:d3.
Please contact your system administrator.
Add correct host key in /home/<user>/.ssh/known_hosts to get rid of
this message.
Offending key in /home/<user>/.ssh/known_hosts:3
RSA host key for login.scinet.utoronto.ca
<http://login.scinet.utoronto.ca <http://login.scinet.utoronto.ca>> has
changed and you have requested
</pre>

* If you get the message below you may need to logout of your gnome session and log back in since the ssh-agent needs to be
restarted with the new passphrase ssh key.
<pre>
$ ssh USERNAME@login.scinet.utoronto.ca

Agent admitted failure to sign using the key.
</pre>

===(Optional) Using <tt>ssh-agent</tt> to Remember Your Passphrase===

But now you've just replaced having to type a password for login with having to type a passphrase for your key; what have you gained?

It turns out that there's an automated way to manage ssh "identities", using the <tt>ssh-agent</tt> command, which should automatically be running on newer Linux or Mac OS X machines. You can add keys to this agent for the duration of your login using the <tt>ssh-add</tt> command:

$ ssh-add
Enter passphrase for /home/USERNAME/.ssh/id_rsa:
Identity added: /home/USERNAME/.ssh/id_rsa (/home/USERNAME/.ssh/id_rsa)

and then logins will not require the passphrase, as <tt>ssh-agent</tt> will provide access to the key.

When you log out of your home computer, the ssh agent will close, and next time you log in, you will have to <tt>ssh-add</tt> your key. You can also set a timeout of (say) an hour by using <tt>ssh-add -t 3600</tt>. This minimizes the number of times you have to type your passphrase, while still maintaining some degree of key security.

=== Multiple ssh private keys ===
In quite a few situations its preferred to have ssh keys dedicated to each service, specific role or domain.
<pre>
ssh-keygen -t rsa -f ~/.ssh/id_rsa.SciNet -C "Key for SciNet"
ssh-keygen -t rsa -f ~/.ssh/id_rsa.SHARCNET -C "Key for SHARCNET"
ssh-keygen -t rsa -f ~/.ssh/id_rsa.DCS -C "Key for Dept. Of Computer Science"
ssh-keygen -t rsa -f ~/.ssh/id_rsa.CITA -C "Key for CITA"
</pre>

Use different file names for each key. Lets assume that there are 2 keys, ~/.ssh/id_rsa.SciNet and ~/.ssh/id_rsa.SHARCNET. The simple way of making sure each of the keys works all the time is to now create config file for ssh:
<pre>
touch ~/.ssh/config
chmod 600 ~/.ssh/config
echo "IdentityFile ~/.ssh/id_rsa.SciNet" >> ~/.ssh/config
echo "IdentityFile ~/.ssh/id_rsa.SHARCNET" >> ~/.ssh/config
</pre>

This would make sure that both keys are always used whenever ssh makes a connection. However, ssh config lets you get down to a much finer level of control on keys and other per-connection setups. The recommendation is to use a key selection based on the Hostname. For example, a ~/.ssh/config that looks like this :

<pre>
Host SciNet
Hostname login.scinet.utoronto.ca
IdentityFile ~/.ssh/id_dsa.SciNet
User pinto

Host SHARCNET
Hostname sharcnet.ca
IdentityFile ~/.ssh/id_rsa.SHARCNET
User jchong
Port 44787
</pre>

And just login with the shortcut:
<pre>
$ ssh SciNet
</pre>

=== SSH tunnel ===
A more obscure use of ssh is to generate a communication tunnel. As an example, assume you want to access a website running on a remotehost using your localhost, but there is a firewall between the 2 systems blocking every port, except incoming ssh.

The basic syntax of the ssh command for such a purpose is:
<pre>
ssh -f -N -L localport:localhost:remoteport user@remotehost
# -f puts ssh in background
# -N makes it not execute a remote command
</pre>

If the remote website broadcasts on the default port 80, you could do the following:
<pre>
ssh -L 8080:localhost:remotehost:80 tunneluser@remotehost
</pre>
... and point your local browser to http://localhost:8080

If you don't want to remember the above sequence of flags all the time, you can add an entry to your ~/.ssh/config:
<pre>
Host tunnel
HostName remotehost
IdentityFile ~/.ssh/id_rsa.tunnel
LocalForward 8080 127.0.0.1:80
User tunneluser
</pre>

To open the tunnel just issue the command:
<pre>
$ ssh -f -N tunnel
</pre>