Remote access to EECIS systems is available via SSH. For links to client software, see UseSSH. All EECIS systems have SSH software installed by default.
We encourage users to use one of our Linux systems for their appropriate tasks:
|Hostname||Operating System||Hardware||Architecture||Users with access|
||Ubuntu 18.04 Linux||Virtual Machine||x64 (amd64)||Academic|
||Ubuntu 20.04 Linux||Physical machines||x64 (amd64)||Research|
hoek.eecis.udel.eduis no longer in service as a general-purpose research machine. It is replaced by an expanded
catan.eecis.udel.edu. This change was due to CentOS6 going out-of-support (with no good upgrade path to CentOS7, which is being sunsetted early). Connections to
hoekwill be forwarded to a
mlb.acad.ece.udel.eduis no longer in service as the general-purpose academic machine. It is replaced by
catan load balances between multiple servers.
That is why when you connect you will notice the hostname has a number, e.g.
The preferred remote access systems are
catan.eecis.udel.edu (research), and
These servers allow remote ssh access from off-campus. Other ECE/CIS
administered servers allow ssh connections from systems on
campus networks (including via the UD VPN).
Connections from other networks are blocked.
The remote-access hosts are shared systems, so the following policies are in effect:
No process on the remote access hosts may run for more than 100 cpu hours, after which it will be automatically killed. If you will need more than 100 cpu hours, you will need to restart your process.
Each remote-access system will be rebooted monthly so that security patches may take effect in a timely manner.
3 will be rebooted on the first/second/third Monday of a month, respectively.
On each preceeding Friday, the load balancer will stop forwarding new connections to the given machine.
go will be rebooted when needed as course loads permit.
If you’d like to
ssh between hosts without using a password, you can set up
key-based authentication as follows. This will work between all ece/cis hosts
that share home directories.
ssh-keygen -t dsa Enter file in which to save the key (/usa/<username>/.ssh/id_dsa): Enter passphrase (empty for no passphrase): **<enter>** Enter same passphrase again: **<enter>** > cat ~/.ssh/id_dsa.pub >>! ~/.ssh/authorized_keys
You can now append your
~/.ssh/id_dsa.pub to other authorized_keys files in
other home directories in order to move between research and acad systems, or
between research and private computers.
The point of public-key authentication is that the remote system uses the public half of your key pair to verify that you possess the private half. If, of course, anyone else gets a copy of the private half, they can readily impersonate you. Attaching a passphrase to the key pair encrypts the private half of your key with the pass phrase, so even if you lose control of the private key file, an attacker would need to decrypt the key in order to use it. Thus, under most circumstances it is a bad idea to do without a pass phrase on your SSH keys.
It can be inconvenient to have to enter your pass phrase every time you want to
access a remote host. Most SSH implementations permit the use of an ssh-agent
to manage your SSH keys. On systems using OpenSSH (including EECIS-managed
UNIX systems and Mac OSX machines), the ssh-agent is called (sensibly enough)
ssh-agent. The ssh-agent remains in memory and permits connections via a UNIX
socket (usually located under /tmp) which is readable and writable only by you.
SSH clients (ssh, sftp, scp, and ssh-add for the most part) know how to
contact the agent via the $SSH_AUTH_SOCK environment variable, which
point to the above-mentioned UNIX socket. Once the agent is started, you load a
key into it using ssh-add
You should ensure that nobody else can access the $SSH_AUTH_SOCK socket, however, since that would permit them to authenticate to remote machines as you using your agent. In particular, root and anyone using a shared account will be able to access this socket!
Some times it is convenient for one machine to be able to perform activities on another machine on behalf of a user without their being around. For example, you may wish to regularly synchronize a directory tree from one machine to another. You could accomplish this by having a pass-phrase-less key, but as discussed above, this has significant security implications. There are two main ways to limit the security risks of automated SSH access: a long-running SSH agent, and restricting the authority of the ssh-key used.
Most ECE/CIS systems strive to be openly available, but sometimes need dictates limiting access to some resources. We’ll try to list some of these resources so that searches will turn up something, but be aware that access to them may require you contact a Faculty member and/or PI of a sponsoring grant to gain access to them.
Infolab.ece is a 7 node, 56 core cluster owned by Dr. Fang. More info is available
ir.cis is an 8 node, 64 core cluster owned by Dr. Carterette. More info is available