Using ssh keys

Basic description on how to use ssh keys

Create a ssh key

Access to the INCD computing clusters is performed via SSH and requires the use of SSH keys for authentication. Authentication with passwords is not supported. Each SSH key pair has two components a public key that must be added to the hosts to be remotely accessed, and a private key that must remain in the user workstation or laptop machine. The private key must be protected with a strong password. The users must generate their own SSH key pair in a machine of their own (workstation, laptop, etc). To generate your SSH key pair follow these instructions.

Linux and macOS

$ ssh-keygen -b 4096 -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/username/.ssh/id_rsa): 
Created directory '/home/username/.ssh'.
Enter passphrase (empty for no passphrase):           ----> IMPORTANT: Choose a strong password 
Enter same passphrase again:                          ----> IMPORTANT: Choose a strong password
Your identification has been saved in /home/username/.ssh/id_rsa.
Your public key has been saved in /home/username/.ssh/
ls -la $HOME/.ssh/
total 8
drwx------ 3 username group 4096 Jan 11 18:12 .
-rw------- 1 username group 1743 Feb 19 10:52 id_rsa
-rw-r--r-- 1 username group  404 Feb 19 10:52
chmod 700 .ssh 
chmod 644 
chmod 600 id_rsa

Microsoft Windows

Login does not work


WARNING: Incorrectly configuring SSH keys can leave your accounts vulnerable to attack and, more importantly, can provide attackers with a trivial means to access remote systems with potential legal consequences for yourself. It is your responsability to keep your SSH authentication and your user account secure.

Configuring SSH

In order to simplify SSH access to remote hosts we recommend INCD users to adopt the following recommendatios and configuration defaults.

Enabling SSH agents and X11 forwarding

Activate the forwarding of both SSH authentication credentials and X11 graphical windows. This will facilitate your SSH access by enabling:

Notice that these are two independent features unrelated to each other, you can activate one or both. If you do not require the forwarding of graphical X11 windows you can skip it. Similarly if you do not plan to access other hosts behind the login host or if you do not trust the remote host you should skip the forwarding of SSH credentials (ForwardAgent).

To activate both options the following configuration steps should be performed in the local workstation (PC or laptop desktop) from which the remote INCD hosts will be accessed.

Alternatively the same SSH forwarding options can be activated from the command line for each connection by invoking SSH with the corresponding flags -A -X and -Y:

  ssh -A -X -Y  remote-hostname

More information about SSH and port forwarding can be found in:

Using SSH tunnels

In some cases you may need to access remote hosts that have private IP addresses or are protected behind a firewall. These hosts might be only accessible through an intermediate login host. The SSH tunnels (SSH port forwarding) facilitate access to multiple hosts protected behind a single public host exposed to the Internet. Once the tunnels are established the hosts behind the firewall can be directly accessed from your machine. Examples where tunnels can be beneficial:

In the following examples the hostnames and as well as the port numbers are placeholders that should be replaced by actual real hostnames and port numbers according to your scenario.

jump over SSH hosts easily from the command line

Basic jump host syntax:

ssh -J username@public-remote-host   username@internal-remote-host

Example of using the SSH jump host functionality to access the SSH port (port number 22) of the remote host through a publicly reachable host Most of the examples in this page are valid both for ssh and its related commands such as scp and sftp.

ssh -J
scp -J  mylocalfile
sftp -J

ssh -J

forwarding of X11 windows

port forwarding from local to remote in detail

Basic port forwarding syntax:

ssh -L local-port:internal-remote-host:internal-remote-port   public-remote-host

Example of establishing a tunnel to access the SSH port (port number 22) of the remote host through a publicly reachable host We pick a random local-port (e.g. 31732) that is then mapped to the port 22 of

ssh -L

Once the SSH connection to is established the host can be directly accessed from your local host by connecting to the local-port on the loopback address. Just create a second command line terminal and try:

ssh -p 31732 username@
scp -P 31732 mylocalfile  username@
sftp -P 31732

Once the SSH connection to the intermediate host is closed the tunnels will stop working. Therefore the initial SSH connection must be kept alive while needed and the connections to the remote internals hosts must be performed from a separate local terminal window.

Another example where both port 22 (SSH) and port 80 (HTTP) are both mapped to local ports. With this both ports are forwarded over a single SSH connection. The access to the web server from the local host can be tested using curl.

ssh -L -L


port forwarding from remote to local in detail

Basic remote port forwarding syntax:

ssh -R remote-port-on-public-host:local-host:local-port   public-remote-host

Example of forwarding the remote-port number 65532 on to the port 22 of the local host named myotherlocalhost.

ssh -R 65532:myotherlocalhost:22

Then from you can access myotherlocalhost in your local network with:

ssh -p 65532

jump host via config file

The basic configuration for remote access via a jump host

Host name-for-the-internal-remote-host
Hostname actual-internal-remote-host
User username-in-actual-internal-remote-host
ProxyJump username@public-remote-host
HostKeyAlias name-for-the-internal-remote-host

Example of configuration:

Host ncg-internal
User username-for-internal
HostKeyAlias ncg-internal

Accessing the configured host:

ssh ncg-internal

port forwarding via config file

The basic configuration for port forwarding:

Host public-remote-host
LogLevel FATAL
LocalForward local-port internal-remote-host:internal-remote-port

Host name-for-the-internal-remote-host
User username
Port local-port
HostKeyAlias name-for-the-internal-remote-host

Example of port forwarding for both SSH (port 22) and HTTP (port 80):

LogLevel FATAL
LocalForward 31732
LocalForward 8080

Host ncg-internal
User username
Port 31732
HostKeyAlias ncg-internal

Accessing the configured host

ssh ncg-internal

(*) notice that you cannot use the hostname ncg-internal with curl as this is a hostname that is only recognized by SSH related applications (ssh, scp, sftp).

using socks proxies

The basic command line usage to establish a socks server via SSH:

ssh -D local-port  username@public-remote-host

The basic $HOME/.ssh/config setup to establish a socks server:

Host public-remote-host
DynamicForward local-port
User username

Example of socks proxy use with Firefox:

ssh -D 31733

Then in firefox:

  1. Goto Preferences->Network Settings:
  2. Select Manual proxy configuration
  3. Enter in SOCKS Host:
  4. Enter in Port: 31733
  5. If needed add local networks to be excluded from the proxy using No proxy for
  6. If needed add the options related to DNS proxying

(*) notice that all your http request will now be forwarded through the socks proxy, to restore the previous settings choose No proxy in the Preferences->Network Settings.

(*) as in the other examples the TCP port number to be allocated might need to be adjusted to match a free port number in your local machine (desktop, laptop, etc).

using sshuttle

The tool sshuttle is available in many Linux distributions. It uses SSH in combination with iptables and other functionalities to easily establish tunnels with better performance and a behavior more similar to a VPN. Instead of establishing a direct end-to-end TCP connection to the remote internal hosts, sshutle intercepts local packets, sends their payload over SSH and establishes connections from the remote public host to the internal hosts. This prevents some of the performance issues associated with TCP end-to-end connections through SSH inner tunnels and also enables other capabilities such as accessing more transparently hosts and services behind the firewall.


Template for the sshutle configuration file:

internal-remote-host-01,internal-remote-host-02, ...

Example that needs to be adjusted to your actual needs:

Invoking sshutle from the command line:

sshuttle @$HOME/.ssh/sshutle-ncg.conf

Then you can ssh into the hosts directly:


If the remote internal host has other services running such as a web server they will be also accessible:


Enable access to a remote host

In most cases you will not need to add your own SSH public key to other INCD remote hosts as there are other processes to do so, namelly: