Operating Systems 2022F Lecture 9

Video

Video from the lecture given on October 6, 2022 is now available:

• video
• auto-generated captions

Video is also available through Brightspace (Resources->Zoom meeting->Cloud Recordings tab)

Notes

Lecture 9
---------
Admin stuff
 - Assignment 2 is due Tuesday
 - Midterm is Thursday
 - Monday is Thanksgiving
 - please get your T3 and T4 checked off by the end of tomorrow if possible, as
   TA's aren't working Monday and it has to be done by 11:30 AM on Tuesday

Today I was going to
 - answer questions on T3, T4, and A2
 - talk about ssh


Format of the midterm
 - same as assignment, except will be a PDF you download via brightspace
 - answers uploaded as a text file
 - you'll have 80 minutes (class time)
 - open book, open note, open internet
    - but NO COLLABORATION
 - I will be the lecture zoom to answer questions during the midterm, but you
   don't need to show up
 - I'll also answer questions via PM on Teams
 - remember I'll be holding randomized interviews after the midterm is graded
   - you may volunteer for interviews, this is where I'll regrade
 - remember questions are based on the material in the assignments, not the tutorials
   - tutorials cover more material than the assignments


dup2
 - when you open a file, it gets an arbitrary file descriptor
   (well, the next available one generally but you can't count on it)
 - you use dup2 to copy a file descriptor to a specific one
 - so this is how you open something on 0, 1, or 2
    - open first,
    - then dup2 to 0, 1, or 2 (or any specific file descriptor)

When answering programming questions
 - describe at a high level what you did
 - then include code snippets and explain where they should go in the program
   (line numbers/and or context, just make it clear)


Going back to A1, if you omit the call to wait, you'll get zombies
 - that will last until 3000menu terminates
 - because wait is how we eliminate zombies
 - zombies are just child processes that have terminated
   but are waiting around to give their return value

Before ssh, there was telnet and rlogin/rsh
 - simple TCP/IP connections to a server, plain text
 - authentication was either
    - telnet: type in the right password (in the clear to the server)
    - rsh/rlogin: password, or coming from trusted host (IP address)
 - problem: anyone could listen in and capture passwords,
   or could just impersonate another host

ssh is a secure version of rsh
 - basic syntax is very similar, but has many more options


basic syntax: ssh [user@]<host> [command]
 - no command, you get a login shell

Underlying ssh is public key cryptography ("certificates")

Classic cryptography is based on shared secrets, like a password
 - both parties know the secret
 - relationship is "symmetric"

Symmetric cryptography can be VERY secure, but it has one fundamental weakness
 - how do you get the secret to be shared in the first place?


Public key cryptography changes the game
 - instead of a shared secret, we have two pieces of information
   - a public part, that can be shared with everyone
   - a secret part (keep it private)

The cool thing about these is that
 - what one can do, the other can undo
 - so if you encrypt with the secret part, you decrypt with the public part
 - and vice versa

If I publish my public part as my public key or "certificate"
  - certificate is a public key + metadata, like my name & email address
Then anyone can use my certificate to send me a secret message
  - only I can decrypt, because only I have the private part

Similarly, I can digitally sign anything
 - I create the signature using my private key
 - Anyone can verify the signature using the public key

(in reality we often have different algorithms for encryption & signing)

So what are we doing with SSH?
 - the server and the client both have public keys (some short, some long term)
   that they exchange
 - they use these to set up a shared secret key
 - this key is used to encrypt the entire communication

So, how do you know you're talking to the right server?
 - they have the "right" secret key corresponding to a known public key
    (stored in .ssh/known_hosts on the local system)
 - it is saved on first use

how does the server know you're an authorized user?
 - you enter your password
 - you show that you have the secret key corresponding to the public
   key on record for this account
    (stored in .ssh/authorized_keys on the remote system)
 - we manually put the key in this file

So what about certificate authorities?
 - they just sign certificates, i.e., they vouch for them
 - so instead of saving on first use or transferring manually,
   we just check the signature and see if it has been signed by
   someone we trust
 - browsers include the certificates of many CAs
   - so your browser trusts the certificates presented by any website
     that has been signed by one of these CA's public keys
   - if this fails, you get a warning about an insecure connection


Some public key algorithms are relatively simple to implement
 - such as RSA

DO NOT IMPLEMENT YOUR OWN CRYPTOGRAPHY
 - don't make up your own algorithms
 - don't just implement your own version of known algorithms
MANY MANY attacks, you'll mess things up, and it can lead
to catastrophic failures