Changes to SSH access into PSI-LAN

Current SSH connections from the internet to systems within the internal PSI network are carried out directly, without an intermediary "jumpsystem". This method introduces considerable disadvantages to IT Security at PSI.

The fact that internal PSI systems are more-or-less directly accessible from the internet via SSH, leads to published system address information, which is readable by anyone on the internet. Since the PSI-internal addressing of the systems is dynamic, and each potentially-reachable systems address can change as and when, the entire database of address information of PSI has to be published.

This also leads to the added disadvantage that address information of purely internally-used infrastructure must be made public, which ultimately presents a major loophole in the level of IT Security.

For this reason, PSI has decided that future incoming SSH connections to systems within the PSI network will only be permitted through a jumpsystem (hop.psi.ch). This system contains the necessary address information of internal systems, which precludes the need to publish internal address information to the internet

To smooth the transition, both the new and the old systems will be temporarily available in parallel. At a yet-to-be-announced point, the old system will be decommissioned.

PSI employees with an account can use the jump system by default. Non-PSI employees have to apply via their responsible contact person for an external-employee account.

SSH with Unix

There are several methods for SSH connections using Unix systems.

Method 1
For every SSH connection into the PSI-LAN, an initial SSH connection to hop.psi.ch must be made. From there, you make a new SSH connection to the target system within the PSI-LAN. This could be referred to as an "interactive" session.

ssh-manuell.png

Example for the connection establishment:
Please replace the <user> with your actual username.

ssh to hop.psi.ch
$ ssh <user>@hop.psi.ch  
$ <user>@hop.psi.ch's password:
and next to the system within the PSI-LAN
$ ssh <user>@sshserver.psi.ch  
$ <user>@sshserver.psi.ch's password:
Alternative command:
$ ssh -t <user>@hop.psi.ch ssh -t <user>@sshserver.psi.ch
<user>@hop.psi.ch's password: 
<user>@sshserver.psi.ch's password:
[<user>@sshserver ~]$  
Method 2
For those who wish to make multiple SSH connections to different systems within the PSI-LAN, this method is most appropriate. ssh-only.png

All SSH connections to the PSI-LAN go through a SSH tunnel to hop.psi.ch. For this method, you have to make some adjustments to the client system.

First ensure the ~/.ssh/config file exists, and has octal 600 permissions.
mkdir ~/.ssh/tmp
touch ~/.ssh/config
chmod 600 ~/.ssh/config


adjust the ssh ~/.ssh/config as follows:

ControlMaster auto 
ControlPath   /home/<user>/.ssh/tmp/%h_%p_%r
Protocol 2

# The following can also be specified in the host-based sections below.
ForwardX11 yes 
ForwardX11Trusted yes
ForwardAgent yes 

host hop hop.psi.ch
     hostname hop.psi.ch
     user <PSI-user>

host sshsrv1-psi-internal
     hostname sshserver1.psi.ch
     user <user>
     ProxyCommand ssh -A -W %h:%p hop.psi.ch

host sshsrv2-psi-internal
     hostname sshserver2.psi.ch
     user <user>
     ProxyCommand ssh -A -W %h:%p hop.psi.ch

host sshsrv3-psi-internal
     hostname sshserver3.psi.ch
     user <user>
     ProxyCommand ssh -A -W %h:%p hop.psi.ch
The connection to internal systems is made via two steps.

Step no. 1, ssh to hop.psi.ch
$ ssh <user>@hop.psi.ch  
$ <user>@hop.psi.ch's password:
This connection establishes the tunnel to hop.psi.ch and must be left open during the entire lifetime of the connection(s) to system(s) within the PSI-LAN!

Step no. 2, ssh to the systems in the PSI-LAN
$ ssh sshsrv1-psi-internal  
$ <user>@sshserver1.psi.ch's password:

$ ssh sshsrv2-psi-internal  
$ <user>@sshserver2.psi.ch's password:

$ ssh sshsrv2-psi-internal  
$ <user>@sshserver3.psi.ch's password:
All three connections will be sent through the tunnel to hop.psi.ch, and from there to the destination systems.

SSH with Windows and PuTTY

SSH connections from windows systems are only possible using method 1, as described above. Again here, an initial connection to hop.psi.ch must be established. Putty allows us to set this up with little effort.

Example: ssh login to llc.psi.ch

Fill in the field Host Name (or IP address) the name of the jumpsystem hop.psi.ch. In the Field Saved Sessions type in a description of the connection. For example llc.psi.ch via hop.psi.ch.

screen1.PNG

Then choose Category SSH in the left column. Type in the command ssh llc.psi.ch into the field Remote command.

screen2.PNG

Go back to Category Session and save the settings with a click to save.

screen3.PNG

To make the connection, you have to click Open. Please replace the <user> with your actual username. The password for the useraccount will be requested twice. Once for the login to hop.psi.ch

screen7.PNG

..and afterwards for the login to llc.psi.ch.

screen4.PNG

After you have entered the passwords successfully, you have access to llc.psi.ch

screen5.PNG

Upon logout from llc.psi.ch, both connections (to hop.psi.ch and llc.psi.ch) will be closed.

Tunnelling

With the help of SSH tunnelling, internal services (remote desktop, vnc, smb etc.) are usable through the jumpsystem hop.psi.ch. It should be noted, that not all users of the jumpsystem get the same connection privileges: depending on the type of user account you possess, varying degrees of reachability will be available.

PSI employee
PSI employees can tunnel the following TCP connections through hop.psi.ch into the PSI-LAN:
TCP Port Number used for
22 ssh
80/443 http(s)
445 CIFS Windows file server (e.g. fs00, fs01 or fs02)
>1023 e.g. for rdp, vnc etc.
External Users
External users can tunnel the following TCP connections through hop.psi.ch into the PSI-LAN:
TCP Port Number used for
22 ssh
3389 rdp
5900 vnc
Additional connections can be allowed upon request.

Tunnelling with Windows

Tunnelling in Windows works via PuTTY. Fill in the field Host Name (or IP address) the name of the jumpsystem hop.psi.ch. In the Field Saved Sessions type in a description of the connection. For example hop-tunnel.

screen11.PNG

Then choose Category SSH in the left column. Fill in the field Source port e. g. a local port 9000 and in the field Destination the destination system with its port. In this case winterm1:3389, for a remote desktop connection to winterm1.psi.ch. Then click Add to add the tunnelling information to the configuration.

screen9.PNG

Go back to Category Session and save the settings with a click to save. After the SSH connection to hop.psi.ch is established, start your locally-installed remote desktop client and connect to localhost:9000.

screen12.PNG

The RDP connection will be sent through the ssh tunnel to hop.psi.ch, and from there to winterm1.psi.ch in the PSI-LAN.

Tunnelling in Unix

There are several method for tunnelling using Unix systems too.

Method 1, command line
ssh -L 9000:winterm1.psi.ch:3389 <user>@hop.psi.ch
$ <user>@hop.psi.ch's password:
After successful login to hop.psi.ch, port 9000 will be listening on the local client system. If you connect with a locally-installed remote desktop client to port 9000, the connection will be sent through the tunnel via hop.psi.ch to winterm1.psi.ch. E. g. with
$ rdesktop localhost:9000
Method 2, adjust the .ssh/config
For those who wish to make multiple protocol connections (RDP, CIFS, etc) to different systems within the PSI-LAN, this method is most appropriate.

ssh-tunnel.png adjust the ssh client configuration (see above):
~/.ssh/config

ControlMaster auto 
ControlPath   /home/<user>/.ssh/tmp/%h_%p_%r
Protocol 2

# The following can also be specified in the host-based sections below.
ForwardX11 yes 
ForwardX11Trusted yes 
ForwardAgent yes 

host hop.psi.ch
     hostname hop.psi.ch
     user <PSI-user>
     # Forward RDP to winterm1.psi.ch
     LocalForward 9000 winterm1.psi.ch:3389
     # Forward RDP to pc8699.psi.ch
     LocalForward 9001 pc8699.psi.ch:3389
     # Forward SMB to Fileserver fsX.psi.ch
     LocalForward 9445 fsX.psi.ch
...
Once the connection to hop.psi.ch is established, the local tunnelling ports 9000, 9001 and 9445 will be available for the configured connections.

Dynamic tunnelling

The jumpsystem hop.psi.ch can also be used as socks5 proxy for dynamic tunnelling. This allows, for example, multiplexing several connections to different internal webservers, without the need of a separate tunnel to each webserver.

Example with windows

With PuTTy you can add the settings for dynamic tunnelling to the already-defined connection profile hop.psi.ch. Choose in the left column Category SSH -> Tunnels. Fill in the field Source port e. g. a local Port 9999, leave the field Destination blank, and activate the Option Dynamic. Click Add to confirm the settings.

screen14.PNG

Don`t forget to save the connection profile. After successful login to hop.psi.ch, port 9999 will be listening on the local client system. Now you can change the proxy settings of the firefox browser and set SOCKS Host: localhost Port: 9999. It is recommended to fill in the field No Proxy for: every domainname, which should be contacted directly without sending the requests over hop.psi.ch, e. g. localhost, 127.0.0.1, .ethz.ch, =.com=

Attention: Using hop.psi.ch you can only connect to PSIs internal websites. Connections to websites outside the PSI address range won`t be forwarded!! screen13.PNG Tip If you use a laptop and would like to keep your browser configuration to access internal websites from outside PSI, it is recommended to use two different browsers. One for the access through hop.psi.ch with its socks5 configuration, and one for pure internal connections within the PSI-LAN without a connection through hop.psi.ch.

Example with Unix

Method 1, command line
ssh -D 9999 <user>@hop.psi.ch
$ <user>@hop.psi.ch's password:
After successful login to hop.psi.ch, port 9999 will be listening on the local client system. Now you can use this port as a socks5-proxy. Please have a look at the description for Windows systems above.

Method 2, adjust the .ssh/config
For the adjustment of the ssh configuration file you have to add the row
DynamicForward 9999 
SSH-client configuration file:
~/.ssh/config

ControlMaster auto 
ControlPath   /home/<user>/.ssh/tmp/%h_%p_%r
Protocol 2
 
# The following can also be specified in the host-based sections below.
ForwardX11 yes 
ForwardX11Trusted yes
ForwardAgent yes 

host hop.psi.ch
     hostname hop.psi.ch
     user <PSI-user>
     DynamicForward 9999
     # Forward RDP to winterm1.psi.ch
     LocalForward 9000 winterm1.psi.ch:3389
     # Forward RDP to pc8699.psi.ch
     LocalForward 9001 pc8699.psi.ch:3389
     # Forward SMB to Fileserver fsX.psi.ch
     LocalForward 9445 fsX.psi.ch
...
After successful login to hop.psi.ch, local port 9999 is ready to use for the dynamic tunnelling.

Hint for macOS/Mac OS X Users
If you would like to access internal PSI websites using the safari browser, you will have to setup the socks-proxy through the system wide network preferences. In the network preferences, choose the active network connection (WLAN, ethernet...) and open Advanced -> Proxies. Then set the Socks-Proxy Port to 9999.

macnetwork.png

Attention: These settings are globally active for any network-using application on the mac system. E. g. this means to the applications mail and calendar, too. Any connections from these applications will also be sent through the socks-proxy. This could lead to connection problems if an application tries to reach a server outside of PSI. To circumvent this behaviour, you will have to exempt from proxy-usage all connections to the external server with entries in the field Bypass proxy settings for these Hosts & Domains:.

Target Host Key Management

Occasionally, a target system within PSI will alert the user that the SSH host key has changed. The warning assumes this is malicious:
[user@hop ~]$ ssh user@targethost
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
6e:45:f9:d8:af:33:3d:a1:a5:c7:76:1d:02:f8:77:00.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/user/known_hosts:4
RSA host key for targethost has changed and you have requested strict checking.
Host key verification failed.
What this warning usually means (in lieu of 'targetsystem' really having been compromised) is that targetsystem's ssh host key has changed for one of the following reasons:
  1. The system was re-installed (thus sshd had a new host key generated to work with)
  2. The administrator of the system has intentionally re-generated the ssh host key
In both cases, the new host key will need to be accepted by the user. A tool is provided to do just this called kd, which stands for "key delete".
[user@hop]$ kd
usage: kd [host or IP]
   This program will delete a host key from your ~/.ssh/known_hosts.
   You should use this program when a destination host has been rebuilt,
   or the host SSH key on that system has been regenerated.
   Example usage:

     [user@hop]$ kd mybox
     # Host mybox found: line 2 type ECDSA
     /home/user/.ssh/known_hosts updated.
     Original contents retained as /home/user/.ssh/known_hosts.old
     [user@hop]$

   *NOTE* You are required to accept the host's SSH key again on the next connection!
   Please bear this in mind when executing your next tunnel to the destination host!

[user@hop]$ 


One invokes kd as follows, giving the hostname or IP address:

1 Delete the host key
[user@hop]$ kd targethost
# Host targethost found: line 4
/home/user/.ssh/known_hosts updated.
Original contents retained as /home/user/.ssh/known_hosts.old
2 Reconnect to the host to accept new key
[user@hop]$ ssh targethost
The authenticity of host 'targethost (129.129.123.123)' can't be established.
ECDSA key fingerprint is f5:64:8e:a4:f1:6f:dc:c3:57:01:e6:e8:ec:ae:95:ff.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'targethost,129.129.123.123' (ECDSA) to the list of known hosts.
user@targethost's password: 
[user@hop]$