Changes

<!-- {{Admon/important|Backup Your Data|These computers are NEVER backed up. Please save all important files on other storage. '''These machines may fail, be removed, be upgraded, or be reinstalled at any time.'''}}In [[SPO600]], remote access to servers is provided for learning and project work. It is recommended that you also set up [[SPO600 Host Setup|a personal Linux system]].-->

In order to gain access to these computers, you must send an [[SSH]] key to your [[User:Chris Tyler|professor]]. <!-- Please follow these instructions exactly:

# Attach that file to an e-mail message and send it to [mailto:chris.tyler@senecacollege.ca chris.tyler@senecacollege.ca] with the subject line "SPO600 Key".-->

<!-- {{Admon/important|Server ChangesContent being Updated|The server configurations have changed several times changed -- This page is in the process of being updated from a previous mentions of these systems by name may have referred to different hardwaresemester's content. Note that The SPO600 servers may will be set up in a new configuration later this semester, and this information will be added or updated. Do not rely on this information until this warning is removed as the semester proceeds.}}

A main === AArch64 system is available, known as ''aarchie''. This machine has a lot of weak cores. You can access this system at the hostname aarchie: israel.cdot.systems; if you're using a command-line ssh system, you can access aarchie with a command such as this:===

ssh A main AArch64 system is available, known as ''usernameisrael''@aarchie. 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 aarchie with a command such as this:

ssh ''username''@israel.cdot.systems<!-- === AArch64: bbetty ===

=== The x86_64server system is known as ''portugal''. If you're using a command-line ssh system, you can access xerxes with a command such as this: xerxes ===

The x86_64 server system is known as ''xerxes''. If you're using a command-line ssh system, you can access xerxes with a command such as this:  ssh ''username''@xerxesportugal.cdot.systems

user "YourUserId" -->

<!-- Host "xerxes"

ssh xerxesportugal

If you wish == Multiuser Access == Remember that these machines are multi-user systems. Use the <code>w</code> or <code>who</code> commands to access the servers from additional computers, see who else is using them; you can append also try using the SSH public keys from those computers <code>write</code> 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 <code>~/password.sshtxt</authorized_keyscode> and you can change the password with the <code>passwd</code> filecommand. Your password is used for sudo access (see the next section).

{{Admon/caution|Do Not DO NOT Build or Install Software Except Via as Root except via RPM (dnf/yum) or DEB (apt)|Do not build or install software as the root user (using <code>sudo</code>), except in RPM or DEB form using the <code>dnf</code>/<code>yum</code> or <code>apt</code> commands (as appropriate to the system). Building or installing software as root may overwrite system files and be very difficult to track down.<br /><br />It is OK to install software into your own directories (e.g., <code>~/bin</code> or <code>~/local</code>), which can be done without root privilege.}}

Remember that these machines are multi-user systems. Use == 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 <code>w<~/.ssh/code> or <code>whoauthorized_keys</code> commands to see who else is using them; file. Alternately, you can also try using copy the <code>write</code> command private key from one client system to communicate with another user if required(e.g., your laptop to your desktop).

Note that 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 servers versions of software may vary slightly. The kernel versions may have different operating system releasesalso vary between the systems because of kernel hardware support. 

With other ==== Debugging SSH clientsConnection Problems ==== ===== Situation 1:The SSH client asks you for a passphrase ===== # Your key The passphrase is the one you provided when you created your SSH keys. You must be remember this passphrase in OpenSSH format when 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 it the public key to your professor; this format is used :# Create the keys with <code>ssh-keygen -t ed25591</code># Copy the public key (which by the default SSH client on Mac OSwill be named <code>~/.ssh/id_ed25519.pub</code>) to a file named <code>'''UserId'''.pub</X code> where '''UserId''' is your Seneca User ID.# Attach that file to an e-mail message and Linux as well as PuTTYsend it to your professor. If it is in SSH2 format, used by some other  ===== Situation 2: The SSH client programs, asks you can convert it with this command on for a Linux system with OpenSSH (such as Matrix):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-keygen -i -f ~/.path/to/ssh/''SSH2_PUBLIC_KEY_FILE''PrivateKey ...pub </code> ~/# Check the permissions on the private key and the directory holding the private key.ssh/''OPENSSH_PUBLIC_KEY_FILE''# If necessary, generate a new key and send it to your professor (see the previous section).pub

Your professor will do this automatically as part of ===== Getting Verbose Output ===== To see what the key processing; howeverOpenSSH client program is doing, you will need to manually perform this step for any keys that you append can use the <code>-v</code> (verbose) argument, up to your three times: <code>~/ssh -vvv ...ssh/authorized_keys</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(snaming issues).