- Infos im HLRS Wiki sind nicht rechtsverbindlich und ohne Gewähr -
- Information contained in the HLRS Wiki is not legally binding and HLRS is not responsible for any damages that might result from its use -
Secure Shell ssh: Difference between revisions
m (ssh from login nodes to your allocated nodes of your job) |
|||
(97 intermediate revisions by 13 users not shown) | |||
Line 2: | Line 2: | ||
Secure shell is the exclusive way to get into the secure environment of the HWW machines. Commands like telnet, ftp as well as the r-cmds are '''NOT allowed''' and therefore are rejected by the firewall.<BR> | Secure shell is the exclusive way to get into the secure environment of the HWW machines. Commands like telnet, ftp as well as the r-cmds are '''NOT allowed''' and therefore are rejected by the firewall.<BR> | ||
{{Warning | |||
| text = Access to HWW platforms via ssh will definitely be restricted to ssh V2 ONLY! | |||
}} | |||
On HWW platforms the ssh software is installed. The user is responsible for installation of ssh on his platform.<BR> | On HWW platforms the ssh software is installed. The user is responsible for installation of ssh on his platform.<BR> | ||
Line 10: | Line 13: | ||
For details on the licensing see the external link [http://www.openssh.org/ HOME page of OpenSSH]<BR> | For details on the licensing see the external link [http://www.openssh.org/ HOME page of OpenSSH]<BR> | ||
Please read first the files README and INSTALL.<BR> | |||
Please be aware to run the latest version of ssh client software. Most operating systems provide installable packages and update mechanism. | |||
== Tips and hints == | == Tips and hints == | ||
Line 30: | Line 21: | ||
=== if you can't get a connection === | === if you can't get a connection === | ||
this may have 3 causes: | this may have 3 causes: | ||
# Your workstation is not known by the firewall. Please | # Your workstation is not known and blocked by the firewall. Please contact Your HLRS contact person (adviser/Betreuer), or submit a bug-report to accounting via the [http://www.hlrs.de/trouble-ticket-submission-form/ Trouble Ticket Submission Form] providing Your username and the static IP Address You want to access from ([https://websrv.hlrs.de/ipinfo your external IP address]). | ||
# The HWW platform, you're trying to connect to, is currently not running. Please check the appropriate | # The HWW platform, you're trying to connect to, is currently not running. Please check the appropriate [http://www.hlrs.de/systems/platforms/status/ status] page for your platform. | ||
# Your ssh client is setuid root. Please remove setuid root bit or use -P (for ssh) resp. -L option (for scp). | # Your ssh client is setuid root. Please remove setuid root bit or use -P (for ssh) resp. -L option (for scp). | ||
If you encounter any problems while connecting with ssh, please use -v option to get more detailed messages from ssh. | If you encounter any problems while connecting with ssh, please use -v option to get more detailed messages from ssh. | ||
=== | === ssh and scp filetransfer without password (using protocol version 2) === | ||
Login via ssh resp. Filetransfer via scp is also possible without having to enter a password. Authentification is done via a public/private key pair. The following steps have to be accomplished: <BR> | Login via ssh resp. Filetransfer via scp is also possible without having to enter a password. Authentification is done via a public/private key pair. The following steps have to be accomplished: <BR> | ||
(<tt>system1</tt> is the machine from which you logon to the target system <tt>system2</tt>) | (<tt>system1</tt> is the machine from which you logon to the target system <tt>system2</tt>) | ||
System1 > ssh-keygen | System1 > ssh-keygen | ||
Generating public/private | Generating public/private rsa key pair. | ||
Enter file in which to save the key ($HOME/.ssh/ | Enter file in which to save the key ($HOME/.ssh/id_rsa): <RETURN> | ||
Enter passphrase (empty for no passphrase): <RETURN> | Enter passphrase (empty for no passphrase): <RETURN> | ||
Enter same passphrase again: <RETURN> | Enter same passphrase again: <RETURN> | ||
Your identification has been saved in $HOME/.ssh/ | Your identification has been saved in $HOME/.ssh/id_rsa. | ||
Your public key has been saved in $HOME/.ssh/ | Your public key has been saved in $HOME/.ssh/id_rsa.pub. | ||
The key fingerprint is: | The key fingerprint is: | ||
2f:5c:18:e7:g0:3b:fb:52:g3:22:1d:3d:a4:cf:b1:57 $LOGNAME@$HOSTNAME | 2f:5c:18:e7:g0:3b:fb:52:g3:22:1d:3d:a4:cf:b1:57 $LOGNAME@$HOSTNAME | ||
System1 > chmod 700 $HOME/.ssh | |||
System1 > chmod 600 $HOME/.ssh/id_rsa | |||
System1 > cd $HOME/.ssh | System1 > cd $HOME/.ssh | ||
System1 > scp | System1 > scp id_rsa.pub System2:sys1.pub | ||
System2 > cd $HOME/.ssh | System2 > cd $HOME/.ssh | ||
System2 > cat $HOME/sys1.pub >> | System2 > cat $HOME/sys1.pub >> authorized_keys | ||
System2 > chmod 700 $HOME/.ssh | System2 > chmod 700 $HOME/.ssh | ||
There's also a command automizing the last steps: | |||
System1 > ssh-copy-id System2 | |||
The key generation with ssh-keygen has only to be done once. The public key in the file $HOME/.ssh/identity.pub can be used for as many systems as needed. | The key generation with ssh-keygen has only to be done once. The public key in the file $HOME/.ssh/identity.pub can be used for as many systems as needed. | ||
Further information regarding ssh can be found at external link http://www.cs.hut.fi/ssh/ or at external link [http://www.f-secure.com/f-secure/fclintp.htm DATA FELLOWS - F-Secure SSH ] | Further information regarding ssh can be found at external link http://www.cs.hut.fi/ssh/ or at external link [http://www.f-secure.com/f-secure/fclintp.htm DATA FELLOWS - F-Secure SSH ] | ||
A good alternative for Windows platforms is external link [http://www.chiark.greenend.org.uk/~sgtatham/putty/ putty] | A good alternative for Windows platforms is external link [http://www.chiark.greenend.org.uk/~sgtatham/putty/ putty]. | ||
For file transfer [https://winscp.net WinSCP] is a powerful client. | |||
== ssh tunnel == | |||
Due to security policies inside the HWW network (all HWW platforms), general internet access is not possible. | |||
For example to get access to software repositories (svn servers, git servers, etc.), a ssh tunnel could be useful. | |||
<font color=red>'''W A R N I N G :''' | |||
If you create an ssh tunnel, any user on this system is able to access this port. Please be aware of sensitive data on your local network. E.g. if you create an ssh tunnel to your local private software repository, any users on the remote server has access to this port and is able to use this repository! | |||
</font> | |||
=== SVN === | |||
Please find the following example to get access to a svn repository. | |||
'''For Linux, Mac and Unix users:''' | |||
Assume the svn repository is: ''svn.mplayerhq.hu'' listening on port ''3690'' (default svn port) and your username on the HWW platform ''hermit1.hww.hlrs.de'' is ''hpchugo''. | |||
Then on your local workstation login and create the tunnel using following commands: | |||
ssh -R7777:svn.mplayerhq.hu:3690 hpchugo@hermit1.hww.hlrs.de | |||
You will be asked for your password on hermit1 and get a login session. | |||
The local port on hermit1 into the created tunnel in this example is 7777. Please select a different number in the range of 5000-20000. This number must be unique for each user and each tunnel. Be aware on some platform of HWW (e.g. the cray system hermit1) round robin name service will cause multiple sessions on different login servers. The created tunnel is only available on the login server created by the ssh command above. | |||
To use this tunnel you have to access the selected port (7777) on localhost of hermit1.hww.hlrs.de: | |||
svn co svn://localhost:7777/ffmpeg/trunk ffmpeg | |||
'''on windows using putty you have to open following dialogue:''' | |||
[[File:ssh-tunnel-svn_1.jpg]] | |||
by klick on the ADD button, the dialogue should look like: | |||
[[File:Ssh-tunnel-svn_2.jpg]] | |||
To use this tunnel you have to access the selected port (7778) on localhost of hermit1.hww.hlrs.de: | |||
svn co svn://localhost:7778/ffmpeg/trunk ffmpeg | |||
For more information please check: | |||
man ssh | |||
External links (Wikipedia & Co.): | |||
[http://venthur.de/ssh-tunnel.html ssh-tunnel german] | |||
[http://de.wikipedia.org/wiki/Tunnel_(Rechnernetz) ssh-tunnel wiki german] | |||
[http://en.wikipedia.org/wiki/Tunneling_protocol ssh-tunnel wiki english] | |||
'''as a second example''' following commands are neccessary to transfer an external WEB page into the current working dirtory on the hermit1 system: | |||
## login and create the tunnel | |||
ssh -R7890:ftp.scientificlinux.org:80 hpchugo@hermit1.hww.hlrs.de | |||
## fetch one file from this server | |||
wget http://localhost:7890/linux/scientific/6x/x86_64/iso/readme | |||
'''for tunnelling svn+ssh connections''': | |||
If you use the svn+ssh protocol to check out files you have to use a bit more workarounds since you are already using ssh to do the tunneling. | |||
A possible solution is to start a tunnel from your laptop to the frontend through the firewall and access the repository through this tunnel. Log in to the cluster and see if the port is free | |||
ssh cl3fr1.hww.hlrs.de "netstat -l | grep 10022" | |||
If it is in use, just pick another one for the following steps. | |||
Make a tunnel from your laptop to the repository: | |||
ssh -R10022:your.svnserver.com:22 -N -t -x cl3fr1.hww.hlrs.de | |||
Test the tunnel (this makes sure it works and that an entry of localhost:10022 will be added to your ssh known_hosts file such that ssh-agent works like a charm) by doing the following on the cluster: | |||
ssh -p 10022 username@localhost | |||
(Note that the username is the username at the other end of the tunnel!) | |||
Add a custom protocol to your .subversion/config file on the cluster. Under the heading <tt>[tunnels]</tt> add | |||
tunnel_ssh = $TUNNEL_SSH ssh -p 10022 | |||
Maybe you have to transfer ssh-keys in order to be able to log in password-free. Be aware that there are other users on the same host who can use this tunnel as well, so be careful how much you open. Maybe it is a better idea to temporarily genearate a separate ssh-keypair which you throw away after you are done with the svn stuff. | |||
Finally, you can test the connection, or simply check out your sources: | |||
svn co svn+tunnel_ssh://localhost/repos/... | |||
=== Git === | |||
Git supports four protocols to access remote repositories: Local, HTTP(S), SSH and git (cf. [https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols] for the respective pros and cons). The method required to use Git on the HWW-systems depends on the chosen protocol: | |||
==== Local ==== | |||
no modifications of the standard procedure required in this case | |||
==== HTTP(S) ==== | |||
Unfortunately, just using a SSH tunnel as with the [[Secure_Shell_ssh#SSH | SSH]] and [[Secure_Shell_ssh#git_2 | git]] protocols is not sufficient in this case (cf. [[#HTTPProblemDescription | below]] for a detailed description of the reason). Instead, one has to connect via an additional SOCKS proxy on a machine that has unlimited access to the internet, e.g. your laptop/desktop. | |||
In order to do so, establish a proxy by using a special feature of OpenSSH: | |||
ssh -N -D 1080 localhost | |||
This will establish some kind of a "loopback" SSH connection from your laptop/desktop to itself which will not execute any command (-N) but act as an SOCKS proxy on port 1080 (-D 1080). | |||
On a second shell, now login to the desired HWW-system and forward a port on the remote machine (e.g. 7777) to the port on your laptop/desktop where the newly established SOCKS proxy is listening on (1080): | |||
ssh -R 7777:localhost:1080 <username>@<system-name>.hww.hlrs.de | |||
By doing so, you have a SOCKS proxy listening on port 7777 of the HWW-system. Hence you can use this proxy for accessing remote git repositories. In order to do so, you can now add "-c http.proxy='socks5://localhost:7777'" to your git commands, e.g.: | |||
git -c http.proxy='socks5://localhost:7777' clone <nowiki>http://github.com/llvm-mirror/llvm.git</nowiki> | |||
or to use HTTPS rather than HTTP, do | |||
git -c http.proxy='socks5://localhost:7777' clone <nowiki>https://github.com/llvm-mirror/llvm.git</nowiki> | |||
In order to avoid typing this in every git call, you can also set the respective port to be used whenever git talks to a remote repository via HTTP by | |||
git config --global http.proxy 'socks5://localhost:7777' | |||
<div id="HTTPProblemDescription"></div> | |||
'''''Description of the underlying problem:''''' | |||
''During interaction with the remote side, "normal" URLs (e.g. <nowiki>http://github.com/llvm-mirror/llvm.git</nowiki>) seem to be transferred to the client, which - however - can't be accessed from within the HWW-systems. Instead, the host needs to be replaced by the local endpoint of the tunnel pointing to this host (i.e. <nowiki>http://localhost:7777/llvm-mirror/llvm.git</nowiki> if we have a tunnel from localhost:7777 to github.com:80). This translation, however, can't be done by Git itself because it is not aware of accessing the remote side via an SSH tunnel. The described workaround hence uses a SOCKS proxy outside of the HWW-network in order to avoid this address translation.'' | |||
==== SSH ==== | |||
===== Variant 1 (simpler) ===== | |||
Let's assume we like to clone LLVM from GitHub with the SSH protocol, i.e. we like to access the repository git@github.com:llvm-mirror/llvm.git. | |||
In order to do so, establish a tunnel from a port (e.g. 7777) on the HWW-system to port 22 on the repositories host (github.com) by | |||
ssh -R 7777:github.com:22 <username>@<system-name>.hww.hlrs.de | |||
and use the following syntax to access the repository: | |||
git clone <nowiki>ssh://git@localhost:7777/llvm-mirror/llvm.git</nowiki> | |||
Keep in mind that the usage of SSH to transfer Git data is fully independent of the used SSH tunnel! The latter is rather utilized to ''host'' a ''further'' SSH connection to a repository somewhere on the internet. | |||
===== Variant 2 (easier to use, more advanced setup) ===== | |||
If you want a more permanent solution for git via SSH that works without modifying the clone path, you can try the following solution that uses [https://github.com/larryhou/connect-proxy connect-proxy]: | |||
# Log in to the HWW system and enable reverse dynamic forwarding by executing | |||
<syntaxhighlight lang="shell"> | |||
ssh -R 7777 <username>@<system-name>.hww.hlrs.de | |||
</syntaxhighlight> | |||
This creates a SOCKS proxy on the HWW system that routes internet traffic via your local machine. Instead of 7777, you might want to use another port to avoid use conflicts with other users. | |||
# <li value="2">Get the [https://github.com/larryhou/connect-proxy connect-proxy] source code, e.g., by cloning it locally and then uploading it to the HWW system.</li> | |||
# Enter the <syntaxhighlight lang="shell" inline>connect-proxy</syntaxhighlight> directory and build the <syntaxhighlight lang="shell" inline>connect</syntaxhighlight> tool by calling <syntaxhighlight lang="shell" inline>make</syntaxhighlight>: | |||
<syntaxhighlight lang="shell"> | |||
cd connect-proxy | |||
make | |||
</syntaxhighlight> | |||
# <li value="4">Move the <syntaxhighlight lang="shell" inline>connect</syntaxhighlight> executable to a permanent place (e.g., <syntaxhighlight lang="shell" inline>~/.my_personal_binaries</syntaxhighlight>)</li> | |||
# Configure git to always use your SOCKS proxy when making | |||
<syntaxhighlight lang="shell"> | |||
git config --global core.sshCommand 'ssh -o ProxyCommand="~/.my_personal_binaries/connect -S 127.0.0.1:7777 %h %p"' | |||
</syntaxhighlight> | |||
# <li value="6">Now enjoy using git via ssh using the regular git clone command.</li> | |||
==== git ==== | |||
Let's assume we like to clone LLVM from GitHub with the git protocol, i.e. we like to access the repository at <nowiki>git://github.com/llvm-mirror/llvm.git</nowiki>. | |||
In order to do so, establish a tunnel from a port (e.g. 7777) on the HWW-system to port 9418 on the repositories host (e.g. github.com) by | |||
ssh -R 7777:github.com:9418 <username>@<system-name>.hww.hlrs.de | |||
and just replace the server in the original URL by localhost:7777, i.e. | |||
git clone <nowiki>git://localhost:7777/llvm-mirror/llvm.git</nowiki> | |||
<font color=red>'''With all protocols, don't forget to re-establish the tunnel (and proxy, in case of HTTP(S)) when again attempting to access the remote repository!'''</font color> | |||
=== R === | |||
The proxy method described in the git section above for using https also works for R. So it's repeated here for completeness. | |||
On your client, establish a proxy by using a special feature of OpenSSH: | |||
ssh -N -D 1080 localhost | |||
This will establish some kind of a "loopback" SSH connection from your local machine to itself which will not execute any command (-N) but act as a SOCKS proxy on port 1080 (-D 1080). | |||
On a second shell, now login to the desired HWW-system and forward a port on the remote machine (e.g. 7777) to the port on your local machine where the newly established SOCKS proxy is listening on (1080): | |||
ssh -R 7777:localhost:1080 <system-name>.hww.hlrs.de | |||
By doing so, you have a SOCKS proxy listening on port 7777 of the HWW-system. Hence you can use this proxy for accessing remote git repositories. | |||
Since /tmp on hww machines is mounted with noexec some R-packages won't install properly. To circumvent this problem simply create a tmp directory in your HOME folder and export it as the nem TMPDIR environment variable: | |||
cd | |||
mkdir tmp | |||
export TMPDIR=$HOME/tmp | |||
In order to make R use the SOCKS proxy within an R session you have to set the https_proxy environment variable: | |||
Sys.setenv(https_proxy = "socks5://localhost:7777") | |||
Then simply do as usual | |||
install.packages("<package_name>") | |||
Once you execute the command above R updates its mirror list. This can take quite a while so be patient. | |||
In order to install R-packages from github one can either use the 'remotes' package | |||
remotes::install_github("<path/to/package/on/github>") | |||
where <path/to/package/on/github> is a string constant containing the github page of the package with https://github.com/ stripped away. As an alternative the devtools package can be used. | |||
devtools::install_github("<path/to/package/on/github>") | |||
=== pip (Python package installer) === | |||
{{Warning|text= | |||
You are probably not allowed to install Python modules system-wide. Hence, please use the flag "--user" in order to install the module in your home directory (see [https://pip.pypa.io/en/stable/user_guide/#user-installs here] for details).}} | |||
Python's package installer ''pip'' also requires access to various network resources. The most practical approach is to run a pip-proxy service on your workstation and tunnel pip traffic from the HLRS systems back to your workstation. We suggest to use the pip-proxy ''[https://www.devpi.net devpi]'', which just needs a working Python installation. To install devpi on your local workstation just do | |||
{{Command|command= | |||
local_workstation> pip install devpi <br/> | |||
local_workstation> devpi-init}} | |||
{{Warning|text= | |||
The install location of pip is system-dependent. You might need to add ''$HOME/.local/bin'' to your ''PATH''.}} | |||
The previous step is required only once and will provide the command ''devpi-server''. | |||
Then to install python packages on HLRS systems proceed as follows. You will need two terminals. | |||
The first terminal is used to run devpi-server on your local workstation. | |||
{{Command|command= | |||
local_workstation> devpi-server}} | |||
''devpi-server'' will now listen on port localhost:3141 for pip requests | |||
Later, you will see various log messages on this terminal. It should remain open until your installation session is complete. | |||
The second terminal is used to connect to the respective HLRS system, and forward pip traffic back to devpi on your ssh workstation. | |||
{{Command|command= | |||
local_workstation> ssh -R 56567:localhost:3141 <system-name>.hww.hlrs.de}} | |||
This will connect port 56567 (you may choose any other port above 1024) back to devpi-server, which is listening on port 3141 of your local workstation. At the same time you will get a regular ssh session on the respective HLRS system. Now you need to tell pip to install python packages from an index-url pointing to your pip-proxy | |||
{{Command|command= | |||
hlrs_system> module load python/3 # or python/2.7 or any other python module <br /> | |||
hlrs_system> pip install --index-url <nowiki> http://localhost:56567/root/pypi/+simple/</nowiki> --user <your_package_name> | |||
}} | |||
Note, that the port (here 56567) needs to coincide with the port used for the ssh tunnel above. | |||
Alternatively to the command line option --index-url also the environment variable PIP_INDEX_URL can be set. | |||
When done, close the ssh session to the HLRS system on the second terminal, and terminate devpi-server on the first terminal. | |||
=== SOCKS Proxy under Windows with MobaXterm === | |||
First start a local terminal session and prepare sshd to work properly with generating a default config file | |||
touch /etc/sshd_config | |||
Then generate hostkeys with | |||
ssh-keygen -A | |||
The two steps above have only to be done once. | |||
In the local terminal start the ssh deamon with | |||
sshd | |||
Then create the dynamic and the remote port tunnel with the MobaSSHTunnel tool which you can find in MobaXterm under Tools. Below you can see the settings that have to be made in order to setup both tunnels. | |||
[[File:VirtualBox Windows 8 new 02 08 2023 13 23 48.png|600px|alt=Dynamic tunnel with MobaXterm|Dynamic tunnel with MobaXterm]] | |||
[[File:VirtualBox Windows 8 new 02 08 2023 13 24 03.png|600px|alt=Remote port tunnel with MobaXterm|Remote port tunnel with MobaXterm]] | |||
[[File:VirtualBox Windows 8 new 02 08 2023 13 24 15.png|900px|alt=Tunnel settings in MobaSSHTunnel tool|Tunnel settings in MobaSSHTunnel tool]] | |||
After setting up and starting both tunnels set up a remote session as shown below | |||
[[File:VirtualBox Windows 8 new 02 08 2023 13 25 50.png|900px|alt=Remote session setup in MobaXterm|Remote session setup in MobaXterm]] | |||
In the remote shell execute your regular commands like e.g. to install an R package in user space load the module and start a R session | |||
module load bigdata/R | |||
R | |||
Within the R session do not forget to set the https_proxy environment variable: | |||
Sys.setenv(https_proxy = "socks5://localhost:7777") | |||
Then simply do as usual | |||
install.packages("<package_name>") | |||
Once you execute the command above R updates its mirror list. This can take quite a while so be patient. | |||
== ssh | == ssh within HLRS/HWW == | ||
[[Batch_System_PBSPro_(Hawk)#ssh_from_login_nodes_to_your_allocated_nodes_of_your_job|ssh from login nodes to your allocated nodes of your job]] | |||
on Hawk requires setting the PBS_JOBID environment variable, e.g. | |||
export PBS_JOBID=123456.hawk-pbs5 |
Latest revision as of 15:22, 7 February 2024
Installation
Secure shell is the exclusive way to get into the secure environment of the HWW machines. Commands like telnet, ftp as well as the r-cmds are NOT allowed and therefore are rejected by the firewall.
On HWW platforms the ssh software is installed. The user is responsible for installation of ssh on his platform.
The source of OpenSSH is available from
- HOME page of OpenSSH Alternatives for other platforms like MS Windows can also be found on this site.
For details on the licensing see the external link HOME page of OpenSSH
Please read first the files README and INSTALL.
Please be aware to run the latest version of ssh client software. Most operating systems provide installable packages and update mechanism.
Tips and hints
if you can't get a connection
this may have 3 causes:
- Your workstation is not known and blocked by the firewall. Please contact Your HLRS contact person (adviser/Betreuer), or submit a bug-report to accounting via the Trouble Ticket Submission Form providing Your username and the static IP Address You want to access from (your external IP address).
- The HWW platform, you're trying to connect to, is currently not running. Please check the appropriate status page for your platform.
- Your ssh client is setuid root. Please remove setuid root bit or use -P (for ssh) resp. -L option (for scp).
If you encounter any problems while connecting with ssh, please use -v option to get more detailed messages from ssh.
ssh and scp filetransfer without password (using protocol version 2)
Login via ssh resp. Filetransfer via scp is also possible without having to enter a password. Authentification is done via a public/private key pair. The following steps have to be accomplished:
(system1 is the machine from which you logon to the target system system2)
System1 > ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key ($HOME/.ssh/id_rsa): <RETURN> Enter passphrase (empty for no passphrase): <RETURN> Enter same passphrase again: <RETURN> Your identification has been saved in $HOME/.ssh/id_rsa. Your public key has been saved in $HOME/.ssh/id_rsa.pub. The key fingerprint is: 2f:5c:18:e7:g0:3b:fb:52:g3:22:1d:3d:a4:cf:b1:57 $LOGNAME@$HOSTNAME
System1 > chmod 700 $HOME/.ssh System1 > chmod 600 $HOME/.ssh/id_rsa System1 > cd $HOME/.ssh System1 > scp id_rsa.pub System2:sys1.pub
System2 > cd $HOME/.ssh System2 > cat $HOME/sys1.pub >> authorized_keys System2 > chmod 700 $HOME/.ssh
There's also a command automizing the last steps:
System1 > ssh-copy-id System2
The key generation with ssh-keygen has only to be done once. The public key in the file $HOME/.ssh/identity.pub can be used for as many systems as needed.
Further information regarding ssh can be found at external link http://www.cs.hut.fi/ssh/ or at external link DATA FELLOWS - F-Secure SSH A good alternative for Windows platforms is external link putty. For file transfer WinSCP is a powerful client.
ssh tunnel
Due to security policies inside the HWW network (all HWW platforms), general internet access is not possible. For example to get access to software repositories (svn servers, git servers, etc.), a ssh tunnel could be useful.
W A R N I N G :
If you create an ssh tunnel, any user on this system is able to access this port. Please be aware of sensitive data on your local network. E.g. if you create an ssh tunnel to your local private software repository, any users on the remote server has access to this port and is able to use this repository!
SVN
Please find the following example to get access to a svn repository.
For Linux, Mac and Unix users:
Assume the svn repository is: svn.mplayerhq.hu listening on port 3690 (default svn port) and your username on the HWW platform hermit1.hww.hlrs.de is hpchugo. Then on your local workstation login and create the tunnel using following commands:
ssh -R7777:svn.mplayerhq.hu:3690 hpchugo@hermit1.hww.hlrs.de
You will be asked for your password on hermit1 and get a login session. The local port on hermit1 into the created tunnel in this example is 7777. Please select a different number in the range of 5000-20000. This number must be unique for each user and each tunnel. Be aware on some platform of HWW (e.g. the cray system hermit1) round robin name service will cause multiple sessions on different login servers. The created tunnel is only available on the login server created by the ssh command above.
To use this tunnel you have to access the selected port (7777) on localhost of hermit1.hww.hlrs.de:
svn co svn://localhost:7777/ffmpeg/trunk ffmpeg
on windows using putty you have to open following dialogue:
by klick on the ADD button, the dialogue should look like:
To use this tunnel you have to access the selected port (7778) on localhost of hermit1.hww.hlrs.de:
svn co svn://localhost:7778/ffmpeg/trunk ffmpeg
For more information please check:
man ssh
External links (Wikipedia & Co.): ssh-tunnel german ssh-tunnel wiki german ssh-tunnel wiki english
as a second example following commands are neccessary to transfer an external WEB page into the current working dirtory on the hermit1 system:
## login and create the tunnel ssh -R7890:ftp.scientificlinux.org:80 hpchugo@hermit1.hww.hlrs.de ## fetch one file from this server wget http://localhost:7890/linux/scientific/6x/x86_64/iso/readme
for tunnelling svn+ssh connections:
If you use the svn+ssh protocol to check out files you have to use a bit more workarounds since you are already using ssh to do the tunneling.
A possible solution is to start a tunnel from your laptop to the frontend through the firewall and access the repository through this tunnel. Log in to the cluster and see if the port is free
ssh cl3fr1.hww.hlrs.de "netstat -l | grep 10022"
If it is in use, just pick another one for the following steps.
Make a tunnel from your laptop to the repository:
ssh -R10022:your.svnserver.com:22 -N -t -x cl3fr1.hww.hlrs.de
Test the tunnel (this makes sure it works and that an entry of localhost:10022 will be added to your ssh known_hosts file such that ssh-agent works like a charm) by doing the following on the cluster:
ssh -p 10022 username@localhost
(Note that the username is the username at the other end of the tunnel!)
Add a custom protocol to your .subversion/config file on the cluster. Under the heading [tunnels] add
tunnel_ssh = $TUNNEL_SSH ssh -p 10022
Maybe you have to transfer ssh-keys in order to be able to log in password-free. Be aware that there are other users on the same host who can use this tunnel as well, so be careful how much you open. Maybe it is a better idea to temporarily genearate a separate ssh-keypair which you throw away after you are done with the svn stuff.
Finally, you can test the connection, or simply check out your sources:
svn co svn+tunnel_ssh://localhost/repos/...
Git
Git supports four protocols to access remote repositories: Local, HTTP(S), SSH and git (cf. [1] for the respective pros and cons). The method required to use Git on the HWW-systems depends on the chosen protocol:
Local
no modifications of the standard procedure required in this case
HTTP(S)
Unfortunately, just using a SSH tunnel as with the SSH and git protocols is not sufficient in this case (cf. below for a detailed description of the reason). Instead, one has to connect via an additional SOCKS proxy on a machine that has unlimited access to the internet, e.g. your laptop/desktop.
In order to do so, establish a proxy by using a special feature of OpenSSH:
ssh -N -D 1080 localhost
This will establish some kind of a "loopback" SSH connection from your laptop/desktop to itself which will not execute any command (-N) but act as an SOCKS proxy on port 1080 (-D 1080).
On a second shell, now login to the desired HWW-system and forward a port on the remote machine (e.g. 7777) to the port on your laptop/desktop where the newly established SOCKS proxy is listening on (1080):
ssh -R 7777:localhost:1080 <username>@<system-name>.hww.hlrs.de
By doing so, you have a SOCKS proxy listening on port 7777 of the HWW-system. Hence you can use this proxy for accessing remote git repositories. In order to do so, you can now add "-c http.proxy='socks5://localhost:7777'" to your git commands, e.g.:
git -c http.proxy='socks5://localhost:7777' clone http://github.com/llvm-mirror/llvm.git
or to use HTTPS rather than HTTP, do
git -c http.proxy='socks5://localhost:7777' clone https://github.com/llvm-mirror/llvm.git
In order to avoid typing this in every git call, you can also set the respective port to be used whenever git talks to a remote repository via HTTP by
git config --global http.proxy 'socks5://localhost:7777'
Description of the underlying problem: During interaction with the remote side, "normal" URLs (e.g. http://github.com/llvm-mirror/llvm.git) seem to be transferred to the client, which - however - can't be accessed from within the HWW-systems. Instead, the host needs to be replaced by the local endpoint of the tunnel pointing to this host (i.e. http://localhost:7777/llvm-mirror/llvm.git if we have a tunnel from localhost:7777 to github.com:80). This translation, however, can't be done by Git itself because it is not aware of accessing the remote side via an SSH tunnel. The described workaround hence uses a SOCKS proxy outside of the HWW-network in order to avoid this address translation.
SSH
Variant 1 (simpler)
Let's assume we like to clone LLVM from GitHub with the SSH protocol, i.e. we like to access the repository git@github.com:llvm-mirror/llvm.git. In order to do so, establish a tunnel from a port (e.g. 7777) on the HWW-system to port 22 on the repositories host (github.com) by
ssh -R 7777:github.com:22 <username>@<system-name>.hww.hlrs.de
and use the following syntax to access the repository:
git clone ssh://git@localhost:7777/llvm-mirror/llvm.git
Keep in mind that the usage of SSH to transfer Git data is fully independent of the used SSH tunnel! The latter is rather utilized to host a further SSH connection to a repository somewhere on the internet.
Variant 2 (easier to use, more advanced setup)
If you want a more permanent solution for git via SSH that works without modifying the clone path, you can try the following solution that uses connect-proxy:
- Log in to the HWW system and enable reverse dynamic forwarding by executing
ssh -R 7777 <username>@<system-name>.hww.hlrs.de
This creates a SOCKS proxy on the HWW system that routes internet traffic via your local machine. Instead of 7777, you might want to use another port to avoid use conflicts with other users.
- Get the connect-proxy source code, e.g., by cloning it locally and then uploading it to the HWW system.
- Enter the
connect-proxy
directory and build theconnect
tool by callingmake
:
cd connect-proxy
make
- Move the
connect
executable to a permanent place (e.g.,~/.my_personal_binaries
) - Configure git to always use your SOCKS proxy when making
git config --global core.sshCommand 'ssh -o ProxyCommand="~/.my_personal_binaries/connect -S 127.0.0.1:7777 %h %p"'
- Now enjoy using git via ssh using the regular git clone command.
git
Let's assume we like to clone LLVM from GitHub with the git protocol, i.e. we like to access the repository at git://github.com/llvm-mirror/llvm.git. In order to do so, establish a tunnel from a port (e.g. 7777) on the HWW-system to port 9418 on the repositories host (e.g. github.com) by
ssh -R 7777:github.com:9418 <username>@<system-name>.hww.hlrs.de
and just replace the server in the original URL by localhost:7777, i.e.
git clone git://localhost:7777/llvm-mirror/llvm.git
With all protocols, don't forget to re-establish the tunnel (and proxy, in case of HTTP(S)) when again attempting to access the remote repository!
R
The proxy method described in the git section above for using https also works for R. So it's repeated here for completeness.
On your client, establish a proxy by using a special feature of OpenSSH:
ssh -N -D 1080 localhost
This will establish some kind of a "loopback" SSH connection from your local machine to itself which will not execute any command (-N) but act as a SOCKS proxy on port 1080 (-D 1080).
On a second shell, now login to the desired HWW-system and forward a port on the remote machine (e.g. 7777) to the port on your local machine where the newly established SOCKS proxy is listening on (1080):
ssh -R 7777:localhost:1080 <system-name>.hww.hlrs.de
By doing so, you have a SOCKS proxy listening on port 7777 of the HWW-system. Hence you can use this proxy for accessing remote git repositories.
Since /tmp on hww machines is mounted with noexec some R-packages won't install properly. To circumvent this problem simply create a tmp directory in your HOME folder and export it as the nem TMPDIR environment variable:
cd mkdir tmp export TMPDIR=$HOME/tmp
In order to make R use the SOCKS proxy within an R session you have to set the https_proxy environment variable:
Sys.setenv(https_proxy = "socks5://localhost:7777")
Then simply do as usual
install.packages("<package_name>")
Once you execute the command above R updates its mirror list. This can take quite a while so be patient.
In order to install R-packages from github one can either use the 'remotes' package
remotes::install_github("<path/to/package/on/github>")
where <path/to/package/on/github> is a string constant containing the github page of the package with https://github.com/ stripped away. As an alternative the devtools package can be used.
devtools::install_github("<path/to/package/on/github>")
pip (Python package installer)
Python's package installer pip also requires access to various network resources. The most practical approach is to run a pip-proxy service on your workstation and tunnel pip traffic from the HLRS systems back to your workstation. We suggest to use the pip-proxy devpi, which just needs a working Python installation. To install devpi on your local workstation just do
local_workstation> devpi-init
The previous step is required only once and will provide the command devpi-server.
Then to install python packages on HLRS systems proceed as follows. You will need two terminals. The first terminal is used to run devpi-server on your local workstation.
devpi-server will now listen on port localhost:3141 for pip requests Later, you will see various log messages on this terminal. It should remain open until your installation session is complete.
The second terminal is used to connect to the respective HLRS system, and forward pip traffic back to devpi on your ssh workstation.
This will connect port 56567 (you may choose any other port above 1024) back to devpi-server, which is listening on port 3141 of your local workstation. At the same time you will get a regular ssh session on the respective HLRS system. Now you need to tell pip to install python packages from an index-url pointing to your pip-proxy
hlrs_system> pip install --index-url http://localhost:56567/root/pypi/+simple/ --user <your_package_name>
Note, that the port (here 56567) needs to coincide with the port used for the ssh tunnel above. Alternatively to the command line option --index-url also the environment variable PIP_INDEX_URL can be set.
When done, close the ssh session to the HLRS system on the second terminal, and terminate devpi-server on the first terminal.
SOCKS Proxy under Windows with MobaXterm
First start a local terminal session and prepare sshd to work properly with generating a default config file
touch /etc/sshd_config
Then generate hostkeys with
ssh-keygen -A
The two steps above have only to be done once.
In the local terminal start the ssh deamon with
sshd
Then create the dynamic and the remote port tunnel with the MobaSSHTunnel tool which you can find in MobaXterm under Tools. Below you can see the settings that have to be made in order to setup both tunnels.
After setting up and starting both tunnels set up a remote session as shown below
In the remote shell execute your regular commands like e.g. to install an R package in user space load the module and start a R session
module load bigdata/R R
Within the R session do not forget to set the https_proxy environment variable:
Sys.setenv(https_proxy = "socks5://localhost:7777")
Then simply do as usual
install.packages("<package_name>")
Once you execute the command above R updates its mirror list. This can take quite a while so be patient.
ssh within HLRS/HWW
ssh from login nodes to your allocated nodes of your job on Hawk requires setting the PBS_JOBID environment variable, e.g.
export PBS_JOBID=123456.hawk-pbs5