Difference between revisions of "SPO600 Servers"
Chris Tyler (talk | contribs) |
Chris Tyler (talk | contribs) (→AArch64: israel.cdot.systems) |
||
(One intermediate revision by the same user not shown) | |||
Line 27: | Line 27: | ||
=== AArch64: israel.cdot.systems === | === AArch64: israel.cdot.systems === | ||
− | A main AArch64 system is available, known as ''israel''. This machine has a lot of mid-range cores. You can access this system at the hostname israel.cdot.systems; if you're using a command-line ssh system, you can access | + | A main AArch64 system is available, known as ''israel''. This machine has a lot of mid-range cores. You can access this system at the hostname israel.cdot.systems; if you're using a command-line ssh system, you can access israel with a command such as this: |
ssh ''username''@israel.cdot.systems | ssh ''username''@israel.cdot.systems | ||
Line 165: | Line 165: | ||
# If your SSH public key is not named <code>~/.ssh/id_rsa</code>, your SSH client may not automatically find it. You can specify the identity (private key) file using the <code>-i</code> argument to the SSH command.}} | # If your SSH public key is not named <code>~/.ssh/id_rsa</code>, your SSH client may not automatically find it. You can specify the identity (private key) file using the <code>-i</code> argument to the SSH command.}} | ||
− | + | ==== Debugging SSH Connection Problems ==== | |
− | |||
− | + | ===== Situation 1: The SSH client asks you for a passphrase ===== | |
− | + | The passphrase is the one you provided when you created your SSH keys. You must remember this passphrase in order to successfully unlock your private key. If you do not remember your passphrase, you will need to create a new pair of keys and re-send the public key to your professor: | |
+ | # Create the keys with <code>ssh-keygen -t ed25591</code> | ||
+ | # Copy the public key (which by default will be named <code>~/.ssh/id_ed25519.pub</code>) to a file named <code>'''UserId'''.pub</code> where '''UserId''' is your Seneca User ID. | ||
+ | # Attach that file to an e-mail message and send it to your professor. | ||
+ | ===== Situation 2: The SSH client asks you for a password ===== | ||
+ | |||
+ | The password is for the remote system, but the SSH client will only ask you for a password if it is unable to authenticate using your keys. If that is the case, then one of your keys is corrupted, missing, has the wrong permission, or can't be found by the SSH client. | ||
+ | # If you're using OpenSSH, try using the <code>-i</code> argument to tell the client which private key identity file to use: <code>ssh -i /path/to/ssh/PrivateKey ...</code> | ||
+ | # Check the permissions on the private key and the directory holding the private key. | ||
+ | # If necessary, generate a new key and send it to your professor (see the previous section). | ||
+ | |||
+ | ===== Getting Verbose Output ===== | ||
+ | |||
+ | To see what the OpenSSH client program is doing, you can use the <code>-v</code> (verbose) argument, up to three times: <code>ssh -vvv ...</code> | ||
+ | |||
+ | By reading through the output carefully, you can see what the OpenSSH client program is doing, and address any problems that arise (such as permission or file naming issues). | ||
== Disconnect/Reconnect Ability == | == Disconnect/Reconnect Ability == |
Latest revision as of 02:02, 11 September 2023
Contents
Preparatory Steps
In order to gain access to these computers, you must send an SSH key to your professor.
An account will be created within a few work days of sending the key.
Available Servers
The names of servers within CDOT are based on the names of countries. There is no significance to the country names.
AArch64: israel.cdot.systems
A main AArch64 system is available, known as israel. This machine has a lot of mid-range cores. You can access this system at the hostname israel.cdot.systems; if you're using a command-line ssh system, you can access israel with a command such as this:
ssh username@israel.cdot.systems
x86_64: portugal.cdot.systems
The x86_64 server system is known as portugal. If you're using a command-line ssh system, you can access xerxes with a command such as this:
ssh username@portugal.cdot.systems
Simplified SSH Access
If you're using OpenSSH (the ssh client used on most Linux systems and other platforms), you can simplify ssh command lines by placing host connection details in the file ~/.ssh/config
:
Host "portugal" hostname "portugal.cdot.systems" user "YourUserID" Host "israel" hostname "israel.cdot.systems" user "YourUserID"
Once you have added these lines (inserting your user ID where appropriate) and set the permission on that file (chmod 0600 ~/.ssh/config
) you can use these commands to access the servers:
ssh israel ssh portugal
You can similarly configure simplified access in most other SSH client programs.
Multiuser Access
Remember that these machines are multi-user systems. Use the w
or who
commands to see who else is using them; you can also try using the write
command to communicate with another user if required.
Passwords
Your password on each of these systems has been set to a random string (different on each host). You can find out the original random password by viewing the file ~/password.txt
and you can change the password with the passwd
command. Your password is used for sudo access (see the next section).
Sudo Access
To perform operations which require privilege, such as installing software, use the sudo
command to execute the desired instruction as the root
user.
For example, to install the software packaged ncurses-devel
, execute: sudo dnf install ncurses-devel
on xerxes or sudo yum install ncurses-devel
on betty. The commands are different because Xerxes is running Fedora, which has transitioned from the older yum system to dnf, while Betty is running LEAP (based on CentOS), which still uses the older system.
In order to use sudo
, you will need to know your password. An initial random password is provided in the file ~/password.txt
(note that your password will be different on each server). Feel free to change this with the passwd
command -- not by editing the file, which is provided only for your information!
SSH Access from Other Client Systems
If you wish to access the servers from additional computers, you can append the SSH public keys from those computers to the ~/.ssh/authorized_keys
file. Alternately, you can copy the private key from one client system to another (e.g., your laptop to your desktop).
OS Versions
The current servers are both running Fedora 35 and will be updated from time to time. The machines may not be updated at the same time, so the versions of software may vary slightly. The kernel versions may also vary between the systems because of kernel hardware support.
Backup Your Accounts
These accounts are never backed up, and the machines may fail, lose data, or be reinstalled without warning at any time. Please back up your work frequently by copying it to another system or storage device.
Common SSH Problems
With the OpenSSH client:
- Your ssh private key must be in your
~/.ssh
directory (which must have 0700 permission) and the private key file must have 0600 permissions -- no more and no less. - If your SSH public key is not named
~/.ssh/id_rsa
, your SSH client may not automatically find it. You can specify the identity (private key) file using the-i
argument to the SSH command.}}
Debugging SSH Connection Problems
Situation 1: The SSH client asks you for a passphrase
The passphrase is the one you provided when you created your SSH keys. You must remember this passphrase in order to successfully unlock your private key. If you do not remember your passphrase, you will need to create a new pair of keys and re-send the public key to your professor:
- Create the keys with
ssh-keygen -t ed25591
- Copy the public key (which by default will be named
~/.ssh/id_ed25519.pub
) to a file namedUserId.pub
where UserId is your Seneca User ID. - Attach that file to an e-mail message and send it to your professor.
Situation 2: The SSH client asks you for a password
The password is for the remote system, but the SSH client will only ask you for a password if it is unable to authenticate using your keys. If that is the case, then one of your keys is corrupted, missing, has the wrong permission, or can't be found by the SSH client.
- If you're using OpenSSH, try using the
-i
argument to tell the client which private key identity file to use:ssh -i /path/to/ssh/PrivateKey ...
- Check the permissions on the private key and the directory holding the private key.
- If necessary, generate a new key and send it to your professor (see the previous section).
Getting Verbose Output
To see what the OpenSSH client program is doing, you can use the -v
(verbose) argument, up to three times: ssh -vvv ...
By reading through the output carefully, you can see what the OpenSSH client program is doing, and address any problems that arise (such as permission or file naming issues).
Disconnect/Reconnect Ability
The screen utility provides disconnect/reconnect capability, which is very useful for unstable network connections, long interactive operations, and changing your work location.
Other programs such as tmux provide similar capability.
For graphical disconnect/reconnect capability, consider using VNC.