Intro to SSH and SSH Keys

[@mattjoe67]

Thank you very much for simple and extremely easy way explaining SSH, some instructors or professors make things very difficult for their students, those instructors want to feel important and smart by not sharing the simple and easy method with their students, I hope you make more videos thank you, Sir.

[@PaulTurnerChannel]

Thank you very much for the feedback. I'm sorry that I didn't respond earlier. I really do appreciate it.

[@Thmyris]

Big ego teachers are indeed super annoying. I'm in love with some of my teachers who have big stats in humility, like this youtuber :)

[@punjabimitti]

Excellent presentation with soothing voice, context, perspective and technical details.

[@PaulTurnerChannel]

I’m glad you liked it, Sunil. Thanks for the kind words.

[@אליהובראל]

I've searched lot of videos, and this is the first one that explain this topic so well. Very good explanation, it helped me alot. thanks

[@ayasswain]

Excellent video on SSH. Very nice explanation.

[@PaulTurnerChannel]

Thanks a bunch for the feedback, Ayaskant.

[@abhi_galav]

This is certainly the best explanation on this topic

[@PaulTurnerChannel]

Thanks a bunch, Abhishek

[@shivmmehrotra]

By far best video on ssh keys on youtube

[@PaulTurnerChannel]

Wow, Shivam. That is quite a compliment. Thank you very much for taking the time to provide your feedback. I’m glad you liked it.

[@pkelly20091]

You have a great ability in explaining things in a simple way which is refreshing

[@PaulTurnerChannel]

Thank you very much for the feedback. It means a lot to me. I'm glad you found the videos helpful.

[@cyberguide_in]

Wow... an extremely insightful video.

[@PaulTurnerChannel]

Thank you, One Step Ahead. I’m glad you found it helpful.

[@ameyapatil1139]

Absolutely brilliant ! Helped my understand this vague concept in just few minutes

[@piyushkhare3394]

Please make more videos...Thanks a lot for this video.....

[@PaulTurnerChannel]

Thank you for the feedback, Piyush!

[@sergeiromanoff]

Great video! The only thing worth mentioning is the relation between the private and public keys. A message encrypted with the private key can be decrypted only with the corresponding public key. And the public key can decrypt only those messages encrypted with the corresponding private one.

[@ayasswain]

You nailed it. I was also thinking about the same. He should have told this in this video. But still its a great video. He has explained the concept quite well.

[@dmitryrukavishnikov6711]

Did you mean that private key can decrypt messages encrypted with corresponding public key in your last sentence ?

[@Beliedat]

Umm no asymmetric cryptography works differently...the private can ONLY decrypt and the public key can ONLY encrypt. The public key cannot decrypt a message it has encrypted (if it could that means anybody with the public key could decrypt a message encrypted by another user with the same public key)

[@iamsiddhantsahu]

Superb explanation, cleared all my doubts about ssh!

[@PaulTurnerChannel]

Wow. Thanks, Siddhant.

[@lesliedrozario5890]

Excellent explanation Paul. I am just about stepping into SSH world and your video has given me a great start. Make more videos if possible :P

[@PaulTurnerChannel]

The SSH world is awesome. Lots to learn and endless challenges ;-). I’m sure you’ll enjoy it. You might look up the NIST document that Tatu and I co-authored with NIST. You might find it helpful. I’ll do my best to get a couple of videos out this summer. This darn day job keeps me busy, and it’s lots of fun ;-)

[@lesliedrozario5890]

@@PaulTurnerChannel Indeed, the little that I have picked up from your videos makes me believe it's going to fun working on SSH 😉. BTW... Where can I find the NIST document you mentioned. Please guide if possible 🙏

[@PaulTurnerChannel]

nvlpubs.nist.gov/nistpubs/ir/2015/NIST.IR.7966.pdf For some reason, it was slow to download this morning.

[@lesliedrozario5890]

@@PaulTurnerChannel Thanks a ton

[@Marceau.]

you should make more videos, they are really well done :)

