Accessing hosts

Attention

The external ssh server, login1.oden.utexas.edu, will be retired on 8/31/2025. This is an effort to reduce our exposure of external facing services from threats. Going forward please use UT’s vpn service, vpn.utexas.edu.

Hosts on the oden domain can be accessed remotely when on or off campus by two methods.

  • When on campus, hosts @oden.utexas.edu can be accessed using password authentication or SSH public keys. ‘On campus’ means the Austin UT campus, this does not include TACC.

  • When off campus, hosts can be accessed by using UT’s VPN service. This method requires the use of DUO and an active UT appointment.

Hint

All UT appointments are approved by the PI and created by HR. Please reach out to your PI or the research administrative assistant in your group or center to request an appointment. Sysnet is not able to create appointments.

Note

For more information on UT’s VPN service, please visit the following links UT VPN wikis and UT VPN ServiceNow Articles. The information is extensive and should answer most questions.

SSH

There are a number of reasons why you would want to use SSH keys over regular passwords when accessing hosts. In our environment, we allow the use of password and SSH pub/priv keys for authentication, the later being our recommnedation. You can search the web for reasons why SSH pub/priv keys are better, but here are a few reasons.

Enhanced Security

  • Stronger Authentication: SSH keys use public-private key pairs and cryptographic algorithms for authentication, making them significantly harder to guess or brute-force compared to passwords.

  • Protection Against Brute-Force Attacks: Since keys are very long and complex, attackers cannot easily attempt multiple login combinations.

  • No Password Transmission: Your private key never leaves your machine, minimizing the risk of it being intercepted during transmission, unlike passwords which are sent over the network.

  • Reduced Phishing Risk: Users are not prompted to enter a password, lessening the chance of falling victim to phishing scams.

  • Server Compromise Resilience: Even if a server is compromised, hackers cannot use stolen public keys without the corresponding private key

Increased Convenience

  • Passwordless Access: Once set up, you can log in without entering a password each time, saving time and reducing typing errors.

  • Automation-Friendly: SSH keys are ideal for automating tasks and workflows that require remote server access, like scripts or CI/CD workflows, without needing to hard-code passwords.

  • Easier Management: While initial setup requires more effort, keys allow for better access control by managing individual user keys and revoking access without changing passwords.

  • User-Specific Keys: Each user can have unique keys for different servers or services, preventing password reuse issues and facilitating access revocation.

SSH Port

All hosts on the oden domain use the well known port, 22, for ssh.

SSH keys

You can setup ssh public key authentication for logging into your Oden Institute account remotely. This allows you to prevent your encrypted password from being sent over the network. It also allows you to setup password-less logins to any machines.

Create a private/public key pair

Execute the following instructions below depending on your client.

For Linux and Mac clients:

# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/oden/stew/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /oden/stew/.ssh/id_rsa.
Your public key has been saved in /oden/stew/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:GKW7yzA1J1qkr1Cr9MhUwAbHbF2NrIPEgZXeOUOz3Us stew@suzerain
The key's randomart image is:
+---[RSA 2048]----+
|.*++ o.o.        |
|.+B + oo.        |
| +++ *+.         |
| .o.Oo.+E        |
|    ++B.S.       |
|   o * =.        |
|  + = o          |
| + = = .         |
|  + o o          |
+----[SHA256]-----+
#

If you are on campus or on UT’s VPN with your client and you want to copy your key over to your account here, use ssh-copy-id. This will allow you to use password authentication to copy your key to the correct location on your remote host:

ssh-copy-id -i ~/.ssh/id_rsa user@<host>.oden.utexas.edu

If you are off campus, your only option is to connect to the VPN and issue the ssh-copy-id above to place your public key in the proper location.

For more detailed instructions visit https://www.ssh.com/ssh/copy-id

For the Windows clients

  1. Follow the Installation instructions for Windows here: https://www.ssh.com/ssh/putty/download

  2. Generate the key using PuTTYgen here: https://www.ssh.com/ssh/putty/windows/puttygen Important. Copy and paste the public key that was generated in the box below the text Public key for pasting into OpenSSH authorized_keys file into a file or directly into the help request. This is the public key portion we place into your authorized_keys file under your .ssh directory in your home dir.

