https://homeostasis.scs.carleton.ca/wiki/index.php?action=history&feed=atom&title=Operating_Systems_2022F_Lecture_9 2026-04-05T22:41:58Z Revision history for this page on the wiki MediaWiki 1.42.1 https://homeostasis.scs.carleton.ca/wiki/index.php?title=Operating_Systems_2022F_Lecture_9&diff=24101&oldid=prev 2022-10-06T19:48:45Z

<p>Created page with &quot;==Video== Video from the lecture given on October 6, 2022 is now available: * [https://homeostasis.scs.carleton.ca/~soma/os-2022f/lectures/comp3000-2022f-lec09-20221006.m4v video] * [https://homeostasis.scs.carleton.ca/~soma/os-2022f/lectures/comp3000-2022f-lec09-20221006.cc.vtt auto-generated captions] Video is also available through Brightspace (Resources-&gt;Zoom meeting-&gt;Cloud Recordings tab) ==Notes== &lt;pre&gt; Lecture 9 --------- Admin stuff - Assignment 2 is due Tues...&quot;</p> <p><b>New page</b></p><div>==Video==<br /> <br /> Video from the lecture given on October 6, 2022 is now available:<br /> * [https://homeostasis.scs.carleton.ca/~soma/os-2022f/lectures/comp3000-2022f-lec09-20221006.m4v video]<br /> * [https://homeostasis.scs.carleton.ca/~soma/os-2022f/lectures/comp3000-2022f-lec09-20221006.cc.vtt auto-generated captions]<br /> Video is also available through Brightspace (Resources-&gt;Zoom meeting-&gt;Cloud Recordings tab)<br /> <br /> ==Notes==<br /> <br /> &lt;pre&gt;<br /> Lecture 9<br /> ---------<br /> Admin stuff<br /> - Assignment 2 is due Tuesday<br /> - Midterm is Thursday<br /> - Monday is Thanksgiving<br /> - please get your T3 and T4 checked off by the end of tomorrow if possible, as<br /> TA&#039;s aren&#039;t working Monday and it has to be done by 11:30 AM on Tuesday<br /> <br /> Today I was going to<br /> - answer questions on T3, T4, and A2<br /> - talk about ssh<br /> <br /> <br /> Format of the midterm<br /> - same as assignment, except will be a PDF you download via brightspace<br /> - answers uploaded as a text file<br /> - you&#039;ll have 80 minutes (class time)<br /> - open book, open note, open internet<br /> - but NO COLLABORATION<br /> - I will be the lecture zoom to answer questions during the midterm, but you<br /> don&#039;t need to show up<br /> - I&#039;ll also answer questions via PM on Teams<br /> - remember I&#039;ll be holding randomized interviews after the midterm is graded<br /> - you may volunteer for interviews, this is where I&#039;ll regrade<br /> - remember questions are based on the material in the assignments, not the tutorials<br /> - tutorials cover more material than the assignments<br /> <br /> <br /> dup2<br /> - when you open a file, it gets an arbitrary file descriptor<br /> (well, the next available one generally but you can&#039;t count on it)<br /> - you use dup2 to copy a file descriptor to a specific one<br /> - so this is how you open something on 0, 1, or 2<br /> - open first,<br /> - then dup2 to 0, 1, or 2 (or any specific file descriptor)<br /> <br /> When answering programming questions<br /> - describe at a high level what you did<br /> - then include code snippets and explain where they should go in the program<br /> (line numbers/and or context, just make it clear)<br /> <br /> <br /> Going back to A1, if you omit the call to wait, you&#039;ll get zombies<br /> - that will last until 3000menu terminates<br /> - because wait is how we eliminate zombies<br /> - zombies are just child processes that have terminated<br /> but are waiting around to give their return value<br /> <br /> Before ssh, there was telnet and rlogin/rsh<br /> - simple TCP/IP connections to a server, plain text<br /> - authentication was either<br /> - telnet: type in the right password (in the clear to the server)<br /> - rsh/rlogin: password, or coming from trusted host (IP address)<br /> - problem: anyone could listen in and capture passwords,<br /> or could just impersonate another host<br /> <br /> ssh is a secure version of rsh<br /> - basic syntax is very similar, but has many more options<br /> <br /> <br /> basic syntax: ssh [user@]&lt;host&gt; [command]<br /> - no command, you get a login shell<br /> <br /> Underlying ssh is public key cryptography (&quot;certificates&quot;)<br /> <br /> Classic cryptography is based on shared secrets, like a password<br /> - both parties know the secret<br /> - relationship is &quot;symmetric&quot;<br /> <br /> Symmetric cryptography can be VERY secure, but it has one fundamental weakness<br /> - how do you get the secret to be shared in the first place?<br /> <br /> <br /> Public key cryptography changes the game<br /> - instead of a shared secret, we have two pieces of information<br /> - a public part, that can be shared with everyone<br /> - a secret part (keep it private)<br /> <br /> The cool thing about these is that<br /> - what one can do, the other can undo<br /> - so if you encrypt with the secret part, you decrypt with the public part<br /> - and vice versa<br /> <br /> If I publish my public part as my public key or &quot;certificate&quot;<br /> - certificate is a public key + metadata, like my name &amp; email address<br /> Then anyone can use my certificate to send me a secret message<br /> - only I can decrypt, because only I have the private part<br /> <br /> Similarly, I can digitally sign anything<br /> - I create the signature using my private key<br /> - Anyone can verify the signature using the public key<br /> <br /> (in reality we often have different algorithms for encryption &amp; signing)<br /> <br /> So what are we doing with SSH?<br /> - the server and the client both have public keys (some short, some long term)<br /> that they exchange<br /> - they use these to set up a shared secret key<br /> - this key is used to encrypt the entire communication<br /> <br /> So, how do you know you&#039;re talking to the right server?<br /> - they have the &quot;right&quot; secret key corresponding to a known public key<br /> (stored in .ssh/known_hosts on the local system)<br /> - it is saved on first use<br /> <br /> how does the server know you&#039;re an authorized user?<br /> - you enter your password<br /> - you show that you have the secret key corresponding to the public<br /> key on record for this account<br /> (stored in .ssh/authorized_keys on the remote system)<br /> - we manually put the key in this file<br /> <br /> So what about certificate authorities?<br /> - they just sign certificates, i.e., they vouch for them<br /> - so instead of saving on first use or transferring manually,<br /> we just check the signature and see if it has been signed by<br /> someone we trust<br /> - browsers include the certificates of many CAs<br /> - so your browser trusts the certificates presented by any website<br /> that has been signed by one of these CA&#039;s public keys<br /> - if this fails, you get a warning about an insecure connection<br /> <br /> <br /> Some public key algorithms are relatively simple to implement<br /> - such as RSA<br /> <br /> DO NOT IMPLEMENT YOUR OWN CRYPTOGRAPHY<br /> - don&#039;t make up your own algorithms<br /> - don&#039;t just implement your own version of known algorithms<br /> MANY MANY attacks, you&#039;ll mess things up, and it can lead<br /> to catastrophic failures<br /> &lt;/pre&gt;</div>

Soma