[@the-sunny-side-up]

Lively and lucid, as always!! Thanks Paul for making my life so easy :)

[@PaulTurnerChannel]

Wow! If I’m making your life easy, I have to go back and watch that video. I need some of that ;-) Seriously, thanks for your generous comment, Arkadeep. It puts a big smile on my face.

[@lubeda04]

Very good introduction to this technology. It helped me a lot.

[@PaulTurnerChannel]

Glad it was helpful, Ludger. Thank you for taking the time to provide the feedback.

[@chandrasekharavajpayeemadd2494]

are these keys persistent ? What should we do make sure keys are persistent?

[@davidstandish1482]

Thx for posting Paul. Nice primer.

[@tapsulinka]

SSH was developed by Tatu Ylönen. He was my friend at student time 😊😊

[@PaulTurnerChannel]

Thank you for sharing that you were in school with Tatu! He clearly has been a leader in a variety of areas of security.

[@ujjwalghatak3787]

very good, thanks for sharing your knowledge

[@PaulTurnerChannel]

Thank you for your comment, Ujjwal. I appreciate it.

[@KeepItTechie]

Great video Paul. I really enjoyed how you broke SSH down.

[@PaulTurnerChannel]

Thanks a bunch for the feedback, KeepItTechie.

[@RajanSingh-kr7pg]

Thanks for the concept. Very nicely done !!

[@PaulTurnerChannel]

Glad it was helpful, Rajan.

[@JohnKatiku]

This is a Good Listen Thank you. Is there an update to this can follow and how to mitigate the risks ..?

[@PaulTurnerChannel]

I’m very sorry for the slow response, Katiku. I created two other videos that discussed SSH components, risks, and best practices. The first one is here: kzbin.info/www/bejne/honMXmZvmtGlbLs The second one is the furthest I’ve gotten on providing suggestions for addressing the risks in my videos. It is here: kzbin.info/www/bejne/mqObiGZqncaoqsU If you’d like a copy of the spreadsheet that is used for the metrics, reply to this comment and I’ll see what I can do. Thank you very much for taking the time to reach out.

[@inderdhami2001]

Best video on How SSH really works.. thanks!! Is there any video on resolving the plethora of keys or inventory management?

[@PaulTurnerChannel]

Thanks for the feedback, Inderpal. I've been remiss in getting that video done. I'll work on getting something uploaded soon. Thanks again.

[@RayAvijeet]

Q. What happens if the public-key received in the very first connect instance is another server’s ? Could the security of the intended server be compromised ? How would an intermediary server be able to hack in then ? Pls explain briefly if possible to make it crystal.

[@PaulTurnerChannel]

Thanks for your question, Avijeet. For starters, this attack assumes that the attacker is able to get the user's client to redirect them to their server (rogue-server) instead of the server they intended to connect to (good-server). This would most likely be done by manipulating ARP or DNS (which is not necessarily trivial). With that said, here are the steps: 1. User1 enters "ssh user1@good-server" on their workstation to login to good-server. 2. User1 is redirected to rogue-server (based on the ARP or DNS manipulation above). 3. User1 is prompted by their ssh client to confirm the public key for "good-server" (though it is actually the public key for rogue-server). User1 doesn't double check to ensure that is the correct public key for good-server and responds "yes" to their client. The client stores that as the correct public key for good-server. 4. rogue-server then prompts user1 for their password. User1 enters their password into their ssh client, which is then sent to rogue-server. 5. While user1 is awaiting a response from rogue-server (thinking that it is actually good-server), rogue-server initiates an ssh connection to good-server (e.g., using a command like "ssh user1@good-server"). 6. good-server prompts rogue-server for the password for user1. 7. rogue-server provides the password they received from user1 to good-server. 8. good-server returns a prompt to rogue-server. 9. rogue-server returns the prompt provided by good-server to user1. 10. As user1 starts to enter commands, rogue server passes those commands to good-server and the responses provided by good-server verbatim (so that user1 doesn't know that rogue-server is actually in the middle). Hope this helps.

[@thedr00]

This was excellent. Thank you for sharing.

[@PaulTurnerChannel]

Thanks a bunch for taking the time to send a comment. I really appreciate it. I’m glad it was helpful.

[@zj4678]

You may want to annotate the video. Windows 10 supports SSH client and server natively :)

