The client doesn't send the secret back to the server, because the secret could be stollen this way. It uses the secret to encrypt the rest of the communication.
@@NetworkInfo No verification is needed because the rest of the communication will be encrypted. If the client was not able to get access to the key, it wouldn't be able to continue the communication. The fact that client can now send encrypted messages to server and the server can decrypt them proves that the client was legit hence able to get access to the secret key.
@@rakeshshiva625 there are two, the server's public key will be used by client to encrypt the message and the server's private key will be used by the server to decrypt them, so asymmetric.
great explanation! Your video provided the most important fragments of information which other videos lack, for ex:- you mentioned the key being a cipher and you explained which software are used in these different OSes. Thanks And Keep up the good work!
Correct me if I am wrong please? The step that I always missed understood was section 4:36.... 1. A public key is created by the client 2. And some how this newly created client public key is provided to the server to keep 3. Then when the client ssh(s) into the server, it sends the public key it has while connecting 4. The server receives the connection request "and" compares the public key being received with the once the server has on a list 5. If the keys match, then the server sends "its own" public key back the client 6. The client accepts the servers public key and connection is made If the process describe above is correct, then this means that servers have to have a way of accepting (someone approves) public keys from clients (step number 2 above) so that it compares when being used?
Thanks for your love and support, keep learning. Follow bitfumes on twitter.com/bitfumes or facebook.com/Bitfumes to get the latest updates. bitfumes.com
In the video it is mentioned that at last the secret is sent back to server so server can identify the client. This secret can hacked. How it is avoided. Adding that to the video would make it complete.
Thanks a lot. This is exactly the information I was looking for. Most videos assume I already know what a public and private key is so thanks for clearing everything from the ground up.
Thanks for the details.. one query how does it know the first time which public key to pick for a new request .. what is that id against which the public key is picked for the authentication purpose
Thanks for your love and support, keep learning. Follow bitfumes on twitter.com/bitfumes or facebook.com/Bitfumes to get the latest updates. bitfumes.com
This video is not completely correct ! There is an missing part with the Diffie-Hellmann for the symmetric key wich is used to encrypt the communication. The asymmetric keys are only used for authentication.
The "SSH Working" part gives a wrong explanation. The SSH public key authentication is signature-based challenge response protocol, which can be found in SSH protocol on section 7. The public key encryption and public signature are totally two different things.
I agree. In general the TH-cam video gives a very nice illustration on how SSH keys works. however, I don't agree with the top secret explanation. The "top secret" is a "challenge" generated by server to prove client has a proof of possession of the private key. Once decrypted, client signs the clear text version of the top secret with its private key and sends back to server. Server uses client's public key to authenticate the top secret by verifying the signature. Once the verification is successful, the security channel is established.
Private key can't be shared and private key can only decrypt the data So once, the secure tunnel is established, Does the data sent from client is encrypted using public key? If yes then, how can server decrypt the data, as it does not have the private key of client??
Data is encrypted using the public key. The secret key shared is encrypted using the clients public key, which can only be decrypted using the clients private key
you say that the service is only available when the system starts , is it possible for a admin to use Wake-On-LAN in a Client system while the system in in off and establish the tunnel
Great explanation...... I have a question. When I am already on a linux machine and from there if I want to ssh any other linux machine then I do "ssh -i key.pem ". Here key.pem is private key. In this case how handshake happen as I am not sending Public key ?
thank your for explanation.however, client send topsecret key without hashing? what happens if somebody gets this open topsecret key during sending client to server?
When sending the Top Secret Key back to the server, can't someone intercept it and send it over to the server before you get yours to the server, thus not verifying the correct user?
Old comment but, I think that would be correct. But at that point I don't think any protocol can help you. It is very well the case in practice that services can be denied e.g. DDOS(not that that is the scenario you describe). The point of having such protocols is not to guarantee that the sender and receiver can communicate, but instead that when communication occurs, an interceptor would not be able to extract any useful information. Even without some malicious actor, we can't guarantee that communication works out. Sometimes packets of data just drop th-cam.com/video/7rLROSYcQU8/w-d-xo.html. You can't even guarantee that two computers are absolutely sure that they both agree on something (The Two Generals Problem) th-cam.com/video/IP-rGJKSZ3s/w-d-xo.html A single computer can't even have guarantees about it's current state, like stray cosmic rays can hit the silicon to flip bits. Anyways, though we have a lot of things we can't guarantee, one can attempt to produce the most robust solution possible given the circumstances(and, with some assumptions, prove that it is secure), or we can produce a solution which we believe to have a low probability of failing. Like, it is incredibly unlikely that cosmic rays do flip bits in memory, but even if this was an issue there are ways of using redundancy to lower the probability that we read corrupted data(coding theory and information theory). Quicksort is an example of an algorithm where we choose to take our chances, it hinges on selecting a random pivot, and on average it is a very fast algorithm but if you give it a really inconvenient input list it will have the same time complexity as the naive sorting algorithms(Bubblesort, SelectionSort, etc). To put out one last caveat, we don't even know if cryptography is actually bulletproof :) It's still an open question as to whether P = NP, but if it is and we find a good algorithm for solving NP problems, then we also have a good algorithm for breaking cryptography. Noone's cracked P vs NP yet though, and modern cryptography isn't cracked yet either(or maybe it is and some people have kept that secret really well), soooooooooooooooooooooooooooooooooo it's probably safe. Rant aside, SSH and all other protocols can't guarantee service, but if it is observed that the service is consistently being denied and it's an issue, then either the user or the people who provide the service should investigate and figure out what the root cause is.
Server gets your public key Server encrypts a [challenge] with your public key You decrypt the challenge with your private key(as only your private key will unlock what the private key you shared locked) and send back the challenge Server verified the challenge and established a tunnel
@@yordanibonilla5859 I see, but the question Nabil asks still applies. Basically the situation would become, what if an interceptor responds to the challenge before you do(with an invalid response), resulting in the challenge being failed and you not being verified. Ah, but upon rereading the original comment, it says "not verifying the correct user". I interpreted it as the interceptor preventing you from being verified, rather then the interceptor being verified pretending to be you. But ya, given this procedure they can't beat the challenge the server provides.
@@Vaaaaadim Right and if they the interceptor did send the correct challenge by intercepting yours and it so happens to get there before you wouldn't they just be doing you a favor verifying ya lol?
wow great can you tell me difference between Bash language and puTTY and Command line command prompt. also what connection is there between Bash and Linux. Thanks in advance
Sir, its nice presentation with little diversion!. you said, "Symmetrical encryption can’t be done on remote servers". But you didn't continue the need for SSH with proper justification.
it is the same key everywhere - hence, sharing it becomes increasingly risky with asymmetrical encryption, identity and uniqueness is assigned to a caller
If I have just a LapTop and want to use a SSH just for security can I just Enable the Open ssh on my LapTop. Or do I have to have a server to configure the ssh? I just can't get it right.
I am lost here, Okay remote computer uses public key to encrypt a secret key which is a key to SSH. Well public key is known and so what's the point ...I am lost, please help
@@Bitfumes I searched more about this and found out that the pair of the public and private key are some how mathematically connected, but there is no way to derive one key from another. Whatever is encrypted by public key can only be decrypted by the paired private key.
Server gets your public key Server encrypts a challenge with your public key You decrypt the challenge with your private key and send back the challenge Server verified the challenge and established a tunnel
After connection established we go to folder .ssh(of server) and copy all private keys( which will be encrypted by client public key) and get it into our system 😂 finally we hacked it.
@Bitfumes Webnologies Great explanation! But I have a question, if I am a MITM, I can catch the encrypted "top secret" message from the server (in this state I cannot read the message or get the private key) - but when I am able to catch the decrypted "top secret" that the client send back to the server, I now have the encrypted "top secret" message and the decrypted "top secret" message, and now I can figure out the private key... am I wrong? there is something I miss here?
encryption algorithm which is used in SSH is RSA and it is really hard to guess it, the key itself could be AES-256 encrypted, so it will take few million years to guess
If I use password authentication for ssh session then how the data gets encrypted? In password authentication the client's public key is not present in server.
@@NetworkInfo I believe ssh channel is first established then authentication process starts. Ssh server and client first set up a secret key using Diffie Hellman algorithm and then that key is used to encrypt the channel. Next it asked for authentication method, either password based or ssh key based. That's why ssh key is not necessary for ssh connection. And we will always share client key into server, generating public private key is not necessary in server. For SSL it's different where server's public key is shared with client.
The client doesn't send the secret back to the server, because the secret could be stollen this way. It uses the secret to encrypt the rest of the communication.
@@NetworkInfo No verification is needed because the rest of the communication will be encrypted. If the client was not able to get access to the key, it wouldn't be able to continue the communication. The fact that client can now send encrypted messages to server and the server can decrypt them proves that the client was legit hence able to get access to the secret key.
There is only one secret key. So is it symmetric encryption.
so the server sends back its public key so that the client can encrypt the rest of the data is sends?
@@rakeshshiva625 there are two, the server's public key will be used by client to encrypt the message and the server's private key will be used by the server to decrypt them, so asymmetric.
@@perminusgaita correct
great explanation!
Your video provided the most important fragments of information which other videos lack,
for ex:- you mentioned the key being a cipher and you explained which software are used in these different OSes.
Thanks And
Keep up the good work!
Thanks for watching bro, please like BitFumes on facebook to get latest updates.
amazing explanation! 2 times better than the universities when they explain it. More videos like this please
Lovely video still valid in 2020. Shame most techies fail to explain this in a simple way as you have done thanks.
Wow how simple u made it ........ simply awesome Plz make Somme more videos of this kind
Great and simple explanations! Thank you.
Thanku easy to understand terminology
Correct me if I am wrong please? The step that I always missed understood was section 4:36....
1. A public key is created by the client
2. And some how this newly created client public key is provided to the server to keep
3. Then when the client ssh(s) into the server, it sends the public key it has while connecting
4. The server receives the connection request "and" compares the public key being received with the once the server has on a list
5. If the keys match, then the server sends "its own" public key back the client
6. The client accepts the servers public key and connection is made
If the process describe above is correct, then this means that servers have to have a way of accepting (someone approves) public keys from clients (step number 2 above) so that it compares when being used?
Best video about SSH keys. Thanks a lot!!
Thankyou for great explaination
You opened my eyes to SSH , great explanation
Thanks for watching, please like BItfumes on facebook to get latest updates.
Nicely explained.Thanks!!
It’s symmetric encryption but the key is transmitted via asymmetrical encryption
Great video!!! explaining in a simple way a difficult subject
Thanks for your love and support, keep learning. Follow bitfumes on twitter.com/bitfumes or facebook.com/Bitfumes to get the latest updates.
bitfumes.com
you have explained it very well. Thanks a lot.
Thank you for a wonderful explanation. Bless your heart...
Thanks for watching, please like BItfumes on facebook/twitter to get latest updates.
Thanks for clear view in easy way! 😊
Very well described. and good use of real time IMAGEs.
Only a genius can think of such details.
Thanks
Glad you liked it
Very well explained
seriously man
you made it so easy
thanks 👌👌
Good lesson. You explained it very well. Thank you!
4 videos dekhne ke baad... ab jaake kuch samajh main aaya ...!!! this video gave me a clear picture.... Maybe I have a low IQ..
Thanks 🙏 and Respect from Pakistan 🇵🇰
Thanks, great video! It helped me to get the idea of SSH.
The best explanation I have come across! Thanks :')
In the video it is mentioned that at last the secret is sent back to server so server can identify the client. This secret can hacked. How it is avoided. Adding that to the video would make it complete.
Is the client going to encrypt this secret with the public key provided by the server?
@@wimrotor i have the same exact doubt.. when the client send back the callenge to the server, the client encrypts that challenge into de pub key ???
thank you for the very clear tuto
Many thanks for the summarized explanation!
Glad it was helpful!
Great explanation! Thx :-)
Simple and concise
thank you very much sir
Thanks a lot. This is exactly the information I was looking for. Most videos assume I already know what a public and private key is so thanks for clearing everything from the ground up.
Tq bro, you really explained it in a clear way and easy to understand . Tqtq so much
Thanks for the details.. one query how does it know the first time which public key to pick for a new request .. what is that id against which the public key is picked for the authentication purpose
I have the same question, did you finally get the answer?
Nice explanation
Amazing explanation! :)
Thanks for your love and support, keep learning. Follow bitfumes on twitter.com/bitfumes or facebook.com/Bitfumes to get the latest updates.
bitfumes.com
Thanks for this. Very helpful.
Excellent Specking and Explaining Style. Keep it up brother
great video, thanks.
Well explained
How client share that top secret key with server ?
It might get change during sharing and server will never verify that user
Very clear explanation, thanks!
Thanks for your love and support, keep learning. Subscribe to bitfumes newsletters
bitfumes.com/newsletters
This was great!!! Thank you!!!
What a great explanation! Thank you!
You're very welcome!
Thanks a lot :)
this video help me to understand how SSH works :)
This is great, you're explaining in such a good way!! Thanks a lot
Glad it was helpful!
Clear explanation! Thank you! Please, make examples!))
Great explanation. 👍
Thank you, it's a bit clearer now.
thanks for watching, please check bitfumes.com/courses for more advanced courses
Great video... Excellent work
This video is not completely correct ! There is an missing part with the Diffie-Hellmann for the symmetric key wich is used to encrypt the communication. The asymmetric keys are only used for authentication.
Sweet and short.. Well done
thanks for watching, please check bitfumes.com/courses for more advanced courses
Awesome explanation!!!
Great explanation..thank you!!
Excellent Explination bro
Great 🙏
Thanks for watching bro, keep learning.
For full course checkout bitfumes.com
The "SSH Working" part gives a wrong explanation. The SSH public key authentication is signature-based challenge response protocol, which can be found in SSH protocol on section 7. The public key encryption and public signature are totally two different things.
I agree. In general the TH-cam video gives a very nice illustration on how SSH keys works. however, I don't agree with the top secret explanation. The "top secret" is a "challenge" generated by server to prove client has a proof of possession of the private key. Once decrypted, client signs the clear text version of the top secret with its private key and sends back to server. Server uses client's public key to authenticate the top secret by verifying the signature. Once the verification is successful, the security channel is established.
thank you
Nice video very helpful
Glad it helped
Just what I needed, thanks! :D
Thanks for watching bro, please like Bitfumes on facebook to get latest updates,
the legendary indian programmer
Clear explanation. Thanks.
Thanks bro for watching, keep learning.
Private key can't be shared and private key can only decrypt the data
So once, the secure tunnel is established,
Does the data sent from client is encrypted using public key?
If yes then, how can server decrypt the data, as it does not have the private key of client??
Data is encrypted using the public key. The secret key shared is encrypted using the clients public key, which can only be decrypted using the clients private key
you say that the service is only available when the system starts , is it possible for a admin to use Wake-On-LAN in a Client system while the system in in off and establish the tunnel
Great explanation...... I have a question. When I am already on a linux machine and from there if I want to ssh any other linux machine then I do "ssh -i key.pem ". Here key.pem is private key. In this case how handshake happen as I am not sending Public key ?
thank your for explanation.however, client send topsecret key without hashing? what happens if somebody gets this open topsecret key during sending client to server?
Good video
Update: Windows 10: PowerShell got a ssh-client plugin! Same syntax like Linux
Okay Thanks.
When sending the Top Secret Key back to the server, can't someone intercept it and send it over to the server before you get yours to the server, thus not verifying the correct user?
Old comment but,
I think that would be correct. But at that point I don't think any protocol can help you. It is very well the case in practice that services can be denied e.g. DDOS(not that that is the scenario you describe). The point of having such protocols is not to guarantee that the sender and receiver can communicate, but instead that when communication occurs, an interceptor would not be able to extract any useful information.
Even without some malicious actor, we can't guarantee that communication works out. Sometimes packets of data just drop th-cam.com/video/7rLROSYcQU8/w-d-xo.html. You can't even guarantee that two computers are absolutely sure that they both agree on something (The Two Generals Problem) th-cam.com/video/IP-rGJKSZ3s/w-d-xo.html
A single computer can't even have guarantees about it's current state, like stray cosmic rays can hit the silicon to flip bits.
Anyways, though we have a lot of things we can't guarantee, one can attempt to produce the most robust solution possible given the circumstances(and, with some assumptions, prove that it is secure), or we can produce a solution which we believe to have a low probability of failing. Like, it is incredibly unlikely that cosmic rays do flip bits in memory, but even if this was an issue there are ways of using redundancy to lower the probability that we read corrupted data(coding theory and information theory). Quicksort is an example of an algorithm where we choose to take our chances, it hinges on selecting a random pivot, and on average it is a very fast algorithm but if you give it a really inconvenient input list it will have the same time complexity as the naive sorting algorithms(Bubblesort, SelectionSort, etc).
To put out one last caveat, we don't even know if cryptography is actually bulletproof :)
It's still an open question as to whether P = NP, but if it is and we find a good algorithm for
solving NP problems, then we also have a good algorithm for breaking cryptography.
Noone's cracked P vs NP yet though, and modern cryptography isn't cracked yet either(or maybe it is and some people have kept that secret really well), soooooooooooooooooooooooooooooooooo it's probably safe.
Rant aside, SSH and all other protocols can't guarantee service, but if it is observed that the service is consistently being denied and it's an issue, then either the user or the people who provide the service should investigate and figure out what the root cause is.
Server gets your public key
Server encrypts a [challenge] with your public key
You decrypt the challenge with your private key(as only your private key will unlock what the private key you shared locked) and send back the challenge
Server verified the challenge and established a tunnel
@@yordanibonilla5859 I see, but the question Nabil asks still applies. Basically the situation would become, what if an interceptor responds to the challenge before you do(with an invalid response), resulting in the challenge being failed and you not being verified.
Ah, but upon rereading the original comment, it says "not verifying the correct user". I interpreted it as the interceptor preventing you from being verified, rather then the interceptor being verified pretending to be you. But ya, given this procedure they can't beat the challenge the server provides.
@@Vaaaaadim Right and if they the interceptor did send the correct challenge by intercepting yours and it so happens to get there before you wouldn't they just be doing you a favor verifying ya lol?
@@yordanibonilla5859 Oh, right, duh. It wouldn't help them to beat the challenge on your behalf.
wow great can you tell me difference between Bash language and puTTY and Command line command prompt. also what connection is there between Bash and Linux.
Thanks in advance
How does client encrypt data locked with public key, by using the private key?
How server generate the SSH certificate in Linux?? Pls reply ASAP
nice video :-)
thanks.
Very good presentation
Thanks for watching, please like Bitfumes on facebook/twitter for more updates.
Nice
Sir, its nice presentation with little diversion!. you said, "Symmetrical encryption can’t be done on remote servers". But you didn't continue the need for SSH with proper justification.
it is the same key everywhere - hence, sharing it becomes increasingly risky
with asymmetrical encryption, identity and uniqueness is assigned to a caller
Thanku sir
Thanks for watching, Please subscribe to bitfumes' course section. bitfumes.com/courses
Clear explanatoin...
What if the decrepted top secret is stolen while being sent back to the server?
Would you make a video highlighting difference between the working of SSH and SSL
Thankyou friend
Thanks for your love and support, keep learning.
Follow bitfumes on twitter.com/bitfumes or facebook.com/Bitfumes to get the latest updates.
If I have just a LapTop and want to use a SSH just for security can I just Enable the Open ssh on my LapTop. Or do I have to have a server to configure the ssh? I just can't get it right.
I am lost here, Okay remote computer uses public key to encrypt a secret key which is a key to SSH. Well public key is known and so what's the point ...I am lost, please help
nice
is host based authentication and secure shell are the same?
Can you please explain how to use SSH on android smartphone
But what if mitm send back compromised data, encrypted with your public key? Is this possible? And then get your password of server and other info.
Well the animations are cool but how does the server know your private key so that you can decrypt with your private key
you need to put the private key manually or automatically
@@Bitfumes I searched more about this and found out that the pair of the public and private key are some how mathematically connected, but there is no way to derive one key from another. Whatever is encrypted by public key can only be decrypted by the paired private key.
awesome
Server gets your public key
Server encrypts a challenge with your public key
You decrypt the challenge with your private key and send back the challenge
Server verified the challenge and established a tunnel
After connection established we go to folder .ssh(of server) and copy all private keys( which will be encrypted by client public key) and get it into our system 😂 finally we hacked it.
@@manojprajapati932 lol
You decrypt the challenge with your private key and send back the challenge
how?
user only have public key, only the server have private key
@Bitfumes Webnologies
Great explanation!
But I have a question, if I am a MITM, I can catch the encrypted "top secret" message from the server (in this state I cannot read the message or get the private key) - but when I am able to catch the decrypted "top secret" that the client send back to the server, I now have the encrypted "top secret" message and the decrypted "top secret" message, and now I can figure out the private key... am I wrong? there is something I miss here?
encryption algorithm which is used in SSH is RSA and it is really hard to guess it, the key itself could be AES-256 encrypted, so it will take few million years to guess
:D Man, I just can't get over the phonetic. Anyway, I like it in a different wa! y!
THanks for watching bro, please like Bitfumes on facebook to get latest updates.
Can I get this ppt?
change the title == symmetric and asymmentric key.....
Does SSH helps to Prevents websites from seeing the computer IP Address?
nope, it is just an authorization mechanism to access system data from remove system
what if hacker catch that Top secret key and send it to the server himself?
Would recommend playing this video on 1.25X Speed
bill cipher 1:30
If I use password authentication for ssh session then how the data gets encrypted? In password authentication the client's public key is not present in server.
@@NetworkInfo I believe ssh channel is first established then authentication process starts. Ssh server and client first set up a secret key using Diffie Hellman algorithm and then that key is used to encrypt the channel. Next it asked for authentication method, either password based or ssh key based. That's why ssh key is not necessary for ssh connection. And we will always share client key into server, generating public private key is not necessary in server. For SSL it's different where server's public key is shared with client.
Every one is commenting good, but bro you confused me.