# Logging In to Remote Linux Machines

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.

• Two-factor authentication is used on the VPN logins.

Currently the only available option is the DUO smartphone app. SMS and hardware tokens are not supported.

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:

• You left something running on a server (i.e., you disconnected or lost your network connection before shutting a program down) and want to go back and clean it up.

You would need to return to the same server that you were using before.

• The server you are on slows down dramatically or starts behaving strangely and you suspect that it is overloaded and/or crashing.

You would want to exit that server and then choose a different one in order to resume working.

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…

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

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, modify the ssh command with a -p option as shown here.

• If you get a message saying “The authenticity of host … can’t be established”, don’t worry. This is a way SSH tries to protect you against people trying to capture your login info by “spoofing” or impersonating a legitimate machine.
• In practice, you’re not likely to know whether this info is correct or not, so reply “yes” to proceed with the connection.
• If you get a message saying that “linux.cs.odu.edu” is unknown, you probably are not connected to the VPN.
• If you get a message shouting “POSSIBLE DNS SPOOFING DETECTED”, it’s really not as bad as it seems. See here for an explanation of why you are getting this message and how to get rid of it.

# 4 Logging In

• Do include the “cs_” that is part of all student login names issued after mid-August 2021.
• Don’t prepend a “CS" or ”CS/". That’s a Windows-specific convention.

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

• Note that as you are typing your password, nothing will happen on your screen. Unix does not echo your password back to you. Most programs and operating systems will not do that with passwords, as a basic security precaution against someone snooping your password from over your shoulder or even electronically.

What you may find unusual, however, is that Unix will not even echo back blank characters or *s to show how many characters you have typed. This seems to disturb some people, but it’s a further security precaution. Just knowing how many characters are in your password would be valuable information to someone trying to crack your account.

who am i


# 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.

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.

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.

# 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.