[@PaulTurnerChannel]

Zaid, good point. Thanks for the feedback.

[@wirelessnerd7131]

Thanks Paul. Very well explained.

[@PaulTurnerChannel]

Thanks for the feedback, Wireless. I’m glad you liked it.

[@mdshoaug9019]

@@PaulTurnerChannel van ons land en

[@PaulTurnerChannel]

@@mdshoaug9019 You have me stumped. Is that Dutch?

[@marcoangelo]

man, turn your audio up

[@PaulTurnerChannel]

Thanks, Marco. That was one of my earlier videos before I understood that my phone headset wouldn't hack it as a recording device. Some of us are slow to learn. I appreciate the feedback.

[@marcoangelo]

Paul Turner sorry hope I didn't sound too rude. Thank you.

[@PaulTurnerChannel]

Not at all. I appreciated the feedback. Thanks

[@agfagaevart]

cool soothing HAL 9000 type voice... :-)

[@JohnKatiku]

@@PaulTurnerChannel You made it audible too thank you.

[@ibrahimmarin3541]

You make it very easy to understand! Great Job!

[@ErsanYolcu]

Amazing explanation. Thanks a lot for the time you have spent to share all these information.

[@PaulTurnerChannel]

Thank you for the feedback, Ersan. I really appreciate it.

[@MidwestDIY]

It looks like Windows 10 (as of January 2018) come with SSH as an optional feature in beta version

[@PaulTurnerChannel]

Thanks for the note, Arlan. Yes, it looks like Microsoft is finally embracing SSH (the Powershell team at Microsoft has been pushing for this for a while). It will be interesting to see how rapidly it gets adopted in enterprises. I may have to edit my video to change the "If it is not Windows..." message :-) Thanks again.

[@shashivardhan6541]

Thank you sir

[@PaulTurnerChannel]

Thank you, Shashi. I appreciate you taking the time to comment!

[@juanjosecastro2178]

Nice video. I use public/private keys in openvpn software. But i was wondering how it works on cisco or other network devices since the user who logs into it via ssh doesn't have a private key, he or she, only types the username/password.

[@PaulTurnerChannel]

Sorry for the very slow response, Juan Jose. The default for SSH is to use a username and password. When a client connects and accepts the server's public key, the client and server are able to establish a secure connection via Diffie-Hellman (a cryptographic algorithm used by SSH to establish a session key between the client and server). The user is then able to enter their username and password and it is transferred safely across the encrypted connection. Most SSH systems provide the option to use SSH public key authentication, where an authorized key is placed on the server, as described in this video. I hope this helps.

[@gissc-globalitsecuritysolu2163]

Very good overview..

[@PaulTurnerChannel]

Thank you very much for the feedback.

[@liliacfury]

What’s the purpose of the servers having their own private key? (The orange and blue, not the green.) Now, I understand the purpose of the administrator having a private key, it is needed to initiate the process of the server authenticating that said administrator can be trusted, but why does the server need a private key? The server asks us if we trust it, so does the private key give an extra warning that we can trust it (without it it would give us an extra warning that we can’t trust it?), and it’s just double checking with us (via a prompt using the server’s public key) to make sure that we do trust it? Also, just to clarify, are all of these SSH keys? And similar to public keys from servers needing to be manually verified by the administrator (via prompt), do the servers need to have the administrator manually place their user keys (grey) onto the servers’ authorized keys file? Or is it automated when the server identifies that the user owns a private key?

[@PaulTurnerChannel]

