You have a few options to install software by yourself:
You can always email IT Linux Support to get help installing new software. We can walk you through the steps above so you are independent or we can do it for you. We usually install new software in the share scientific application stack.
We will install and manage research software. We do not manage software on the system like Word, Chrome, TeamViewer, etc.
Please check our list of scientific software before sending a request.
You can send an email to IT Linux Support team to install software on your Linux workstation.
FTPS is an extension to FTP that adds a security layer.
Requesting an account differs based if your a KAUST employee or if you're requesting on for an external collaborator. In both cases, once you have gone through the process you'll receive an email from the Linux & Advanced Platforms Team explaining how to access and use the FTPS server.
Note that you will need a remote account to get Linux access. You can register for an account here.
Internal users have to send an email to IT Linux team to get access.
Once you have been granted access, you will be able to login with your KAUST portal credentials. You will have a bash shell which will allows you to login to the server (in addition to being able to do ftp) and allows normal UNIX user tasks.
External users will need a KAUST employee as a sponsor. The sponsor has to fill out the FTP Account Request form.
External users will have ftp shell. They will not be able to ssh to the server, except to change their password.
You might receive a warning message about man in the middle attack similar to this one:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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 the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is ca:5e:61:7f:67:59:d9:0e:5d:28:6a:3b:df:97:3a:c7. Please contact your system administrator. Add correct host key in /home/moondh/.ssh/known_hosts to get rid of this message. Offending key in /home/moondh/.ssh/known_hosts:2 RSA host key for 172.29.4.66 has changed and you have requested strict checking. Host key verification failed.
This can happen when your job is submitted to a node (selected by the scheduler) and the remote host ID which previously had been stored in your ~/.ssh/known_hosts file does not match the actual remote host
ID. This file automatically captures remote host ID (think of it as a unique fingerprint for each node) for all nodes which you had previously logged into or have run a job on.
In order to resolve this issue, you have 2 options.
First, the simplest way is to remove the ~/.ssh/known_hosts file. You can achieve this by executing:
$ rm -f ~/.ssh/known_hosts
The other way is to remove only the line corresponding to the mismatched remote host ID. You can open the ~/.ssh/known_hosts file with your favorite editor and perform a text search on the hostname of the node or the fingerprint
which is printed in the warning message.
The message also tell you which line to remove, line 2 in this case
/home/moondh/.ssh/known_hosts:2
This guide goes through necessary steps to setup secure passwordless connection between a local Mac or Linux computer and a remote server running a Linux variant. The process requires generating a public and private key on the local computer and then adding the public key to the remote servers authorized list. What is great about this is that it allows a password prompt free session, handy for a lot of uses.
The steps outlined in this page are for Macs but also apply to your Linux workstation.
First thing that you need to do on your macOS machine is to create a directory that will store your SSH keys and generate a public and private key for your account. Then you will need to copy the public key to the server. Finally you will test the passwordless SSH connection.
Change to the home directory
cd
Create a SSH directory name .ssh and move into it
mkdir .ssh
cd .ssh
Make sure that the file permissions are set to read/write/execute only for the user to enforce security
chmod go-rwx ~/.ssh
Create your private and public key, the blank quotes at the end of the command gives the private key no password, thus allowing for passwordless logins.
ssh-keygen -b 1024 -t rsa -f id_rsa -P ""
Now let's list the contents of the .ssh directory
That's your SSH keys created, the private key is the id_rsa and the public one is the id_rsa.pub. Don’t give out the private one; always keep it only on your local machine.
You should repeat this command for all remote hosts you access. Data Movers and Remote Workstations share the same HOME so you won't have to repeat it on those hosts; once is enough.
You can create automatic logins by adding the contents of your public key to the authorized_keys file on the remote server.
You might need to install ssh-copy-id on your Mac. It's simple, just use this command
brew install ssh-copy-id
We can do that with one command
ssh-copy-id dm.kaust.edu.sa
ssh-copy-id is a script that uses ssh to log into a remote machine (presumably using a login password, so password authentication should be enabled, unless you've done some clever use of multiple identities) It also changes the permissions of the remote user's home, ~/.ssh, and ~/.ssh/authorized_keys to remove group write-ability.
You can use the following command if you don't have ssh-copy-id installed or can't install it on your machine
cat ~/.ssh/id_rsa.pub | ssh dm.kaust.edu.sa 'cat >> ~/.ssh/authorized_keys'
This command takes the generated SSH key from the local machine, connects to the remote host via SSH, and then uses cat to append the key file to the remote users authorized key list. Because this connects with SSH to the remote machine you will need to enter the password to use this command.
Finally, confirm that you can now login to the remote SSH server without a password
Let's be sure that the authorized_keys file on the remote server can only be modified by you
Now the last step is to create config file on the remote server whose contents is
Host *
StrictHostKeyChecking no
UserKnownHostsFile /dev/null
This guide goes through the necessary steps to setup a secure passwordless SSH PuTTY connection between a local Windows computer and a remote server running a Linux variant. The process requires generating a public and private key on the local computer and then adding the public key to the authorized list on the remote server. How the passwordless connection works is that during the setup of the connection, instead of using a password, the public key on the remote server is compared to the private key on the Windows client. What is great about this is that it allows a password prompt free session, handy for a lot of uses.
The process has the following steps:
The KAUST Software Center makes PuTTY and PuTTYgen available for installation on your Windows system. PuTTY is an SSH client and PuTTYgen is a generator of public and private keys to be used with PuTTY.
To install PuTTY and PuTTYgen, go to the Software Center on your Windows system. You find the Software Center by going to the Apps page on your Windows system, and searching for Software Center. Check the box next to PuTTY, and click on INSTALL SELECTED. This will install both PuTTY and PuTTYgen.
Once PuTTY and PuTTYgen have been installed, you need to launch PuTTYgen to generate the public/private key pair.
Select the type of key to generate in the parameters at the bottom of the window. SSH2-RSA is selected by default, and it is better and more secure than SSH-1 and SSH-2 DSA. You can also increase the number of bits in the generated key from 2048 to 4096 to make the key stronger, thus harder to break.
Now hit the Generate button.
When the process is in the generation phase like the figure above, move your mouse over the blank area several times to generate more randomness in the key generation.
Once the key generation is complete, you will be able to view the public key in the PuTTYgen window.
You save the public key as a .txt file and the private key as a .ppk file on your Windows system. Once saved, PuTTY will be able to use the keys when setting up a connection to the Linux system. PuTTY will compare the private key on the Windows system with the list of authorized public keys on the Linux system.
You save the public key with the Save public key button, and the private key with the Save private key button on the PuTTYgen window. Make sure you save the public key as a .txt file.
When saving the private key, you will be asked whether you are sure you want to save the key without a passphrase to protect it. Answer Yes.
Make sure you save the private key as a PuTTY private key (.ppk) file.
You now need to login into your Linux system, and store the public key in the list of authorized keys, so that when your Windows client tries to connect to the server, it will be able to get access by comparing its private key with the public key stored on the Linux server. The list is stored in a file called authorized_keys in directory .ssh in your home directory. If this directory does not exist yet, please create it first.
mkdir .ssh
cd .ssh
If the file authorized_keys exists, then you need to append the public key created in PuTTYgen to this file. Copy the key from the PuTTYgen window (see below) and paste it to the file authorized_keys, using your favorite editor.
If the file authorized_keys does not yet exist, please create it, and insert the public key into this file.
Make sure that the file authorized_keys can only be modified by you.
You can now test the connection by launching PuTTY. You need to configure PuTTY to use the newly generated private key. Go to Connection > SSH > Auth.
Click the Browse button and locate the private key you have saved on the Windows system.
Once you have specified the private key, make sure that your system username is specified as login name. Go to Connection > Data.
Under the textWhen username is not specified, click on Use system username.
We've noticed that on some Windows boxes your username is all capital letters. You have to specify your lowercase username in this case in the Auto-login username text field.
Go back top the main page on PuTTY and login as usual. Upon clicking the Open button, PuTTY will login without asking for the password.
This guide goes through the necessary steps to setup a secure X11 window forwarding using PuTTY connection between a local Windows computer and a remote server running a Linux variant. The process requires installing X11 Server emulator (VcXsrv or Xming).
The process has the following steps:
VcXsrv is a Windows X-server based on the xorg git sources (like xming or cygwin's xwin), but compiled with Visual C++ 2012 Express Edition.
After installing VcXsrv, make sure that you run it to be able to forward your X11 windows successfully. Double Click on this shortcut.
The KAUST Software Center makes PuTTY available for installation on your Windows system. PuTTY is an SSH client.
To install PuTTY, go to the Software Center on your Windows system. You find the Software Center by going to the Apps page on your Windows system, and searching for Software Center. Check the box next to PuTTY, and click on INSTALL SELECTED. This will install PuTTY.
Now we need to configure PuTTY to make use of the installed X11 server emulator.
NOT zero.
5
localhost:0.0. 8.
You can now test your configurations by launching PuTTY session and run the following command.
$ xclock &
A small window will appear as the following:
If nothing appears, you need to double check your configurations.
X authentication is based on cookies – secret little pieces of random data that only you and the X server know. You need to let the other user in on what your cookie is.
Before you issue the su or sudo (but after having ssh'ed into the remote system), request the cookie for the current DISPLAY that's connecting to your X server:
$ xauth list $DISPLAY
You'll get something like
somehost.somedomain:10 MIT-MAGIC-COOKIE-1 4d22408a71a55b41ccd1657d377923ae
Then, after having done su, tell the new user what the cookie is:
$ xauth add somehost.somedomain:10 MIT-MAGIC-COOKIE-1 4d22408a71a55b41ccd1657d377923ae
just copy'n-paste the output of the above xauth list onto xauth add.
That's it. Now, you should be able to start any X application.