ssh.cs.brown.edussh.cs.brown.edu is a machine that automatically forwards ssh connections to other machines. There are three modes of operation.
- Default operation:
By default, ssh.cs.brown.edu will automatically forward you to a cslab machine, randomly chosen from a list of the least active machines. This list is updated every 3 minutes, so if you make a lot of calls to ssh.cs.brown.edu in a short time period, there is the possibility that you will be forwarded to the same machine more than once. Absolutely no configuration must be done for this mode; just ssh ssh.cs.brown.edu.
- Preferred operation:
In the default operation, ssh.cs.brown.edu acts like a mini-load balancer. In the preferred operation, ssh.cs.brown.edu will act simply as an ssh gateway. You may use the preferred operation by installing a .sshhost file in your home directory. This .sshhost file is a list of machines from which you would like ssh.cs.brown.edu to choose to forward you. The file should be a list of machine names, each name on its own line. ssh.cs.brown.edu will choose from the list in order from top to bottom. Note: The names given must be the machines' full names (ie, cslab8d, not simply 8d). This method does not check loads. This mode is mostly useful for if you have a preferred set of machines on which to work. Instead of having to figure out which ones may be up, ssh.cs.brown.edu figures that all out for you; all you do, after setting up your .sshhost file, is ssh to ssh.cs.brown.edu, or 'ssh ssh' for short. If you'd like ssh.cs.brown.edu to fall back to the default mode if none of your hosts are available, put an entry "@sunlab" at the end of the list.
- Explicit operation:
ssh.cs.brown.edu can take an explicit machine to forward you to on the command line. To do so, you must have the first argument be in the form "host=<hostname>". For instance,
ssh -t ssh.cs.brown.edu host=cslab8dNotice the use of -t. It is necessary to use -t because, having given ssh a "command" to run, it will not automatically allocate a tty. -t will do the allocation. This mode is the most experimental and may not be available to users of ssh clients other than OpenSSH. Explicit operation will not automatically fall back to another host if none of your requested hosts are available.
In preferred or explicit operation, you can use a host class in place of a hostname; host classes are expanded into all their constituent hosts, in order of most idle host. To specify a host class, enter the name of the class prefixed with "@"; available classes include: @sunlab, @ilab, @ta_office.
If you pass the -Y option to ssh (e.g. ssh -Y ssh.cs.brown.edu), ssh.cs.brown.edu will tunnel X11 through the ssh connections, so you should not have to deal with your $DISPLAY variable if you are going to use X programs remotely.
You can use ssh.cs.brown.edu to run commands on idle machines like so:
ssh ssh your_command_goes_hereThis will effectively send out your process to a relatively idle cslab machine (or, if you have a .sshhost file or explicitly give a machine name before the command, one of your choosing). The major ramification of this addition is that scping to the department may be done through ssh.cs.brown.edu. To move a file to the department, scp to ssh.cs.brown.edu just like you would any other machine. If you need to move something to a specific machine, list that machine in your .sshhost file.
Lastly, if you would like ssh.cs.brown.edu to print some brief information about what host you are being forwarded to, simply create a file in your home directory named .sshhost_verbose:
touch ~/.sshhost_verboseAlternatively, you can pass a "verbose" option to ssh:
ssh -t ssh.cs.brown.edu verboseIf you're also using a host= option, they can go in either order - but must be part of the same string:
ssh -t ssh.cs.brown.edu "verbose host=@ilab"The .sshhost_verbose option is ignored in non-interactive sessions, such as when running a command without the -t option or when using sftp; the "verbose" parameter is never ignored.