This is an old revision of the document!
Linux SSH Access
All Linux servers run 'ssh'. Anyone with a CS account may log into these servers.
From inside UVA, you can simply 'ssh' to CS servers typically by using a Terminal application like HyperTerm (Windows) or Terminal (Mac).
From outside UVA, you are not able to 'ssh' directly into CS servers. However connections to portal.cs.virginia.edu
are still allowed from outside of UVA.
You must use your CS domain userid (identical to your UVA userid) and password to 'ssh' to portal. For example:
ssh -l jsp9ew portal.cs.virginia.edu. Alternatively, ssh jsp9ew@portal.cs.virginia.edu
Note that if you are opening a terminal application on your Mac or PC, your username on the Mac or PC may be different from your CS domain userid. So be sure to include your CS domain userid on the 'ssh' command line.
If you'd like to use a graphical windowing interface to department servers, see: NX Linux Remote Desktop Cluster
Access from Outside UVA
Use one of these options to access CS servers from outside of UVA.
Option 1: VPN access
If you are outside of the UVA network (off grounds) then you can use the UVA VPN to access CS servers via SSH.
Option 2: Access via portal.cs.virginia.edu
You can ssh directly into portal.cs.virginia.edu
without having to use the VPN. Once you are logged into the portal
cluster, you can then ssh to other CS servers. Note! From off grounds, you can ONLY ssh into portal without using the VPN. You cannot ssh directly into other department servers.
[ktm5j@outside-uva ~]$ ssh -l ktm5j portal.cs.virginia.edu ktm5j@portal.cs.virginia.edu's password: Last login: Mon Jul 29 14:12:10 2019 ktm5j@portal04 ~ $ hostname portal04 <-- We are logged into portal cluster ktm5j@portal04 ~ $ ssh gpusrv01 <-- We can now access gpusrv01 ktm5j@gpusrv01's password: .... ktm5j@gpusrv01 ~ $
SSH Jumphost Options
The OpenSSH ssh client has an option -J
to specify a host to use as a “jumphost” that lets you access other servers directly, in one step. This combines two steps (ssh into portal.cs.virginia.edu and then ssh to gpusrv01) into one single command. From the manpages:
-J destination Connect to the target host by first making a ssh connection to the jump host described by destination and then establishing a TCP forwarding to the ultimate destination from there. Multiple jump hops may be specified separated by comma characters. This is a shortcut to specify a ProxyJump configuration directive. Note that configuration directives supplied on the command-line generally apply to the destination host and not any specified jump hosts. Use ~/.ssh/config to specify configuration for jump hosts.
Here is how we use this option to “jump” from portal.cs to another CS server. Let's repeat the example of logging in to gpusrv01
[ktm5j@outside-uva ~]$ ssh -l ktm5j gpusrv01 -J portal.cs.virginia.edu ktm5j@portal04.cs.virginia.edu's password: <-- first asked to authenticate to portal ktm5j@gpusrv01's password: <-- immediately able to log into gpusrv01 .... ktm5j@gpusrv01 ~ $
Server Domain Names
Computer Science hosts its own DNS server with authority over the cs.virginia.edu
domain space. Any server in CS will have a fully qualified domain name (fqdn) of hostname.cs.virginia.edu
.
Short Names
If you are inside of the Computer Science network then use the hostname of a server instead of its fully qualified name. For example, if you are logged into a CS server, you can ping another server by its hostname alone.
username@power5:~$ ping power3 PING power3.cs.virginia.edu (128.143.67.43) 56(84) bytes of data. 64 bytes from power3.cs.virginia.edu (128.143.67.43): icmp_seq=1 ttl=64 time=0.149 ms 64 bytes from power3.cs.virginia.edu (128.143.67.43): icmp_seq=2 ttl=64 time=0.123 ms
This will not work from outside of the CS network unless you modify your DNS search path to contain cs.virginia.edu
.
Login
From Linux/Mac OS
To log into this server from another computer running Linux/Unix/MacOS, run the following from a shell:
username@host ~ $ ssh username@gpusrv04.cs.virginia.edu username@gpusrv04's password: <- Enter Password ... [username@gpusrv04 ~]$
In Mac OS the Terminal app can be found in the Utilities folder under Applications.
From Windows
For information about SSH clients for Windows, see the article SSH from Windows
Servers
For a listing of generally available servers in CS, see the article General Purpose Nodes
Login Restrictions (Info for Faculty)
Here in CS we want to give all of our users fair and equal access to whatever computing resources we have to offer. For this reason we are discontinuing the practice of restricting login access to certain servers. However, there are a number of servers that still have access restrictions in place. This article is to show users with sudo
privileges how to edit /etc/security/time.conf
to allow user logins.
There are several configuration files located in /etc/security
on Linux servers. In this directory, we can use time.conf
to restrict ssh login to a specific set of user accounts.
PAM Setup
This section can be skipped over if your server has already been configured with login restrictions.
By default, access rules in time.conf
are not used unless a PAM module (pluggable authentication module) is configured to read them. This is done by adding a line to the sshd
PAM module file.
Add the following line to the file to the end /etc/pam.d/sshd
:
account required pam_time.so
time.conf
Now that PAM is configured to read time.conf
we can now put in a rule. Here is an example rule from time.conf
:
sshd;*;!root&fls4t&ejs3s&pgh5a;!Al0000-2400
This line is formatted such that the users listed are separated by ampersand &
characters. This entry will allow the users root
, fls4t
, ejs3s
and pgh5a
are allowed access. Be sure to always include yourself and root in this rule. Failure to do so may result in everyone becoming locked out.
If we wanted to add the user ktm5j
to this rule above, we would insert the string &ktm5j
like this:
sshd;*;!root&fls4t&ejs3s&pgh5a&ktm5j;!Al0000-2400
Changes to this file take effect immediately, no services need to be restarted. When editing this file, be sure that you keep at least one active ssh connection until you have tested your changes. This will prevent becoming locked out if any errors are made!