These are great questions. #1 - Purpose of Server Private Key: The server authenticates that they are the holder of the public key by signing something for the client with their (the server's) private key (the server public and private keys are mathematically/cryptographically related so that this can be done). Let's say that the client has Server1's public key from a previous connection and later connects to an attacker's server attempting to act as Server1. Since the attacker's server doesn't have the private key that matches Server1 public key, it can't provide a valid digital signature (signing something unique to the session) during the SSH session establishment. Consequently, the client will throw an error and not continue with the connection. #2 - Are these all SSH keys: Yes. All of the keys described in the presentation are SSH keys. And, as you say, the server looks for user public keys placed in authorized_keys files. It uses these public keys to validate that the clients have the corresponding private keys in their possession (using digital signatures as described in the first paragraph above but in the opposite direction, client to server). You also ask about who places the public keys. First, yes, unique client public keys must be explicitly placed in each user's .ssh/authorized_keys file (each matching the private key that the user holds). How these keys get place in the authorized_keys files depends on the policy of the organization. They can be: 1) installed by each user (which is not a recommended practice and should be prevented through configuration), 2) installed by the administrator can manually place them, or 3) they can use an automated system to provision and manage the user public keys. I hope this helps. Please don't hesitate to ask for further clarification if anything didn't make sense.

[@bigo025]

Can somebody tell me why did he create a new key pair on server 2 to communicate with server 1, instead of using the old key pair ? Thank you

[@PaulTurnerChannel]

Thanks for the question, Kmer. My understanding of your question is you're wondering why the User Keys labeled "A" above Alice are not also used for the User Keys labeled "2" above Server2. The reason is that the User Keys labeled "A" are used by Alice for her access. The User Keys labeled "2" are used by an automated application on Server2 to access Server1. I realize now that is a little confusing. You might want to watch my other video on the Major Components of SSH (kzbin.info/www/bejne/honMXmZvmtGlbLs), which may provide a better explanation. The basic rule is that every entity (whether User or Automated Process) should have its own user keys. Alice has a User Key labeled "A" to access Server1 and Server2. The automated process on Server2 has a different User Key labeled "2" to access Server1. I hope that makes sense.

[@bigo025]

Paul Turner it is everything clear now thank you.

[@arisgreek8697]

@@PaulTurnerChannel what i do not understand is why should server2 create a new key pair for its interaction with server1? I would expect each entity (laptop,pc,server etc) to create only one asymmetric keys pair for all its ssh (whether it will be a client or a server) interactions.

[@PaulTurnerChannel]

@@arisgreek8697 This is a very good question. It is possible to use the host key, used when acting as a server, for client authentication with other systems (acting as servers). That mode is called host-based authentication mode. Generally, it is not recommended. As background, there can be multiple accounts (users and apps) on a system that are able to use SSH. When you configure a system to use host-based authentication, it makes it more difficult to determine which account performed operations. In general, you want to make sure you can clearly see what operations have been performed by each account on a system (since each account has unique credentials and you want to be able to identify who might have done something wrong, etc.). The following paper has a bit more information on this: nvlpubs.nist.gov/nistpubs/ir/2015/NIST.IR.7966.pdf. I hope this helps. Please tell me if I didn't answer your question clearly.

[@amula5939]

can server2 use its Server keys to communicate with server1 instead of User keys?

[@PaulTurnerChannel]

Sorry for the slow response, Amanuel. You can use host-based authentication to authenticate clients (users or automated processes authenticating to another system that is acting as an SSH server). This is not really a recommended method of authentication, as you can't configure command restrictions and there are other limitations. There is a bit more explanation in nvlpubs.nist.gov/nistpubs/ir/2015/NIST.IR.7966.pdf if you're interested.

[@deepakevgoogle]

Well explained. Thank you.

[@PaulTurnerChannel]

Thank you for taking the time to comment, Deepak. I'm glad you liked it.

[@kalyanhr]

very well explained!!

[@PaulTurnerChannel]

I’m glad it was helpful, Kalyan. Thanks for the feedback.

[@alexperez85]

awesome stuff

[@alexperez85]

any part 2?

[@PaulTurnerChannel]

