Accessing TRComp Nodes
There are two ways to access the remote machines:
CLI Access
Connecting via CLI
Open a new cmd or powershell terminal and connect to the remote server:
ssh username@remotehost
If some for reason you are unable to add your private key using the ssh-add command above, run the following command
ssh -i [path to the privatekey] username@remotehost
Using SSH Agent in Windows
Remember that private key files are the equivalent of a password should be protected the same way you protect your password. Use ssh-agent to securely store the private keys within a Windows security context, associated with your Windows account. To start the ssh-agent service each time your computer is rebooted, and use ssh-add to store the private key run the following commands from an elevated PowerShell prompt on your server:
# By default the ssh-agent service is disabled. Configure it to start
# automatically.
# Make sure you're running as an Administrator.
Get-Service ssh-agent | Set-Service -StartupType Automatic
# Start the service
Start-Service ssh-agent
# This should return a status of Running
Get-Service ssh-agent
# Now load your key files into ssh-agent
ssh-add $env:USERPROFILE\.ssh\id_ed25519
If you have configured a passphrase during the key generation process, enter the passphrase when prompted.
Once you've added the key to the ssh-agent on your client, the ssh-agent will automatically retrieve the local private key and pass it to your SSH client.
Using SSH Agent in Linux
If you're using one of the standard Windowing environments on a reasonably recent Linux distribution, there's a good chance your SSH key will automatically be added to an existing (ie. automatically started) ssh-agent proces when you try to login to a remote host with SSH. If you're using a less standard environment (Window Maker/GNUStep, Aweseome, i3, sway, etc) you may need to include your SSH agent details in your shell's .rc file (eg. .bashrc, .zshrc, etc.), or through some other mechanism such as a user systemd service.
When using your shell's .rc file you'll need to remember to look for an existing ssh-agent before starting a new one. Otherwise, you'll have ssh-agent
processes piling up and you'll need to add your key for each new shell you create. You can do some manual checks in your login script by checking
for a running process and/or a unix socket for the running ssh-agent process (see ssh-agent(1) for more info).
An easier way to handle this is to use keychain(1). Keychain can report appropriate environment variables like
running ssh-agent -s but it will know not to start a new instance of ssh-agent if one already exists. It also has a few handy command-line argument
values that allow you to inject your keys on startup by specifying their names, and an option to inject the SSH agent environemnt variables into your user
systemd session, making SSH agent available to various xorg/Wayland applications.
As an example, here's how you might add keychain to your .bashrc file:
# Only run keychain if this isn't an SSH login.
# SSH client should use SSH agent forwarding from the original host (ssh -A) to make their keys available to use on the login host, if needed.
if [ -z "$SSH_CONNECTION" ]; then
# Here we're adding they keys ~/.ssh/id_rsa and ~/.ssh/id_ed25519 into our agent right off the bat.
# Upon login to the shell, we'll be prompted for appropriate password(s), if applicable.
eval "$(keychain --quick --systemd --eval id_rsa id_ed25519)"
fi
Important
It is strongly recommended that you back up your private key to a secure location, then delete it from the local system, after adding it to ssh-agent. The private key cannot be retrieved from the agent providing a strong algorithm has been used, such as ed25519 in this example. If you lose access to the private key, you will have to create a new key pair and update the public key on all systems you interact with.
GUI Access
GUI access via X2Go
Graphical applications can be run by tunnelling X11 over an ssh connection. However, this does not work particularly well on low-bandwidth or high latency connections because X11 creates many round-trips which adds significantly to the rendering delay. A superior approach is the NX protocol developed by nomachine.com . It is available on the trcomp nodes via X2Go. It can be used for a single-application or a full remote-desktop connection. Connections use the built-in ssh client of the X2Go client. ssh-key authentication can be used making single-click passwordless connections possible.
Download and install the X2Go client for your platform.
Configuring X2Go for connecting to a trcomp node
Create a session for the trcomp node that you want to use.
Navigate to Session --> New Session (or) Ctrl+N
- Session name: Name of the session ( Will be used for connection)
- Host: hostname of the remote host.
- Login: username to use for the login.
- SSH Port: 22 (default)
- RSA/DSA Key: path to your private key.
In the Media tab of session preferences, disable sound-support.
Note : You will be prompted to enter your passphrase to decrypt your key.
If you wish to access:
Remote-Desktop style connections
Session Type: XFCE
Over low bandwidth connections, XFCE is the preferred desktop-manager because it is simple and lightweight. Neither GNOME nor KDE are installed on the trcomp nodes.
Single-Application
Session Type: single-application
You can use this to open a single terminal from which you can launch other windows. Choose application "Terminal".
Connecting to a session
After saving the configuration, enter the session name you have configured in the previous step to be connected to the remote host.
References: