Differences

This shows you the differences between two versions of the page.

--- doku:vpn_ssh_access [2021/09/29 09:21] – [Access to VSC] goldenberg
+++ doku:vpn_ssh_access [2024/05/02 09:54] (current) – [Security issues] adding link to man sshd jz
@@ Line 12: / Line 12: @@
 === VPN services ===
   * University of Vienna: [[http://zid.univie.ac.at/en/vpn|English]] [[http://zid.univie.ac.at/vpn/|German]]
-  * TU Vienna: [[https://www.it.tuwien.ac.at/en/services/network-infrastructure-and-server-services/tunet/vpn-virtual-private-network/vpn-access|English]] [[https://www.it.tuwien.ac.at/services/netzwerkinfrastruktur-und-serverdienste/tunet/vpn-virtual-private-network/vpn-zugang|German]]
+  * TU Vienna: [[https://www.it.tuwien.ac.at/en/services/network-and-servers/tuvpn|English]] [[https://www.it.tuwien.ac.at/services/netzwerk-und-server/tuvpn|German]]
   * University of Innsbruck: [[http://www.uibk.ac.at/zid/netz-komm/vpn/|German]]
   * University of Graz: [[https://it.uni-graz.at/de/services/zugang-zum-uninetz/vpn/|German]]
@@ Line 20: / Line 20: @@
 === SSH Gateway ===
-Users can connect first to any linux machine within a university and then connect further to VSC. Some universities provide a dedicated SSH gateway (contact your local IT services if you don't know how to connect):
+Users can connect first to any linux machine within a university and then connect further to VSC. Some universities provide a dedicated SSH gateway (contact your local IT services if you don't know how to connect).
-  * TU Graz: [[https://sso.tugraz.at/idp/Authn/GenericAuthn|SSH gateway]]
 ====== Using SSH keys and SSH agent to connect to VSC ======
@@ Line 52: / Line 51: @@
     * written to ''~/.ssh/config'' (see below).
-==== Connecting to VSC-3 or VSC-4 via ssh-key: ====
+==== Connecting to VSC-4 or VSC-5 via ssh-key: ====
 <code>
-ssh -p 27 <username>@vsc3.vsc.ac.at     # or
+ssh -p 27 <username>@vsc4.vsc.ac.at     # or
-ssh -p 27 <username>@vsc4.vsc.ac.at
+ssh -p 27 <username>@vsc5.vsc.ac.at
 </code>
-=== Forwarding the ssh-agent over multiple servers ===
+=== Using a jump host ===
-If the machine to which one wants to login is reachable only over one or several hops in between, the ssh-agent of the local machine can be forwarded to the machines in between using the '-A' option of the 'ssh' command. Prerequisite is that on all remote hosts the public key has been added to the 'authorized_keys' file as described above. For example, a connection to VSC-3 over the 'login.univie.ac.at' machine would look like this :
+It is also possible to use SSH keys if the machine to which one wants to login is reachable only over one or several hops in between. To do this, use the command ''-J'' to specify the jump host. Prerequisite is that on all remote hosts the public key has been added to the ''authorized_keys'' file as described above. For example, a connection to VSC-5 over the ''login.univie.ac.at'' machine would look like this :
 <code>
-user@host:~$ ssh -p27 -X -A -t <uni_username>@login.univie.ac.at ssh -p27 -X <vsc_username>@vsc3.vsc.ac.at
+user@host:~$ ssh -p27 -X -t -J <uni_username>@login.univie.ac.at <vsc_username>@vsc5.vsc.ac.at
 </code>
@@ Line 69: / Line 68: @@
 <code>
-Host vsc3.vsc.ac.at vsc3
+Host vsc5.vsc.ac.at vsc5
   Port 27
+  User vsc_username
 #  ForwardAgent yes
   IdentityFile id_rsa
   IdentitiesOnly yes
 #  ForwardX11 yes
+</code>
+=== Using a jump host ===
+A configuration for automatically using a jump host could look like this:
+<code>
+Host vsc5.vsc.ac.at vsc5
+  User vsc_username
+  ProxyJump login.univie.ac.at
+Host login.univie.ac.at
+  User uni_username
 </code>
@@ Line 80: / Line 92: @@
     * In theory it would be possible to create an ssh key without passphrase. However, the possession of this key would allow anyone from anywhere to open a connection.
     * Forwarding the ssh key as a standard procedure, e.g. by aliasing the 'ssh' command is not recommended, especially if you connect also to servers which are not perfectly reliable. An attacker with administrator access (using zero-day exploits?) could misuse the forwarded keys.
-    * One of the worst security issues concerning ssh keys would be to create a passphrase-less ssh-key and copy the public key directly to the 'authorized_keys'-file on the same server. This might seem useful if several servers share nfs mounted home directories. However, as stated above, anyone who ever had read access to this account could access forever from anywhere again! If ever necessary, this has to be combined with host access restrictions, e.g. in ''.ssh/authorized_keys'': ''from="*.trusted.host.example.com"'' (see ''man sshd'').
+    * One of the worst security issues concerning ssh keys would be to create a passphrase-less ssh-key and copy the public key directly to the 'authorized_keys'-file on the same server. This might seem useful if several servers share nfs mounted home directories. However, as stated above, anyone who ever had read access to this account could access forever from anywhere again! If ever necessary, this has to be combined with host access restrictions, e.g. in ''.ssh/authorized_keys'': ''from="*.trusted.host.example.com"'' (see [[https://www.linux.org/docs/man8/sshd.html|man sshd]]).