Accessing Lab and Servers

Departmental computers are accessed by ssh, either by strong public key authentication, or a combination of password and 6-digit authentication code (TOTP).

  • TOTP: (authenticator device) can use a public channel, and has a shared secret.
  • Public-key: can use a public channel and the secret is not shared — a public version of the secret is shared.
  • Password: requires a private channel and a shared secret.

The department is accessed from the outside by gateway machines. From the gateway machine, you can log on to other department computers.

Authentication Mechanisms

TOTP authentication

The Time-Based One-Time Password Algorithm (TOTP) is an Internet standard implemented in software such as google's authenticator and in hardware such as Yubikey 5C.

Google-authenticator Icon
  1. Create the secret. These parameters are anyway the defaults,
    
    % google-authenticator -td -w 3 -r 6 -R 30
    % cat .google-authenticator
    ABCDEFGHIJKLYMNOQRSTUVWXYZ
    
  2. The program presents a QR-code encoded version of the string
    
    otpauth://totp/pikachu@bragg?secret=ABCDEFGHIJKLYMNOQRSTUVWXYZ
    
  3. Or the secret can be entered manually.
The protocol uses a cryptographically strong hash function to calculate a code derived from the current time and a shared secret. The two parties use the code over a public channel to confirm they know the secret.

The standard has several configurable parameters. Our systems uses the defaults,

  • Time based (as opposed to HOTP)
  • SHA-1 hashing to create the code
  • 6 digits in a code
  • 30 seconds for each code
On the server, you create or renew your google authenticator secret by running google-authenticator. When run, program creates a secret and places it in the file ~/.google_authenticator.

On the client, the QR-Code is scaned to transfer the secret into your google-authenticator on your phone, or your Yubikey, using the Yubikey app. Or the secret, represented as a long sequence of letters, can be entered manually. The secret can be entered into as many devices as you wish — they all follow the same standard and they will all produce identical codes.

On new account creation, you may be given the secret as a character string, to enter manually into your devices.

SSH Public-key authentication

Public-key authentication is preferred when you are logging in from a device which can run the ssh protocol and can keep secret the secret key.

  1. Generate the key pair,
    
    % cd ; cd .ssh
    % ssh-keygen -t ed25519 -f id_ed25519_pikachu -C pikachu@cs.miami.edu
    Generating public/private ed25519 key pair.
    Enter passphrase (empty for no passphrase): 
    Enter same passphrase again: 
    Your identification has been saved in id_ed25519_pikachu
    Your public key has been saved in id_ed25519_pikachu.pub
    % chmod 0600 id_ed25519_pikachu 
    % cat id_ed25519_pikachu.pub 
    ssh-ed25519 AAAAC3NzaC1lZDI1NTE.....79G431HJDL8ThuqocX7Ytv pikachu@cs.miami.edu     
    
  2. On the target machine, x.y.z, allow logins on proof of knowledge of the private key,
    
    cat id_ed25519_pikachu.pub  >> ~/.ssh/authorized_keys
    
  3. Log in,
    
    ssh -i ~/.ssh/id_ed25519_pikachu pikachu@x.y.z
    

In Step 1, the program ssh-keygen creates a pair of keys,

  • the secret key that must be kept secret,
  • and the public key that can be made public.

The keys will have the same name but the secret except for the extension .pub on the public key. The private key file must have permission 0600, read-write only for user.

In Step 2, the public key is placed into the ~/.ssh/authorized_keys file of the target machine. During the ssh authentication protocol, the public key is used in an interactive proof that the other side has knowledge of the secret key. It is computationally infeasible to learn the private key from the public key, or from observing the any large number protocol messages, or from maliciously manipulating the protocol messages.

On new account creation, the administrator might ask for your public key, and they will include it in your authorized_keys. Then there will be no need for an initial auto-generated password that needs to be sent to you by a secure channel.

Windows users are encouraged to use WSL to get unix implementation of ssh. However, it is an Internet standard (RFC's 4250 through 4254), so Windows-native implementations should exist.

scp, the SSH config file, and other helpful topics,

  • The ~/.ssh/config file to shorten you command to, ssh my-host
  • scp, the secure copy protocol for file transfers such as, scp here-file.txt pikachu@x.y.z:there-file.txt.
  • The known_hosts file, and how you know who you are talking to.
  • ProxyJump, a possible technique in the config file that allows hopping through several machines, for login or for secure copying.
There is a longer page on these subjects.

Password authentication

Within the department, many logins are secured with a password. For access from outside, passwords are used with an Authenticator for a 2FA authentication requirement.

Generating a strong password is difficult. A program picking randomly from a list of about 2000 words, combining 3 words and a tag of one capital letter and 2 digits gives 44 bits of entropy. According to this research, a bank of 12 RTC 4090's can crack these passphrases in about a month. Four words, a capital letter and 3 digits, gives a passphrase of 58 bits of entropy. These will take over 1000 years to crack.

The authenticator gives resilience against poor passwords; the password gives resilience against a lost authenticator.

To learn more about diceware passphrases and to download software,

Computer Resources

Gateway machines:

These machines are accessed with ssh from the Internet. Once logged in, other departmental computers are available. You will need accounts on those machines, separately from the account on the gateway.

Lab machines:

These are the Dell Precision 3680's in the Ungar 305. They have RTX 4000 Ada Generation GPU's, 64G of RAM and 1T NVMe drives. Some are Ubuntu, and some are Mint.

Receiving an account on these machines is separate from the account on the gateway machine. For these machines, the user's home directory is imported onto the lab machine from the fileserver johnston.

The names of these machines are hyphenated pairs, the first of the pair chosen from,

  • red, ora, yel, gre, blue
and in second of the pair chosen from,
  • red, orange, yellow, green, blue
For instance red-blue, blue-green, ora-orange are all Precision 3680's with RTX 4000 GPU's.

Data science machines:

The department also has advanced servers Rosecrans, Sickles, Thoreau and Emerson. Sickles has two P100's, Thoreau has four A100's, and Emerson has for H100's. The professor advising your project will request access to these machines and inform you of its use-policies.

Be aware of the backup policies and the different file systems,

  • Home directories,
  • Lab and Common directories,
  • Scratch filesystems.
There can be these disk technologies for a file system,
  • HD: a.k.a. "spinning rust". The largest and slowest.
  • SSD: solid state drives. Faster.
  • NVMe: also solid state but faster still, as the bus interface has been revised to exploit SSD memory.
In general, big data is not backed up. Please backup your sources to (for example) github.

You might have group rights to common data areas. Please discuss with your project advisor on how to make best use of the computer resource using these common areas.

 
Powered by Open Source Software. Theme adated from Shlomi Noach, openark.org