Hey, Alex. Sorry for the slow response. The best I have so far for Part 2 are: kzbin.info/www/bejne/gHzVgGiNdqeXpbs kzbin.info/www/bejne/honMXmZvmtGlbLs kzbin.info/www/bejne/mqObiGZqncaoqsU I'm hoping to get some other material done but this darn day job keeps getting in the way :-) Thanks a lot for the feedback!

[@researches_technical_stuff7392]

TLS is Transport Layer SECURITY, not Transport Layer Services.

[@PaulTurnerChannel]

Doh! Good catch. I can't believe I included in the video.

[@researches_technical_stuff7392]

This is still a superior explanation of the topic, and a good resource. Engineers misspell, misspeak, and flub terminology while still being competent. Thanks for the good work

[@IsmailMohammedi4ismail]

great video ! :-)

[@PaulTurnerChannel]

Thank you very much, Ismail.

[@Manch271]

Thanks.

[@AbuSaud.Christos]

what are keys ? :D

[@PaulTurnerChannel]

Thankks for your comment and question, Mahmmad. I have another video that provides a basic introduction to algorithms, keys, and certificates at kzbin.info/www/bejne/p2rZpmmVZ9djpZY. Not sure if this is what you were looking for. Thanks again.

[@engalipak]

I maybe the odd one out here. But the keys explanation didn't make any sense to know how they work step by step.

[@PaulTurnerChannel]

Hi, Ali. I’ve created another video (kzbin.info/www/bejne/honMXmZvmtGlbLs) that provides a slightly different explanation. If that is not helpful, what were you looking to understand that is not covered?

[@Hairregrowthjourney]

I can't hear ya

[@PaulTurnerChannel]

:-). Thanks, Saurabh. This was one of my very first videos, before I understood the importance of a good microphone. Sorry about the poor audio quality. Thanks again.

[@PepeAlwaysLoses1]

WHAT, I CANT HEAR THEM, WHAT ARE THEY SELLING?!

[@PaulTurnerChannel]

Timothy, I don't understand your comment. Did you have trouble hearing the audio? Also, did you get the impression I was trying to sell something?

[@PepeAlwaysLoses1]

Yes. I was satirizing the low audio in the video. It is an internet meme. Thanks for having me explain it.

[@sdfasdfsdfklsdfjklsdflsdkl377]

your video takes 13:37 minutes :p

[@PaulTurnerChannel]

Yes, it is quite long. I have a problem communicating concepts in a succinct manner. Still working on that. Thanks.

[@NadeemInamdar]

Good video. But the voice of the narrator is feeble.

[@PaulTurnerChannel]

Nadeem, when I read your comment this morning, it caused me to break out laughing out loud. I haven’t been called feeble too often. I apologize for the poor audio. I recorded that video before I understood the importance of a good microphone, though I may still sound feeble in some of my other videos as well. At any rate, I appreciate you taking the time to comment and give me a good laugh (I didn’t take your comment as a slight). I wish you all the best. Thank you.

[@luacode.x1249]

It's a joke, right? Only 446 subscribers? This is as unfair as, lets say, Jesus scarifying himself in solitude and being forgotten by men or history. People are stupid. SSH IS GREAT! And wait, did I write 446? I meant 447, mb ;)

[@PaulTurnerChannel]

Thanks for your comment, Lua, and for subscribing. It is safe to say that Jesus is in a completely different league :-)

[@junjecguatno8584]

come on dont be shy turn yo voice up for god sake

[@PaulTurnerChannel]

Sorry, Honhek. This was one of my first videos, before I understood the importance of a good mic. I got a better mic a little later so my other videos hopefully have clearer audio. Thanks for watching and enduring the poor audio.

[@junjecguatno8584]

all good man, keep up the good work. cheers

[@aathithrajendran6463]

audio sucks

[@PaulTurnerChannel]

Thanks for taking the time to provide feedback. This was one of my first videos, before I understood the importance of a good mic. Sorry that the audio is not good in the video.