Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
doku:vpn_ssh_access [2016/06/21 09:21]
ir [Using SSH keys and SSH agent to connect to VSC]
doku:vpn_ssh_access [2024/02/16 11:39] (current)
mpfister Jump host in ssh configuration file
Line 8: Line 8:
 Common ways of connecting are either the use of a VPN or a SSH gateway provided by the university. Common ways of connecting are either the use of a VPN or a SSH gateway provided by the university.
  
-See also [[doku:vsc3quickstart|Login]], and  [[doku:win2vsc|Connecting from windows]].+See also [[pandoc:introduction-to-vsc:02_connecting_to_vsc:connecting_to_vsc|Login and data transfer]], and  [[doku:win2vsc|Connecting from windows]].
  
 === VPN services === === VPN services ===
-  * University of Vienna: [[http://zid.univie.ac.at/en/services/services-from-a-z/v/vpn-virtual-private-network|English]] [[http://zid.univie.ac.at/vpn/|German]] +  * University of Vienna: [[http://zid.univie.ac.at/en/vpn|English]] [[http://zid.univie.ac.at/vpn/|German]] 
-  * TU Vienna: [[http://www.zid.tuwien.ac.at/en/tunet_the_network_of_the_tu_vienna/vpn/remote_access/|English]] [[http://www.zid.tuwien.ac.at/tunet/vpn/|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 Innsbruck: [[http://www.uibk.ac.at/zid/netz-komm/vpn/|German]]
-  * University of Graz: [[http://it.uni-graz.at/de/fernzugriff/login-datenzugriff/vpn/|German]] +  * University of Graz: [[https://it.uni-graz.at/de/services/zugang-zum-uninetz/vpn/|German]] 
-  * TU Graz: [[https://sso.tugraz.at/idp/Authn/GenericAuthn| Web Single Sign-On]]+  * TU Graz: [[http://portal.tugraz.at/portal/page/portal/zid/netzwerk/zugang/vpn| Web Single Sign-On]]
  
  
 === SSH Gateway === === 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 ====+====== Using SSH keys and SSH agent to connect to VSC ======
  
-  * Check permissions of your local .ssh directory:<code>+==== Check permissions of your local .ssh directory:==== 
 +<code>
 user@host:~$ ls -dl ~/.ssh user@host:~$ ls -dl ~/.ssh
 drwx------ 4 user user 4096 Dec  6 09:20 /home/user/.ssh</code>This directory should only be accessible for your user. If permissions are not as in the above example set them with:<code> drwx------ 4 user user 4096 Dec  6 09:20 /home/user/.ssh</code>This directory should only be accessible for your user. If permissions are not as in the above example set them with:<code>
Line 31: Line 31:
 </code> </code>
  
-  * Generate ssh-keyssh passphrase should be as strong as your password!:<code>+==== Generate ssh-key ==== 
 +ssh passphrase should be as strong as your password!:<code>
 user@host:~$ ssh-keygen -t rsa user@host:~$ ssh-keygen -t rsa
 </code>If default options are used, the private and public key are saved into your $HOME/.ssh directory. 'id_rsa' is the private key file, this should not be lost or given to any other person. 'id_rsa.pub' is the public key file which is used for authenticating on remote machines. Again, check if the permissions of the generated files are correct. By default they should look like this:<code> </code>If default options are used, the private and public key are saved into your $HOME/.ssh directory. 'id_rsa' is the private key file, this should not be lost or given to any other person. 'id_rsa.pub' is the public key file which is used for authenticating on remote machines. Again, check if the permissions of the generated files are correct. By default they should look like this:<code>
Line 38: Line 39:
 -rw-r--r-- 1 user user  394 Dec  6 09:15 /home/user/.ssh/id_rsa.pub -rw-r--r-- 1 user user  394 Dec  6 09:15 /home/user/.ssh/id_rsa.pub
 </code> </code>
 +See also [[doku:sshkeygen|sshkeygen]]. 
 +==== remote machine ====
   * Preparing the remote machine for logging in with your key: On the remote machine the contents of your 'id_rsa.pub' file have to be added to the 'authorized_keys' file in the '.ssh' directory. Login to the remote machine and use a text editor of your choice to do this. Afterwards check if the permissions of the 'authorized_keys' file are correct:<code>   * Preparing the remote machine for logging in with your key: On the remote machine the contents of your 'id_rsa.pub' file have to be added to the 'authorized_keys' file in the '.ssh' directory. Login to the remote machine and use a text editor of your choice to do this. Afterwards check if the permissions of the 'authorized_keys' file are correct:<code>
 user@remote_host:~$ ls -l .ssh/authorized_keys user@remote_host:~$ ls -l .ssh/authorized_keys
Line 44: Line 46:
 </code>Alternatively you can copy the key via the ''ssh-copy-id'' command:<code>user@remote_host:~$ ssh-copy-id <username>@vsc3.vsc.ac.at</code> </code>Alternatively you can copy the key via the ''ssh-copy-id'' command:<code>user@remote_host:~$ ssh-copy-id <username>@vsc3.vsc.ac.at</code>
  
-  * Logging in with ssh-keys: For using the ssh-keys, they must be added to the so-called ssh-agent. Most window managers have a ssh-agent running by default and if a connection with an applicable key is opened you are asked to enter the passphrase. The ssh-agent will then store the passphrase and reuse it for further connection attempts with this private/public key pair.+  * Logging in with ssh-keys: For using the ssh-keys,  
 +    * they may be added to the so-called ssh-agent. Most window managers have a ssh-agent running by default and if a connection with an applicable key is opened you are asked to enter the passphrase. The ssh-agent will then store the passphrase and reuse it for further connection attempts with this private/public key pair.  
 +    * Alternatively, the ssh-key may be given as parameter (-i) or  
 +    * written to ''~/.ssh/config'' (see below). 
 + 
 +==== Connecting to VSC-4 or VSC-5 via ssh-key: ==== 
 +<code> 
 +ssh -p 27 <username>@vsc4.vsc.ac.at     # or  
 +ssh -p 27 <username>@vsc5.vsc.ac.at 
 +</code> 
 + 
 +=== Using a jump host === 
 +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 -t -J <uni_username>@login.univie.ac.at <vsc_username>@vsc5.vsc.ac.at 
 +</code> 
 + 
 +==== Parameters in .ssh/config ==== 
 + 
 +Parameters may be written, e.g. on a per-host basis, to ''~/.ssh/config'' of the local machine (see also ''man ssh_config'' (agent and X11 forwarding may be enabled if permanently required): 
 + 
 +<code> 
 +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:
  
-  * Connecting to **VSC-2** or **VSC-3** via ssh-key: ''ssh -p 27 <username>@vsc2.vsc.ac.at'' or ''ssh -p 27 <username>@vsc3.vsc.ac.at'', respectively.+<code> 
 +Host vsc5.vsc.ac.at vsc5 
 +  User vsc_username 
 +  ProxyJump login.univie.ac.at
  
-  * Forwarding the ssh-agent over multiple servers: 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 :<code> +Host login.univie.ac.at 
-user@host:~$ ssh -X -A -t <uni_username>@login.univie.ac.at ssh -X <vsc_username>@vsc3.vsc.ac.at +  User uni_username
-</code> To issue the parameter '-A' for certain hosts, an entry in ''.ssh/config'' (see also ''man ssh_config'') could look like:<code> +
-Host vsc2.univie.ac.at +
-  ForwardAgent yes+
 </code> </code>
  
-  * Security issues+===== Security issues =====
     * 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.     * 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.     * 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 ''man sshd'').
  • doku/vpn_ssh_access.1466500901.txt.gz
  • Last modified: 2016/06/21 09:21
  • by ir