Using hardlinks over network drives

Hooo boy. Where to start...

You probably want switches in each of the distant buildings, you don't want to have to run a new line from the central building every time you expand a different building.

Then, you need to work with facilities and/or contractors to get cables strung between buildings. There's probably existing buried tunnels/pipes with other wires, I hope? At least simply for the phone system, electrical, etc? You should run the cables through there.

Then you connect the uplinks of all the remote switches to you central server room.

That's the abstract. You'll need to get into a lot of specifics. These days, GB and 10 GB ethernet is so cheap and commonplace, that might be good for the uplinks, as opposed to some type of fiber (SONET, FDDI - I don't even remember if those are the most common local campus links for between buildings.) But for redundancy, you'd want some sort of loop, so that every building has two paths to go through if one is cut. If done with ethernet, this usually implies implementing spanning-tree protocol.

If this stuff is making your head spin, you need to figure out if you can realistically do a good job of this in the timeframe allotted. You may want to seek the guidance of a local professional if there's no one at the school to give you help; someone might want to donate (or offer at a reduced rate) their design services to the school. A beginner shouldn't be doing all of this, to my mind.

There is a "secret" keyboard shortcut to force an exit :~) From the frozen session, hit these keys in order: Enter~. The tilde (only after a newline) is recognized as an escape sequence by the ssh client, and the period tells the client to terminate it's business without further ado.

The long-hang behavior on communication issues is not a bug, the SSH session is hanging out hoping the other side will come back. If the network breaks, sometimes even days later you can get an SSH session back. Of course you can specifically tell it to give up and die with the sequence above. There are also various things you can do such as setting keep-alive timeouts in your client so that if it doesn't have an active link for a certain amount of time it shuts off on it's own, but the default behavior is to stay as connected as possible!

Edit: Another useful application of this interrupt key is to get the attention of the local ssh client and background it to get back to your local shell for a minute —say to get something from your history— then forground it to keep working remotely. Enter~ Ctrl+Z to send the ssh client to the background job queue of your local shell, then fg as normal to get it back.

Edit: When dealing with nested SSH sessions, you can add multiple tilde characters to only break out of one of the SSH sessions in the chain, but retain the others. For example, if you're nested in 3 levels, (i.e. you ssh from local->Machine1->Machine2->Machine3), Enter~. will get you back to your local session, Enter~~. will leave you in Machine1, and Enter~~~. will leave you in Machine2. This works for other escape sequences as well, such as moving the ssh session to background temporarily. The above works for any level of nesting, by just adding more tilde's.

Finally, you can use Enter~? to print a help menu of available escape commands.

TL;DR - the supported escape commands are Supported escape sequences:

 ~.   - terminate connection (and any multiplexed sessions)
 ~B   - send a BREAK to the remote system
 ~C   - open a command line
 ~R   - request rekey
 ~V/v - decrease/increase verbosity (LogLevel)
 ~^Z  - suspend ssh
 ~#   - list forwarded connections
 ~&   - background ssh (when waiting for connections to terminate)
 ~?   - this message
 ~~   - send the escape character by typing it twice
(Note that escapes are only recognized immediately after newline.)