Logging In to Remote Linux Machines

Steven Zeil

Last modified: Aug 24, 2023
Contents:

In a previous reading, you learned that traffic over networks is organized by protocols and that many protocols are designed to allow client software one one machine to request services from server software on other machines.

Now we are going to build on that idea to use your PC to log into and issue commands to remote Linux machines.

There are two basic steps involved in logging in to the CS Dept Linux servers:

  1. Connect to the CS network via a VPN.
  2. Connect to a Linux server via SSH.

1 The CS VPN

The CS Department Linux servers are hidden behind a VPN. Before you can connect to those servers, you will need to connect to that VPN.

Find the instructions to install and run the VPN on the Resources page.

Remember that you are supposed to log in with your CS network credentials, not your Midas credentials.

If you try to log in to the VPN and it seems to hang for a long time, check your cell phone for a notice that it is awaiting the two-factor confirmation of your identity.

If you continue having problems logging in to the VPN, you will need to contact the CS systems staff at root@cs.odu.edu for help.

Connections to the VPN will time out!

You will usually need to bring up the VPN program and reconnect once or twice a day.

2 SSH

2.1 The SSH Protocol

We will be accessing the remote machines via SSH (Secure SHell), an Internet protocol for issuing text-mode commands to remote machines.

There is an older text-based protocol for giving commands to Unix called “telnet”. Telnet is still used for a variety of purposes, but has fallen out of favor because it sends everything (including your login name and password) in plain-text format, leaving you vulnerable to someone else on your network eavesdropping via “packet sniffers”.

By contrast, ssh encrypts all your communications, so you are safe even if someone is eavesdropping.

SSH allows a person connected to the Internet to log into other machines on the Internet and to issue commands to those machines.

2.1.1 Clients & Servers

Like many network protocols, SSH is based on the idea of servers on a variety of different machines that wait for clients to connect to them and request a service (in this case, an SSH connection).

To use ssh, you must

  1. have an ssh client program on the machine where you are seated, and
  2. you must know the name (or the IP address) of a machine elsewhere that is running a ssh server, the program that accepts logins and subsequent commands from the client, and
  3. you must have credentials (login name and password) allowing you access on that server.

2.1.2 Choosing Your SSH Server

As of JUly 2022, the CS Dept. provides four general purpose Linux servers, and provides a “switching” machine that is supposed to distribute the users equally among the servers to reduce the chances of a server being overloaded.

Most people, most of the time, will use the random selection option, linux.cs.odu.edu. The circumstances in which you might want to try for a specific machine are:

2.2 Login Accounts

You will, of course, only be able to connect to machines where you actually have a login account. If you are a student registered for a CS course at ODU, and have never had a Unix account on the CS Dept system, you will need to create an account.

If you have had an account in the recent past, it should be regenerated for you in any semester when you are registered for a CS course. Otherwise, you will need to contact your instructor or the CS systems staff to get your account.

3 Starting a Remote Session on a Linux Server…

OK, you’ve selected your server, know your login name and password, and are ready to connect.

Remember, you need to be connected to the VPN before attempting to make an SSH connection to a CS Department server.

What you do next depends on the operating system of your local PC and what software you have on there.

3.1 … from a Windows Machine

On a Windows PC, you will need an ssh client program.

If you are on your own PC, you can choose the client program to install and run. If you are on a lab PC, at work, or for some other reason using someone else’s machine, you either need to use whatever they have installed or bring your own client program, probably on a USB flash drive.

3.1.1 Native OpenSSH

Windows 10 builds from the Fall of 2018 and later have a native implementation of “OpenSSH”.

This is the recommended client for most Windows 10 users.

Before you can use this, , it must be activated.

  1. Open Settings.
  2. Go to Apps, then Apps and Feature, then Optional Features.
  3. Find the entry for OpenSSH Client (Client, not Server!), click on it, and then click Install.

    Follow the on-screen instructions to complete the installation.

To run this, open a CMD window (type “cmd” into the search bar). Then follow these instructions to issue the appropriate ssh command.

3.1.2 If You Can’t Run Windows 10 OpenSSH…