Please keep in mind that we require the use of a passphrase.

Some machines may put these files in a different spot. If this is the case, make a note of where it puts them and what it names them. The id_rsa (and, if they exist, id_dsa or identity) file is your private key. Keep it secret, keep it safe.

Passwordless logins

In order to enable passwordless authentication, you need to have an ssh-agent process running. To start the agent in a bash shell, do:

$ eval `ssh-agent`

Add your ssh key to the running agent:

$ ssh-add ~/.ssh/id_dsa

Once this is done, you should be able to login to any system without needing to type your password.

Fail2ban

Wwe use Fail2ban to provide a layer of security for our workstations. Here are some things to keep in mind:

  • Trying to login with an incorrect password for an existing account will lock you out after 5 unsuccessful attempts

If your IP address is blocked, you will receive a message that looks something like this:

ssh_exchange_identification: Connection closed by remote host

If you see this message, send an email to RT and ask us to fix it for you or you can remove the ban yourself.

To remove the IP address that has been banned, you would need to know the IP address that is banned and access the desktop from another IP address that is not banned. This will require a couple hops to get to the desktop you have been banned from. Most users have access to multiple desktops in their group. Login to another desktop then access the desktop that has been banned. Use the following utilities to view and remove the banned IP address.

$ sudo /usr/local/bin/fail2showbans.sh
The IP addresses banned from logging into this system are listed
below with "IP List:"
Status for the jail: ssh-iptables
|- Filter
|  |- Currently failed: 2
|  |- Total failed:     12009
|  `- File list:        /var/log/secure
`- Actions
  |- Currently banned: 29
  |- Total banned:     1145
  `- Banned IP list:   202.131.225.54 173.201.23.110 58.67.199.9

$ sudo /usr/local/bin/fail2unban.sh 202.131.225.54
Please wait a moment..
202.131.225.54

Preventing Lockouts

There are some things you can do to try and prevent yourself from getting locked out by Fail2ban. The first thing would be setting up ssh key pairs (see below). This will also allow you to do things like passwordless logins once you have an ssh agent running.

Another common problem is that your username is different for your oden account and the machine you are attempting to connect from. The following solution was sent to us by a user with this problem:

I am now using the following lines in my ~/.ssh/config file:

Host *.oden.utexas.edu
  User     solj

This sets the default user for all oden machines. So that when I ssh in from home it uses the oden user name instead of my home user name.

Proxy Jump

Warning

The information below will no longer be relevant when login1.oden.utexas.edu is retired. Information below is kept for historical purposes and will be obsoleted in the future

SSH ProxyJump hosts

This assume you have correctly setup your ssh public keys as described above.

It is possible to jump directly into a host on the network if you are not on the campus network using the ProxyJump option in SSH.

To login from a remote host off-campus to a host on the institutes network:

$ ssh -J <user-name>@login1.oden.utexas.edu <user-name>@<host>.oden.utexas.edu

SCP ProxyJump

It is possible to copy files from a remote host not on UT’s network to a host on the network using the same principle as the previous section using ProxyJump.

On the remote host, execute:

$ scp -o 'ProxyJump <user-name>@login1.oden.utexas.edu' <local_file_or_directory> <user-name>@<host>.oden.utexas.edu:/<destination>

A helpful link https://www.madboa.com/blog/2017/11/02/ssh-proxyjump/

Using rsync to copy files

Similar to scp, rsync is another option to use if moving large amounts of files securely. It uses a similar setup as above:

rsync -avz -e 'ssh -J <user-name>@login1.oden.utexas.edu' --progress <local director> <user-name>@<hostname>.oden.utexas.edu:/<destination>

Connecting to a VNC session

To connect to a VNC session from a remote location to a host running a vnc server session on a hosts, use the following command to setup a tunnel:

ssh -Ao ProxyCommand="ssh -W %h:%p  <user-name>@login1.oden.utexas.edu" -L 5902:127.0.0.1:5901 -N  <user-name>@<hostname>.oden.utexas.edu

This should actually fork a process in background and allow you to run the vncviewer and connect to vnc session that is running on the host.

A helpful link https://boknowsit.wordpress.com/2018/09/02/vnc-and-ssh-port-forwarding/