Changes

=== x86_64: portugal .cdot.systems ===

{{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.}}

If you wish to access the servers from additional computers, you can append the SSH public keys from those computers to the <code>~/.ssh/authorized_keys</code> file.Alternately, you can copy the private key from one client system to another (e.g., your laptop to your desktop). 

The current servers are both running Fedora 35 and will be updated from time to time. The two 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. 

With other ==== Debugging SSH clients:# Your key must be in OpenSSH format when you send it to your professor; this format is used by the default SSH client on Mac OS/X and Linux as well as PuTTY. If it is in SSH2 format, used by some other client programs, you can convert it with this command on a Linux system with OpenSSH (such as Matrix):Connection Problems ====

Your professor will do The passphrase is the one you provided when you created your SSH keys. You must remember this automatically as part of the passphrase in order to successfully unlock your private key processing; however. If you do not remember your passphrase, you will need to manually perform this step for any create a new pair of keys that you append 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/authorized_keysid_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 fileto 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 (ssee 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).