…because your Windows PC is too old.

CygWin is a Unix emulation (technically, POSIX) layer that has been used by many programmers since Windows 95. When installed, CygWin allows you to open a terminal session using a Unix-style command shell, from which you can run many of the basic commands associated with the Unix systems.

Install CygWin, including the optional openssh package. You will now have a CygWin Terminal entry in your Start menu. Running that will open up a terminal session from which you can issue most of the Linux commands that you will be learning in this course.

Open a CygWin Terminal and issue an ssh command to connect to a remote machine.

3.2 … from a Chromebook

First, open up a Linux Terminal.

You are now running Linux, so follow the instructions below for launching a remote session from a Linux machine.

Follow these instructions to issue the appropriate ssh command.

3.3 … from a Linux or MacOS Machine

All Linux and MacOS machines should include the ssh client program, ssh.

First, you will need to open a terminal on your machine.

Then…

3.4 The ssh Command

Within your local session, give the command

ssh yourLoginName@sshHostName

filling in your CS Unix login name and the name of the ssh server machine you chose earlier (including the .cs.odu.edu ending).

So, to get a randomly selected Linux server from the CS Dept, you would use

ssh yourLoginName@linux.cs.odu.edu

If you prefer to select a specific server instead of accepting the random selection, give that server name instead of “linux”.

You should now be prompted for your password. You are ready to log in.

4 Logging In

If you are prompted for your login name, enter it.

At the“password:” prompt, enter your password.

After a few moments, you should receive a command prompt. You are now ready to start issuing commands. For example, the “Hello World” of the Unix community might be:

whoami

5 Setting Your Terminal Type

Remember that Unix evolved in a time when many manufacturers made many different models of computer terminals, each with its own set of command codes for clearing the screen, moving the cursor to different screen positions, setting bold face, underline and other text characteristics, and so on. A typical Unix installation will be equipped to communicate with any of a few hundred different types of terminals.

Now, you’re not using a terminal, but your ssh client program actually works by simulating an “old-fashioned” computer terminal. The authors of your client program chose one or more kinds of terminal that they would simulate. For Unix to manipulate your screen appropriately, it most know what kind of terminal command codes your ssh client program is prepared to accept.

Most of the time, the Linux system will recognize the type of terminal that your ssh client is running. If, however, you find that some commands seem to be showing garbled text, in particular if text seems to jump around to odd locations in your window, then read on.

If that’s not happening to you, you can skip the rest of this section.

Find out the kind of terminal being emulated by your telnet program. You may need to consult the program documentation or help files for this. You may also be able to deduce this information from the program’s “Options” or “Preferences” menus.

Here are some common choices:

SSH client program TERM type Comments
Windows OpenSSH xterm
Command-line SSH, basic form, Linux or MacOS xterm or Linux
Command-line SSH, basic form, CygWin xterm or rxvt Depends on what type of window you type the command in.
Command-line SSH, xterm variant xterm

Look at the messages that you received after logging in. If it includes a line saying something like “Terminal type is…” and the terminal type that it names makes sense for your ssh client program, you’re all set and don’t need to change it.

Luckily, most ssh clients these days default to some variation of xterm and Linux more or less expects that as a default.

That means that you rarely need to worry about the terminal type.

If, however, you find that command output appears to be formatted strangely, with results popping up in random lines or columns or with strange graphics characters appearing in the middle of the output, you may have a clash between the terminal type provided by your ssh client and what Linux thinks it is talking to. In that case, read on…

You can also check the terminal type by giving the command

echo $TERM

If the terminal type seems wrong, or you see a message indicating that you are on a “dumb terminal”2 , you need to tell the Unix system what kind of terminal you are really emulating. The command to do so is

export TERM=xxxx

where xxxx is the kind of terminal (e.g, export TERM=vt100).

Most “dumb” terminals provide for 24 lines of text. Your ssh client may have defaulted to this, but most Unix systems will allow their terminals to provide a larger text area. If you choose to use a larger text area (i.e., resize the window showing your terminal session), your ssh client may take care of notifying the remote machine of the change. If, however, you see evidence that it did not do so (e.g., it only scrolls 24 lines even when you are showing more), you can tell Unix how many lines you are using by giving the command

