================================================ How to get Access to the Linux Lab from Wherever ================================================ -IAN! idallen@ncf.ca The Algonquin Linux Lab in room WT-127 is currently on a private network visible only to machines "inside" the College. "Inside" includes most of the machines on campus, machines connected via the College dial-up service, and machines connected via the Virtual Private Network (VPN) software. The Cisco/Microsoft VPN software is supported by ITS only under Windows, not under Linux, though it is available [unsupported] for a particular version of RedHat Linux and may or may not work with other versions of Linux. For Windows installation, see http://www.algonquincollege.com/its/support/vpn/ The private IP addresses of the 25 machines in the lab are these: 10.50.15.1xx where xx ranges from 01 to 25, e.g. 10.50.15.101 to 10.50.15.125 These are the IP addresses you must use to connect to the Linux Lab. The College does not currently have names assigned to these addresses. The above IP addresses are private and are not visible from the public Internet. You must be in the right place on the internal College network (possibly connected via the VPN) to use the above addresses. See the "Lab Access" heading, below, for a list of places that are allowed to connect to these private addresses. --------------------- Disconnection Warning --------------------- You may be connected to one of the Linux Lab machines at the same time as someone else, and that includes someone sitting in front of the machine in the Linux Lab itself. If the person in the Linux Lab decides to push the RESET button or otherwise reboot the machine, you will be disconnected without notice and whatever you were editing at the time may be lost. The VI/VIM editor may save all or part of a file you are editing so that you can recover it when you reconnect. Use the "-r" option to recover: $ vim -r filename The recovery may or may not work, depending on how the machine was shut down and what you were doing when you edited the file. On September 27 I asked ITS to set up a dedicated machine for use by people connecting remotely, one that cannot be rebooted, to avoid this problem. I have had no response yet. --------------------------------- Connecting from Microsoft Windows --------------------------------- From "inside" the firewall (on campus, or via the VPN) you can use the free PuTTY application to connect from Microsoft Windows machines. PuTTY can connect in "telnet" mode (port 23 - not recommended) or in "ssh" mode (port 22 - recommended). Use "ssh" mode. You can also use the built-in Windows "telnet" application; but, your login password and session will be unencrypted. The Windows telnet client also isn't very good at keeping your screen updated (especially the one in Windows 95/98). Select START -> RUN and then enter "telnet" followed by an argument that is a machine name or IP address. For the Linux Lab, machine 01, you would enter: telnet 10.50.15.101 # WARNING: TELNET IS INSECURE You can also type this same thing from a DOS prompt. But use the ssh mode of PuTTY instead. PuTTY also has secure "scp" and "sftp" applications available for file transfer between Windows and Unix machines. FTP is not secure. --------------------------------------------- Connecting from a Unix/Linux/OSX shell prompt --------------------------------------------- From a Unix shell prompt, you can use the "ssh" command with your userid and an argument that is the name or IP address of the machine to which you wish to connect: $ ssh -l xyzz0001 10.50.15.101 xyzz0001@10.50.15.101's password: The argument following "-l" is your Linux Lab userid. The IP address is the address of one of the Linux Lab client machines. You can also use the "telnet" command; but, it is less secure since it doesn't hide your password over the network: $ telnet 10.50.15.101 # WARNING: TELNET IS INSECURE Connected to 10.50.15.101. Red Hat Linux release 7.2 (Enigma) Kernel 2.4.7-10 on an i686 login: xyzz0001 Password: The ssh command is preferred, since it keeps your password and session traffic encrypted over the network (telnet does not!). To transfer files, you can use scp or sftp (encrypted, secure) or plain ftp (unencrypted, insecure). $ scp -p xyzz0001@10.50.15.101:myfile.txt foo.txt xyzz0001@10.50.15.101's password: $ scp -p foo.txt xyzz0001@10.50.15.101:myfile.txt xyzz0001@10.50.15.101's password: $ sftp xyzz0001@10.50.15.101 xyzz0001@10.50.15.101's password: sftp> help $ ftp 10.50.15.101 # WARNING: FTP IS INSECURE Connected to 10.50.15.101. 220 wt127-1.private.algonquincollege.com FTP server ready. Name (wt127-1:abcd0001): xyzz0001 331 Password required for xyzz0001. Password: 230 User xyzz0001 logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> help ---------- Lab Access ---------- The exact list of machines and networks allowed to access the Linux Lab private network has been changed several times by ITS without notice. What is documented here is a snapshot of what seems to work today. It may change again without notice. Locations that are currently allowed access to Linux Lab machines: Algonquin dial-up lines (via modem) Sympatico HSE (PPPoE) open access centres in T building netsrv (www.algonquincollege.com) via Cisco/Microsoft Windows VPN client via Cisco/Linux VPN client for RedHat Linux [unsupported] Locations that are currently *NOT* allowed direct access to Linux Lab machines: acadunix acadaix anywhere on the Internet You can connect from the Linux Lab to ACADUNIX using telnet; but, you cannot connect the other way around. ACADUNIX does not permit incoming "ssh" connections; you must use "telnet" to reach ACADUNIX. ------------------------------- Diagnosing problems: Using ping ------------------------------- You can use the "ping" utility from a DOS or Unix command line to see if a machine is responding: $ ping -c 4 10.50.15.101 PING 10.50.15.101 (10.50.15.101): 56 octets data 64 octets from 10.50.15.101: icmp_seq=0 ttl=252 time=0.4 ms 64 octets from 10.50.15.101: icmp_seq=1 ttl=252 time=0.4 ms 64 octets from 10.50.15.101: icmp_seq=2 ttl=252 time=0.3 ms 64 octets from 10.50.15.101: icmp_seq=3 ttl=252 time=0.3 ms --- 10.50.15.101 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 0.3/0.3/0.4 ms If a machine is not responding: $ ping -c 4 10.50.15.126 PING 10.50.15.126 (10.50.15.126): 56 octets data --- 10.50.15.126 ping statistics --- 4 packets transmitted, 0 packets received, 100% packet loss If you cannot get a "ping" response from a Linux Lab machine, you will not be able to connect to it via ssh, telnet, or ftp. -------------------------------------- Enabling Campus access for Linux Users -------------------------------------- On August 27 I requested that ITS provide off-campus access to the Linux Lab without requiring that students run the Microsoft Windows VPN client at home. (It doesn't make much sense to require students to run Windows at home to do their Linux homework.) In late September I met with the department chair (Claude Brule) and the head of ITS networks (Rod Martin) and we agreed that we needed a solution that worked for Linux users at home. Rod agreed to think of something. On October 4 I met with Rod to hear the ITS "drop-box" solution and ITS reasons why off-campus access is allowed for Windows users but not for Linux users. This is the ITS Drop-Box Linux machine proposal: ITS can configure and implement a "drop box" Linux machine for courses using the Linux Lab. This machine will permit students to copy in/out files from home or from the Lab; but, it will not permit any traffic to flow from home directly to the Lab machines. A student must, while in the Lab, copy all files to the "drop box" machine before going home. At home, the student can copy the files from the "drop box" machine to their own Linux machine to work. Before going back to school, the student must copy the files from the home Linux machine back to the "drop box" machine. Once at school, the student must copy the changed files from the "drop box" machine back into the Linux Lab. The "drop box" machine will be configured the same way as the machines in the Linux Lab, to allow students to test-run their programs on this machine before demonstrating them at school. This proposal makes it at least possible for Linux users at home to have access to a Linux environment similar to that used in the Linux Lab. The proposal doesn't give Linux users any of the same network access enjoyed by Windows VPN users. Below is my "ssh server" proposal to ITS, which would avoid the multiple copy problems of the "drop box" solution and give Linux users much of the College network access that Windows users currently have. We are still negotiating to see if we can convince ITS to run this server for our Linux students: |From: idallen@ncf.ca (Ian! D. Allen [NCFreeNet]) |Date: Sat, 5 Oct 2002 05:03:19 -0400 |To: Claude Brulé |Subject: access to College network for Linux users at home |Cc: Rod Martin , | Robert Allison , | Carolina Ayala , | Bob Kamins , | Shawn Unger , | Gerald C. Hurdle , | Linda MacEwan , | Ken Wilson , poorek, | Patrick Ouellette | |Dear Claude & Linux teachers - | |I had a 1-hour talk with Rod Martin and Jozef Gniadek regarding access to |the College for students who run various flavours of Linux at home and |who for whatever reason can't get the Cisco VPN Linux client running. | |The President wants students to have "anywhere, anytime" learning |capabilities, and at present ITS only guarantees that to students |running the Windows Cisco VPN client at home. My ultimate goal, one |that I think I share with all the Linux teachers and students, is to |give all our Linux users at home the same supported, secure, one-userid, |one-password access to the Collge network that Windows users currently |enjoy. Rod and I weren't quite able to agree on a way to do this that |met Rod's security requirements, and I'll describe why, below. | |As you know, anyone who can use the Cisco VPN client can get full |access to the Algonquin network (including the Linux Lab) by using their |network userid and password from most anywhere in the world. Due to the |proprietary and closed-source nature of the Cisco VPN client software, |it is supplied in binary format, is only supported on a specific type |of RedHat Linux system, and is not distributed as part of any Linux |distribution. It doesn't work for many Linux users. | |If Linux users are to enjoy the same complete access to the College |network, the network access must come via freely available Linux |software that already exists for and is configured in their various |Linux distributions. | |I don't believe that enough Linux distributions currently come configured |with the open-source FreeS/WAN IPSec VPN software that would give Linux |users exactly the same Algonquin access as Windows VPN users. The Linux |VPN software just isn't available "out of the box" in enough systems yet. | |The next best thing, and something that *is* available on almost every |Linux/BSD/Unix distribution, is the security and encryption features of |the standard open-source Secure Shell program "ssh". Students could use |their standard ssh client programs at home to connect to an ssh server |machine on the edge of the College network, and, once logged in, they |could "tunnel" other access to the College network, just as Microsoft |users tunnel their network access using the Cisco VPN. This does not |give Linux users true VPN access to the Algonquin network; it only |enables specific TCP connections, which is still very useful. | |For my courses, my Linux students want access to the files and machines |located in the Linux Lab to work on assignments from home, and they want |access to their College "N" drives. A set of ssh tunnels would do these |things perfectly. | |Given an ssh tunnel, Linux users would have most of their "anywhere, |anytime" environment and could do most of the things that Windows users |do, including mount N drives and connect to the Linux Lab for homework. |Just like the Microsoft VPN, it would be a one-userid, one-password sign |on to the network, with an encrypted data stream. | |This solution has so far failed to gain Rod's approval because he does |not think an ssh server implementation on a Linux machine at the edge of |the the College firewall is secure enough. The Cisco VPN server runs on |dedicated Cisco hardware in which ITS has good confidence. A Linux ssh |server machine is not as secure; because, it is still a general-purpose |computer with greater risk of compromise. Rod considers the risk of a |Linux/ssh compromise too high. | |I think Rod's concerns can be addressed; but, I had to go teach a |class and didn't have time to discuss in detail what might be done to |"harden" the Linux ssh server to make it secure enough for Rod's approval. | |I really hope we can eventually make this work for our Linux students and |faculty, since it really does address the President's "anywhere, anytime" |mandate, and just one ssh server can work for all the Linux/Unix users |and give secure access to most of the services on the College network. | |In the interim, Rod had a different proposal. | |Rod proposes that Dick Campbell prepare a Linux machine that is identical |to the Linux environment in the Linux Lab, and move this machine to |the College DMZ. All services would then be disabled on the machine |except incoming ssh connections. (No outgoing connections would be |allowed at all.) Students at home could ssh into the machine to drop |off and fine-tune their assignments; students in the Linux lab could |also ssh into the machine and pick up things left there and copy them |to the Linux lab machines for demonstrations. All port-forwarding in |ssh would be disabled, to prevent tunneling. | |This would allow students running Linux at home to have a place where |they could fine-tune their Linux assignments before handing them in. |It would not give students at home access to any files that are in |the Linux Lab, since no outgoing connections from the machine would be |permitted. No assignments requiring any kind of web or other network |access (including outgoing email) could be run on this machine. | |This "drop box" machine addresses well the single issue of "how do Linux |students get access to a Linux machine like the one in the Linux lab". |It doesn't give students access from home to their files in the Linux |Lab, which means if a student needs something that's in the Lab they |have to boot Windows, start the Microsoft VPN Client, fetch the file, |then reboot back to Linux. The "drop box" machine implementation also |doesn't give Linux students access to their N drives, nor access to |the College intranet, nor to anything else on the College network. |It isn't the "anywhere, anytime" access that students ultimately need. | |In conclusion, I think we as a Linux/Unix community might try to think |of and suggest ways to "harden" a Linux ssh server (or propose an |alternate ssh sever) to make it acceptable to Rod as a safe supplement |to the proprietary Cisco VPN server that ITS now supports. If Rod can |see this ssh server as meeting his security criteria, it would provide |a good open-standards approximation to the one-userid, one-password |network access that Windows users have. | |If we are unable to meet Rod's security criteria with an ssh server |proposal, we can at least ask Dick Campbell to implement the "drop box" |machine for the Linux Lab. Rod estimates that this will take at least |two weeks to set up and install. We are still discussing my "ssh server" proposal. I have been unable to find an SSH server with enough features and compatibility that ITS is willing to run it. SSH servers that run under Windows are available; but, they don't have the connection logging and time-out features that ITS insists on having. November 2002 ------------- The College has closed all SSH access to campus. This makes the installation of an SSH server irrelevant; nobody could use it. From: Rod Martin Subject: Re: port 22 still blocked To: "Ian! D. Allen [NCFreeNet]" Date: Mon, 11 Nov 2002 10:10:24 -0500 > From: idallen (Ian! D. Allen [NCFreeNet]) > Date: Sun, 3 Nov 2002 13:19:11 -0500 > To: Rod Martin > Subject: port 22 blocked into Algonquin > > Since last week's outage I can't get to my old desktop machine > at 205.211.32.96 (in WB-371) using ssh (port 22) from off-campus > (206.47.37.39). I could connect okay up until Thursday. Can you > please have them unblock the port again? And it will probably remain blocked for a while. We are still performing a comprehensive review of the security of the College network in the wake of the DOS attack we have been experiencing. Once we complete the review we can look at ssh again. At this point I would recommend using the VPN client. Regards Rod The only supported way to connect to the College is using the Microsoft VPN client. Linux users at home must do their homework under Linux, copy the answer to their Windows partition, shut down Linux, reboot the machine into Windows, start up the Microsoft VPN to connect to the College, copy the assignment to the Linux Lab, then shut down the VPN, shut down Windows, and reboot back into Linux.