stty rows nn

where nn is the number of rows/lines.

6 Changing Your Password

Whether we like it or not, we need to worry about the security of our computing environment. There are people who would take advantage of this computer system if they had any, or more complete, access to it. This could range from the use of computer resources they have no right to, to the willful destruction and/or appropriation of the information we all have online. In order to maintain the level of security in our computing environment that we need, there are some things we all have to take responsibility for. Even though you may not feel like you personally have much to lose if someone had access to your account or files, you have to realize that as soon as someone gains ANY access to our system, it’s 100 times easier for them to gain access to ALL of it. So when you are lax with your own account, you are endangering the work and research of everyone else working here.

Your password is the fundamental element of security not only for your personal account, but for the whole UNIX system that we share. Without an account and password a person has NO access to our system. If someone discovers (or you tell someone) your password, not only will they have access to your personal files, but they will have a much better chance to launch attacks against the security of the entire system.

Your account password is the key to accessing and modifying all of your files. If another user discovers your password, he or she can delete all your files, modify important data, read your private correspondence, and send mail out in your name. You can lose much time and effort recovering from such an attack. If you practice the following suggestions, you can minimize the risk.

  1. NEVER give another user your password. There is no reason to do this. You can change permissions and have groups set up if you need to share access with other individuals. Your account should be yours alone.

  2. Never write down your password. Another person can read it from your blotter, calendar, etc. as easily as you can.

  3. Never use passwords that can be easily guessed. Personal information about you (birth date, etc.) may be known to the attacker or may be recorded in on-line databases that the attacker has already obtained.

    Passwords should not be single words (in any language) because on-line dictionaries are widely available for use in spelling checkers. A common approach to cracking passwords is to compile a set of such words and to run a program that tries each one on each account on the machine. Consider inserting punctuation and other “odd” characters into your password to foil such attacks.

    • Note, however, that so-called L33T substitutions, such as using “3” in place of “E”, do not improve your security. These are so widely known that password crackers routinely apply them to their word lists when trying to guess your password.

    A person with local knowledge can also try your spouse’s name, pets’ names, etc. Your account is vulnerable to this type of cracking unless you choose your password carefully.

  4. Change your password the very first time you log in, and every few months thereafter. Security problems are often traceable to stale passwords and accounts. These are accounts that have become inactive for one reason or another or the password has not changed for a long time. In our particular environment we have had break-ins via such stale accounts. A password that remains the same for a long time provides an intruder the opportunity to run much more advanced and longer running programs to break such passwords.

  5. Vary the system by which you choose a password. For example, don’t repeatedly use combinations like BLUEgreen and REDyellow. If an intruder discovers your pattern, he or she can guess future passwords.

To change your password on the CS network, log in to the VCPortal, select one of the VCLab machines,  and then follow these directions.

7 Logging Out

To leave our Unix systems, type

exit

(not logout, as indicated in some books.)

Important: Do not leave your SSH sessions by simply closing the window in which it was running. This may leave you still connected to the remote machine or it may leave programs still running there. Over time, such bad behavior by multiple people will overload the server.

Late in the semester, it’s very common to see our servers straining under the accumulated weight of abandoned programs from CS252 students (particularly because we usually have more than 200 students per semester in CS252). This, of course, becomes critical right when many students are frantically trying to complete their assignments in CS252 and other courses.

Make it a habit to shut down via the exit command.

8 Command Glossary

Commands covered in this lesson:

On your own PC

Command example explanation
ssh yourCSLoginName@server ssh cs_jdo001@linux.cs.odu.edu Log in to a remote server

In Linux:

Command Example Explanation
echo echo $TERM prints whatever its arguments really stand for
exit exit Log out of your current SSH session
export TERM=xxx export TERM=vt100 set your terminal type
whoami whoami prints your user name

1: A dumb terminal is one that displays lines of text but has no command codes for moving things to specific locations on the screen or doing other basic operations. Many Unix applications, such as text editors, will not work with dumb terminals.