I remember back in 97, the university officially ended all support for non encrypted remote access, and we were all required to use SSH. Which worked fine. It also made for an excellent tunnelling tool when the same university tried blocking all access to P2P networks.
Discovering SSH was a game changer for me after i started playing with linux. I discovered SSH forwarding and it blew my goddamn mind. It's been a life saver in a lot of situations and I'll never forget the professor that showed me how to use it.
I still remember when I discovered that I with scp could from machine A copy a file from machine B to C. Also that it could copy between two accounts on the same machine. 😜
@@FractalZero Emacs is great, both in Linux, MacOSX, and MS Windows. You might want to look Up and use My configuration on GitLab to start from. There you have both OrgMode and Magit setup for use in Emacs. Firar is easy way to generator, PDF, HTML and other formats from same source. You can also mix in code, and extract it to files or executing and show result in documents.
The biggest thing for me was when setting up control connections along with that. I was in an environment which had 2FA on the bastion hosts to get into the environment, but regular keys / passwords to the hosts behind. We'd have a session to the bastion host with top running (to keep the session open) then we could use chaining / multihops to go through the existing session on the bastion host to the hosts deeper in the network on subsequent connections during the day
Been there, in 1989 there was no SSH, just telnet, and we was happy to have that. In 1982 there was not even connections outside the university. I still remember the first Macintosh (yes, THE one, after Lisa).
@@lunasophia9002 Its so sad what the internet has become ... so many years yet still we don't have any secure authentication method thats 100% reliable
@@feschber we will never have 100% security, as security faults is either buggs in software, hardware or in specifikation. For instance, there are some interesting bugs in the SMS protocol compression. 😜
Fantastic. You're the professor that true geeks want. You exhibit an approachable charm beneath the geekspeak that invites questions and deep exploration into topics.
@@eadweard. Probably the guy who wanted to prevent others from seeing it. Or maybe he's baiting people to attack the address. Ironically you cared enough about people caring about it to comment so you must be really invested in this xd.
@@naturesinterface6663 I'm starting to think it might be your IP or something and now the script kiddies are pouring in. :( I'm sorry, man. I never wanted anyone attacking you, or anyone else. I merely suggested it might be an intentional choice. It's probably for the best if everyone just stops paying attention to this if it is, in fact, hurting somebody. Again, my apologies if I made your situation worse, that was never my intent.
Small detail, but I don't think padding is there to increase the security of the encryption. It's generally just added so that the data matches the block size of the encryption algorithm.
It's both. Padding is necessary because of block size, but instead of being just null bytes, it's random bytes which scramble the final hash even more, so it also reinforces security
I think there's an error when talking about the packet format. The SSH2's specifications (RFC4253, section 6.3) states as follow: "When encryption is in effect, the packet length, padding length, payload, and padding fields of each packet MUST be encrypted with the given algorithm.". So the packet is all encrypted except the MAC field. Anyway great job as always with bringing such contents, thank you!
How does the other machine (server in your example) know the key to initially decrypt the packet? Do they use an asymmetric encryption handshake to establish the session key for the ssh to encrypt the payload and padding to be passed through the ssh? Love the vids too
Depends on the implementation. I’ve used connections where the sysadmin has to manually add your public key into the target machines config so only people who possess a specific set of private keys can possibly access it. The only way to possibly get in is access to one of the machines involved since no other auth protocol is part of the process.
The first thing I do when setting up a new SSH server is to set PasswordAuthentication to no. Passwords are evil. It takes a few seconds to generate a key pair and add the public key portion to the authorized_keys file. It's amusing to see how rapidly script kiddies start banging on port 22 when you open it on your firewall (within a minute, usually) but they will try in vain if you are using public key access (I like ECDSA-521 and RSA with at least a 2048-bit modulus).
SSH is really good. It even allows to connect ethernet layer VPN so you can have layer 2 or layer 3 if you wish vpn really easily and every machine supports that.
@@dietalkaa a VPN runs on top of L3, so how can it possibly be L2? the VPN interface is for all intents and purposes a L2 interface, but it runs on top of the L3 stack rather than on top of L1 or even other L2. this is why VPN is often called L2.5, among other encapsulation or tunneling protocols. when talking about MPLS VPNs, it's technically possible to get L2 transmission if you run it through something like ATM, but i think the standard method is on top of the IP layer.
What I don’t understand about this and all network encryption generally, is does the first packet have to send the decryption key? How can you send a decryption key without it being sniffed???
Which encryption to use, and how to exchange keys, is something both machines "negotiate" based on what they each support. Basically, it's going to be some version of Diffie Hellman (there are Computerphile videos on that). Over time, less secure options can be phased out, and replaced with new ones, more-or-less like a "plugin", without needing to scrap the basic SSH system.
The encryption works in a very similar fashion to a modern SSL connection. A session key is generated with a Diffie Hellman or ECDH (DH ensures that only you and your suitor know this key), The server has a public/private keypair to prove it's identity which your client confirms is the same as the last time you connected. Dr Steve authenticated to the server using a public/private keypair on the client (which was encrypted on his disk using a password) for which the server has the public key in it's authorized_keys file. All the data is encrypted, usually with AES (but it can be chacha20-poly1305 or others) and the MAC is normally SHA256 based (or the one built into chacha20-poly1305). The public keys can also be several algorithms; RSA, ED25519,etc or even keys linked to certificates.
so if i intercept the negotiation phase or even decrypt the packets with all known encryption on ssh i can get the data ??? is the negotiation itself encrypted ?? and how do they send the keys at first ??? and are the keys secured ??
@@fouzaialaa7962 There's a negotiation about which *method* to use for exchanging keys etc, but the exchange itself is secure. Look up Diffie Hellman for info on how keys can be established securely over an unsecured connection
3:18 Presumably there are additional checks somewhere to ensure the packet length is sane. Otherwise you could fiddle those first four bytes to some random bizarre values and cause mischief that way. Because remember the MAC at the end has to be found via the packet length, so you can’t verify that until you are sure of the packet length!
Lawrence D’Oliveiro what kind of length values might cause mischievous behaviour? Are you thinking what if the receiver is susceptible to a buffer overflow, or something?
@@rlamacraft No I think he means if the packet length is altered, the receiver will not know how far to read into the payload and might miss some packet data.
Why are SSH and TLS(SSL) different protocols when either one could have been built on top of the other to achieve the same objective - e.g. plain-text HTTP over SSH tunnel or rsh/telnet over SSL (instead of tcp) socket ? Is either one more or less secure than the other ?
once a connection is established between a server and a client, "handshaking" is done to ensure that the connection has been made with the right computer. An asymmetric encryption is done between the computers to generate and transport keys for symmetric encryption. The symmetric keys are hence used to encrypt and decrypt data. Now what happens is, computer A generates two keys for asymmetric encryption : public and private. A public key is sent over to computer B which encrypts the symmetric key using the public key it recieved. Here, the public key can only encrypt and the private key can only decrypt data. The encrypted symmetric key is sent back to computer A, which decrypts it using its private key and generates the symmetric encryption key. This way, both computers have a symmetric key which can be used to encrypt/ decrypt the data sent and received over the connection. The 3rd party cannot sniff the encryption "rules" (or the symmetric key) because it has been encrypted by a public key before transmission, and can only be decrypted with a private key, which hasn't been sent over the network.
You should redo this video. You have only explained that ssh sends packets over a transport system. If you go to the level of packets then tell the reader about public private encryption. Then explain a remote shell. Finally explain how ssh can be used in a non-shell mechanism.
So are the random bytes which get concatenated the functional equivalent of a cryptographic “salt”? Also, does the length field include the length of the padding as well as the data?
Steve Richter i assume you found answer by now but.. permissions. TempDisable root make unprivileged user and add user to sudoers group, is the way i did it.
But how do you protect the initial agreement between the 2? If a hacker has already seen that initial agreement the encryption won't matter to xem and xey can just decrypt it based on that initial agreement.
Wow, I started watching this video, but only out of the corner of my eye, and I looked at the monitor on the desk and thought: "What is that huge black cube??" -- optical illusion
If the sniffer intercepts the initial messages that are used to establish the encryption that they will be using then it should be able to decrypt all of the packets correct? Why does this not appear to be a concern?
Thus video misses the really interesting point how the encyption key is exchanged between the two sides in a secure way. It also doesn't mention how to ensure that the foreign host is the one it pretends to be.. The role of the files "known_hostx" and "authorized_keys". Maybe you could explain these in a follow up video ?
SSH is a protocol for sharing files between two computers. The SHA256 NSA encryption is applied for the transmission of data, as the packets don't get lost and it's based on a TCP connection.
@@mytech6779 @MyTech SHA256 was designed for message digests, it's what's used as a layer for information security in applications and if you knew how SSH worked you would know that SHA256 is a cryptographic hash function, but it can also be misused in computation referring to what you mentioned a "hashing algoritihm" used for password cracking. Hashing algorithms serve the purpose of computation among inputs for a desired outcome and that's not applied in SSH, it's based on authentication.
@@mytech6779 SHA256 role in SSH as a one way function is that SSH will ask you for a finger print, when that is mentioned SHA256 will hash your characters as your "ID" which is a long cryptographic hash string in an SSH file for communication for two computers. You can then do authentication for your remote computer for file sharing between the two computers. We are hashing characters to protect the integrity of the data not to perform a brute force attack. These are the only ways SHA256 or SHA512 is applied.
I only watched to correct Steve. 3:34 Unless you select specific 3rd party or otherwise dubious algorithms, the packet length field is also encrypted. In particular, the demo algorithms at 6:00 do encrypt the packet lenght field.
What if there is a weakness in the hashing algorithm for the message authentication code and you somehow figure out for example what the message cannot be? I know it's abstract and non-practical idea... but I guess the mac can be encrypted as well (why not?).
Thanks. This was informative. I have a question about channels. Do I understand correctly that it's the channel that deals with the "handshake" and private/public key encryption/decryption? Or is it something else?
It's more for the purpose of obfuscation, allowing the SSH packet length to be some fixed number, and thus not allowing an attacker to deduce anything useful about what the payload might be. *_EDIT:_* It does also act as a salt, since we can have equivalent payloads which, even if encrypted using a simple block cipher, result in different ciphertexts due to having different randomly generated padding.
Tractor feed is very robust for industrial applications. Common office printers are flimsy junk with unreliable pickup and feed leading to jams and lost prints when removed from the nice clean, low vibration, and air conditioned environment. In short, tractor feed paper is still produced and sold.
he does not explain the most important thing ... the actual initial handshake and why that would be secure. if someone sniff the initial packets he should be able to see the key the sender and reciever agree to use,
@The Zak Take a look into public/private key cryptography. You can publish your public key for all in the world to see (and indeed, you are doing so right now), and it is used to encrypt data being sent to you. But it can only be decrypted by your private key, which (hopefully) no one else has. There's some really really cool maths that goes into it.
Ok, I admit I'm ignorant... but you never once explained how it WORKS - ie, why is this secure and what prevents a packet sniffer from decrypting the packet the same way the intended server does it?
I love this channel !! But I am wondering why in 2019 such an amazing computer science department has that much dot-matrix printer paper ?? What do you guys do with that printer ??
Where is that video on gallois fields that was teased at the end of the last isbn video? I’ve just been sitting by hoping you’ll post the video soon, but now I’m starting to worry that there isn’t a video being made.
I did this once for fun with Windows on my home computer which I connect from my computer at school. It was slow but it works. This was many years ago. I think it was with WinXP or Win2k.
You mention X windows using an encrypted tcp connection to poet 6000. I've always known ssh to use a standard port 23. When did that become the standard?
Fun video. I have noticed something, when i minimise this video on yt app to bottom bar your shirt looks like static on a tv without signal. Anyone nows why is that?
The first handshake, yes. The subsequent handshakes, however, compare the public key it just got and compares it to the key in its local store. If the two are different, SSH complains. That means you should always get the fingerprint through offline means before connecting to a new service over SSH.
Not really. Sometimes it can be used as such, but normally padding is forced simply because encryption algorithms encrypt data in blocks of bytes (often 16 bytes). Nevertheless, if you've got to put bytes in there random is probably better than just zeros.
I understood this as meaning encapsulation, which means that when you want to establish a channel of communication over SSH, what you do is authenticate using the SSH protocol, then you say "create channel 1" down the wire, and then you send as individual SSH packets "send 'hello' to channel 1", "send 'world' to channel 1", and the program listening on channel 1 of the connection is going to just see "hello world". This way, you've forwarded a connection, over which you've just sent "hello world", over SSH, but the program doesn't care about what was happening at the SSH level.
What do you mean "we cant make". For example cisco switches can have only opened max 16 connections to single switch. But it doesnt mean that switch cant forward SSH packets to different devices.
@@BLABLABLA-kl8eq when we establish 20 SSH cxns from a windows server to different routers/switches. We try to open new SSH cxns to different routers but new cxns holds or directly closed.
@@kylaxcry Tahts interesting. What kind of ssh client are you using? at this point it soudns more like client limitation/configration. Did you try on different ssh client? like instead of putty try mremote ng? Or moba xterm?
@@kylaxcry Just to be sure Lets say you have hosts A,B,C,D to which you want to crate ssh connections. After creating 20 connections (like 15 to host A and 5 to host B, you cant create new connection to any of other hosts ? Like host C?
@@BLABLABLA-kl8eq We use openSSH with Python's Paramiko Library. Each SSH cxn we make is unique from one server to unique devices (only cisco, huawei routers). We only wait a second for creating a new cxn to a new device using asynchronous programming.
I remember back in 97, the university officially ended all support for non encrypted remote access, and we were all required to use SSH. Which worked fine. It also made for an excellent tunnelling tool when the same university tried blocking all access to P2P networks.
@@Eeroke Teach me master
"congratulations, you played yourself."
Hoisted by their own petard.
If they can't see it, they have plausible deniability. Bet their lawyers were happier with that
I used to use SSH at work to bypass the internet filter by setting up a tunnel through my home internet connection.
Discovering SSH was a game changer for me after i started playing with linux. I discovered SSH forwarding and it blew my goddamn mind. It's been a life saver in a lot of situations and I'll never forget the professor that showed me how to use it.
I still remember when I discovered that I with scp could from machine A copy a file from machine B to C.
Also that it could copy between two accounts on the same machine. 😜
Anyway, you should try emacs.
Open the file "/ssh:user@machine:file" or "/scp:user@machine:'.
Called Tramp mode. 😜
@@AndersJackson As someone who is new to the linux game, that second sentence is quite an eye-opener. So much to learn.
@@FractalZero Emacs is great, both in Linux, MacOSX, and MS Windows.
You might want to look Up and use My configuration on GitLab to start from.
There you have both OrgMode and Magit setup for use in Emacs. Firar is easy way to generator, PDF, HTML and other formats from same source. You can also mix in code, and extract it to files or executing and show result in documents.
The biggest thing for me was when setting up control connections along with that. I was in an environment which had 2FA on the bastion hosts to get into the environment, but regular keys / passwords to the hosts behind.
We'd have a session to the bastion host with top running (to keep the session open) then we could use chaining / multihops to go through the existing session on the bastion host to the hosts deeper in the network on subsequent connections during the day
Can't imagine life without SSH.
Been there, in 1989 there was no SSH, just telnet, and we was happy to have that. In 1982 there was not even connections outside the university. I still remember the first Macintosh (yes, THE one, after Lisa).
Anders Jackson The internet wasn't (as) full of people actively trying to ruin your day 30 years ago. It's sadly a different place now.
@@lunasophia9002 Its so sad what the internet has become ... so many years yet still we don't have any secure authentication method thats 100% reliable
@@feschber we will never have 100% security, as security faults is either buggs in software, hardware or in specifikation.
For instance, there are some interesting bugs in the SMS protocol compression. 😜
Can't imagine life without PURE WATER
Fantastic. You're the professor that true geeks want. You exhibit an approachable charm beneath the geekspeak that invites questions and deep exploration into topics.
Please don't blur for security. It's still readable. Use solid colored bars, for the love of Turing.
who cares
@@eadweard. Probably the guy who wanted to prevent others from seeing it. Or maybe he's baiting people to attack the address. Ironically you cared enough about people caring about it to comment so you must be really invested in this xd.
@@lollllloro who cares
@@naturesinterface6663 I'm starting to think it might be your IP or something and now the script kiddies are pouring in. :( I'm sorry, man. I never wanted anyone attacking you, or anyone else. I merely suggested it might be an intentional choice. It's probably for the best if everyone just stops paying attention to this if it is, in fact, hurting somebody. Again, my apologies if I made your situation worse, that was never my intent.
@@lollllloro who cares
Sorry I didn't wanna break the chain
the casual focus fade in/out makes it looks like an office episode and its just priceless/.
Thing I love about this video is the listing paper. I bet Nottingham still have boxes and boxes of that stuff floating around from the 80s.
Yeah!! I miss that stuff!
Small detail, but I don't think padding is there to increase the security of the encryption. It's generally just added so that the data matches the block size of the encryption algorithm.
It's both. Padding is necessary because of block size, but instead of being just null bytes, it's random bytes which scramble the final hash even more, so it also reinforces security
I think there's an error when talking about the packet format. The SSH2's specifications (RFC4253, section 6.3) states as follow: "When encryption is in effect, the packet length, padding length, payload, and padding fields of each packet MUST be encrypted with the given algorithm.". So the packet is all encrypted except the MAC field.
Anyway great job as always with bringing such contents, thank you!
That’s what he said (but it’s not true for all elgorithms and Mac’s. Gcm ciphers don’t encrypt the length
perfect timing, I'm taking a networking course right now and they do a terrible job of explaining SSH
I am using this tunnel, 24/7 in my PC and smartphone for over 3 years now. And I am happy
Nice tutorial. Thanks. Would talk more about the key exchange and establishing process you omitted for the purpose of this video at around 4:00?
Thanks for the subtitles! The auto-generated ones can be pretty inconsistent.
SSH tunnels let me watch this video at work without "them" knowing...
Despite looking like a 90s hacksploitation movie character, Dr. Bagley is the real deal
SSH is the way to go ... Nicely explained Doc.
Kudos for taking it down to the packet level! Many videos don't do this!
How does the other machine (server in your example) know the key to initially decrypt the packet? Do they use an asymmetric encryption handshake to establish the session key for the ssh to encrypt the payload and padding to be passed through the ssh? Love the vids too
Yes, they do, as you can see in the video it states "offering public key".
@@ZintomV1 oh yeah thank you, I didn't see that on first watch :)
@@kade9527 try it self with a couple of "-v" switches and you learn a lot. ;-)
They also do some MIM protection. That is they use certificates on both directions, so you can create a certificate to use when you login in.
Depends on the implementation. I’ve used connections where the sysadmin has to manually add your public key into the target machines config so only people who possess a specific set of private keys can possibly access it. The only way to possibly get in is access to one of the machines involved since no other auth protocol is part of the process.
Steve is a Feynman-tier explainer, great vid.
The first thing I do when setting up a new SSH server is to set PasswordAuthentication to no. Passwords are evil. It takes a few seconds to generate a key pair and add the public key portion to the authorized_keys file. It's amusing to see how rapidly script kiddies start banging on port 22 when you open it on your firewall (within a minute, usually) but they will try in vain if you are using public key access (I like ECDSA-521 and RSA with at least a 2048-bit modulus).
+ port knocking.
Just started exploring the world of SSH. I am coming back to this video with reviews on the learning and practice process.
SSH is really good. It even allows to connect ethernet layer VPN so you can have layer 2 or layer 3 if you wish vpn really easily and every machine supports that.
A VPN is not actually L2 by the way, some people call it L2.5.
It's L2. MPLS is more like Layer 2.5 -.- don't miss lead @@BattousaiHBr
@@dietalkaa a VPN runs on top of L3, so how can it possibly be L2?
the VPN interface is for all intents and purposes a L2 interface, but it runs on top of the L3 stack rather than on top of L1 or even other L2.
this is why VPN is often called L2.5, among other encapsulation or tunneling protocols.
when talking about MPLS VPNs, it's technically possible to get L2 transmission if you run it through something like ATM, but i think the standard method is on top of the IP layer.
@@BattousaiHBr yes I know. What's your point??? Wtf
@@dietalkaa
?
you called VPN a L2 connection when it isn't.
Would love to see a video about MOSH from you guys!
Thanks, appreciate your work
Note that it would be better to compress before encryption to get higher compression ratio, rather than the other ordering.
This channel rocks like SSH.
Have you considered doing an episode about BEEP (or BXXP)? This is a standard stream multiplexing protocol as described in RFC's 3080 and 308.
What I don’t understand about this and all network encryption generally, is does the first packet have to send the decryption key? How can you send a decryption key without it being sniffed???
Thank you for a simple and clear explanation.
This was really helpful for me to better understand how it works and why we use it thanks.
how does the encryption work ?? do both machines agree on a key to encrypt and decrypt ?? or do they use an existing keys ?? how is it done exactly ??
ググレかす
Which encryption to use, and how to exchange keys, is something both machines "negotiate" based on what they each support.
Basically, it's going to be some version of Diffie Hellman (there are Computerphile videos on that).
Over time, less secure options can be phased out, and replaced with new ones, more-or-less like a "plugin", without needing to scrap the basic SSH system.
The encryption works in a very similar fashion to a modern SSL connection. A session key is generated with a Diffie Hellman or ECDH (DH ensures that only you and your suitor know this key), The server has a public/private keypair to prove it's identity which your client confirms is the same as the last time you connected. Dr Steve authenticated to the server using a public/private keypair on the client (which was encrypted on his disk using a password) for which the server has the public key in it's authorized_keys file. All the data is encrypted, usually with AES (but it can be chacha20-poly1305 or others) and the MAC is normally SHA256 based (or the one built into chacha20-poly1305). The public keys can also be several algorithms; RSA, ED25519,etc or even keys linked to certificates.
so if i intercept the negotiation phase or even decrypt the packets with all known encryption on ssh i can get the data ??? is the negotiation itself encrypted ?? and how do they send the keys at first ??? and are the keys secured ??
@@fouzaialaa7962 There's a negotiation about which *method* to use for exchanging keys etc, but the exchange itself is secure. Look up Diffie Hellman for info on how keys can be established securely over an unsecured connection
3:18 Presumably there are additional checks somewhere to ensure the packet length is sane. Otherwise you could fiddle those first four bytes to some random bizarre values and cause mischief that way. Because remember the MAC at the end has to be found via the packet length, so you can’t verify that until you are sure of the packet length!
Lawrence D’Oliveiro what kind of length values might cause mischievous behaviour? Are you thinking what if the receiver is susceptible to a buffer overflow, or something?
@@rlamacraft No I think he means if the packet length is altered, the receiver will not know how far to read into the payload and might miss some packet data.
All I want to know where you picked up that lovely, wide, green leporello (endless stationary) paper.
Petition for computerphile to do Unix commands History, Uses, Tips, and Tricks
How do you do the last thing mentioned in the video? Keep ssh connection alive after exiting shell?
Thousands of dollars worth of equipment and homeboy busts out the green sharpie and some printer paper from 1985. I love UA-cam.
Cause it works!!!!lololololol
Scribbling on greenbar... that takes me back.
That timing tho. I know some of my class mates got asked about exactly this yesterday in the oral exam.
Thank you. With what you have said, I (almost) understand what I need.
Why are SSH and TLS(SSL) different protocols when either one could have been built on top of the other to achieve the same objective - e.g. plain-text HTTP over SSH tunnel or rsh/telnet over SSL (instead of tcp) socket ? Is either one more or less secure than the other ?
How many reams of green-bar printer paper do you still have laying around?
Can you link those videos (thumbnail) after the main video in description?
can someone suggest me what to study in order to understand all the concepts related to de video?
which video explains the padding and random data in the packets? It would be nice if that could be added to the description.
i was hoping he would explain how a 3rd party cant sniff the establishing encryption 'rules' and thus be able to decrypt later data
once a connection is established between a server and a client, "handshaking" is done to ensure that the connection has been made with the right computer. An asymmetric encryption is done between the computers to generate and transport keys for symmetric encryption. The symmetric keys are hence used to encrypt and decrypt data.
Now what happens is, computer A generates two keys for asymmetric encryption : public and private. A public key is sent over to computer B which encrypts the symmetric key using the public key it recieved. Here, the public key can only encrypt and the private key can only decrypt data. The encrypted symmetric key is sent back to computer A, which decrypts it using its private key and generates the symmetric encryption key. This way, both computers have a symmetric key which can be used to encrypt/ decrypt the data sent and received over the connection.
The 3rd party cannot sniff the encryption "rules" (or the symmetric key) because it has been encrypted by a public key before transmission, and can only be decrypted with a private key, which hasn't been sent over the network.
Do an rsync too please
+1
rsync is so cool. You know Andrew Tridgell developed it for his PhD thesis?
rsync is literally a swiss army knife for copying/moving files around locally and between machines.
I've used rdist for 30 years; but have heard rsync is better. Will need to try it out.
Your videos are amazing! Thanks you for your work pal!
please do a video on packet sniffing & the transport and network layers of TCP/IP!
You should redo this video. You have only explained that ssh sends packets over a transport system. If you go to the level of packets then tell the reader about public private encryption. Then explain a remote shell. Finally explain how ssh can be used in a non-shell mechanism.
Can a single file (split into packets) be sent through multiple channels of communication?
Great video, thanks for creating great content.
So are the random bytes which get concatenated the functional equivalent of a cryptographic “salt”?
Also, does the length field include the length of the padding as well as the data?
What prevents code on the local system from reading private keys and then using those keys to login to a remote systems?
Steve Richter i assume you found answer by now but.. permissions. TempDisable root make unprivileged user and add user to sudoers group, is the way i did it.
Great explanation, thanks!
But how do you protect the initial agreement between the 2? If a hacker has already seen that initial agreement the encryption won't matter to xem and xey can just decrypt it based on that initial agreement.
Wow, I started watching this video, but only out of the corner of my eye, and I looked at the monitor on the desk and thought: "What is that huge black cube??" -- optical illusion
If the sniffer intercepts the initial messages that are used to establish the encryption that they will be using then it should be able to decrypt all of the packets correct? Why does this not appear to be a concern?
I was thinking the same thing!
Blimey, he's gangsta in front of a computer.
Thus video misses the really interesting point how the encyption key is exchanged between the two sides in a secure way. It also doesn't mention how to ensure that the foreign host is the one it pretends to be.. The role of the files "known_hostx" and "authorized_keys". Maybe you could explain these in a follow up video ?
SSH is a protocol for sharing files between two computers. The SHA256 NSA encryption is applied for the transmission of data, as the packets don't get lost and it's based on a TCP connection.
SHA256 is a non-reversible hash algorithm not an encryption. Blowfish-cbc, aes256-cbc, and aes256-ctr are encryptions.
@@mytech6779 @MyTech SHA256 was designed for message digests, it's what's used as a layer for information security in applications and if you knew how SSH worked you would know that SHA256 is a cryptographic hash function, but it can also be misused in computation referring to what you mentioned a "hashing algoritihm" used for password cracking. Hashing algorithms serve the purpose of computation among inputs for a desired outcome and that's not applied in SSH, it's based on authentication.
@@mytech6779 SHA256 role in SSH as a one way function is that SSH will ask you for a finger print, when that is mentioned SHA256 will hash your characters as your "ID" which is a long cryptographic hash string in an SSH file for communication for two computers. You can then do authentication for your remote computer for file sharing between the two computers. We are hashing characters to protect the integrity of the data not to perform a brute force attack. These are the only ways SHA256 or SHA512 is applied.
I only watched to correct Steve.
3:34 Unless you select specific 3rd party or otherwise dubious algorithms, the packet length field is also encrypted. In particular, the demo algorithms at 6:00 do encrypt the packet lenght field.
What if there is a weakness in the hashing algorithm for the message authentication code and you somehow figure out for example what the message cannot be? I know it's abstract and non-practical idea... but I guess the mac can be encrypted as well (why not?).
Thanks. This was informative. I have a question about channels. Do I understand correctly that it's the channel that deals with the "handshake" and private/public key encryption/decryption? Or is it something else?
I didn't know it was developed by a Finnish guy
Finnish guys have always built relevant software. :)
But why am I not surprised
The story how ssh got allocated port 22 is also abit interesting.
Telnet is port 23?
Please tell so we can see if it worth investigate.
There is no story. Port 22 was free. Developer wrote an email requesting it be reserved for ssh. Request was granted.
@@damnmab as it should be then.
Nothing that to look into.
Is "abit" like "rabbit", only a bit shorter?
[question] what font is it @6:12? normal "a"s, clear distinction between O and 0, that's a keeper
What if someone sniffs during the time when the server and the client decide on the encryption protocol?
always have something to set-off the day with ///
When you say the padding is a random number of whatever, is this akin to a salt when encrypting passwords for example?
It's more for the purpose of obfuscation, allowing the SSH packet length to be some fixed number, and thus not allowing an attacker to deduce anything useful about what the payload might be.
*_EDIT:_* It does also act as a salt, since we can have equivalent payloads which, even if encrypted using a simple block cipher, result in different ciphertexts due to having different randomly generated padding.
Where can I buy that shirt?
How do you even have dot-matrix printer paper in 2019?
Because they haven't use them for printing in ages so the stockpile never gets used up?
@@Neumah Nah... My theory is frivolous use of time machine.
@@mistercohaagen ...or that.
Tractor feed is very robust for industrial applications. Common office printers are flimsy junk with unreliable pickup and feed leading to jams and lost prints when removed from the nice clean, low vibration, and air conditioned environment. In short, tractor feed paper is still produced and sold.
It's still used a lot.
he does not explain the most important thing ... the actual initial handshake and why that would be secure.
if someone sniff the initial packets he should be able to see the key the sender and reciever agree to use,
@The Zak Take a look into public/private key cryptography. You can publish your public key for all in the world to see (and indeed, you are doing so right now), and it is used to encrypt data being sent to you. But it can only be decrypted by your private key, which (hopefully) no one else has. There's some really really cool maths that goes into it.
ssh is probably the most important tool (lower level type like)
Ok, I admit I'm ignorant... but you never once explained how it WORKS - ie, why is this secure and what prevents a packet sniffer from decrypting the packet the same way the intended server does it?
Check other videos for public private key cryptography. It's about symmetric keys. It can be used both for encryption and verification of identity.
because it sends encrypted data... it can be decrypted, yes, but better than plain text..
I would've liked a bit more detail... but.. I guess.. that's really all there is to SSH :)
The way you pronounced Tatu Ylönen made me burst a lung laughing
why is padding encrypted given they would be equally random bytes before and after encryption?
EXCELLENT WORK!! well explained
Toast and Jam! I used to be tech lead on that product.
I love this channel !! But I am wondering why in 2019 such an amazing computer science department has that much dot-matrix printer paper ?? What do you guys do with that printer ??
It's a style choice for these videos, as for the reason the dept has it... if it ain't broke?
They use it to trigger people in youtube comments.
Where is that video on gallois fields that was teased at the end of the last isbn video? I’ve just been sitting by hoping you’ll post the video soon, but now I’m starting to worry that there isn’t a video being made.
It is planned but it hasn't been shot yet! >Sean
Computerphile yay, thanks for the response! I shall wait patiently and keep my eye out for the video.
Is that an amiga 1000 in the background?
I did this once for fun with Windows on my home computer which I connect from my computer at school. It was slow but it works. This was many years ago. I think it was with WinXP or Win2k.
Thanks for this videos!!
Thanks, really enjoyed
you people are awesome
What is that Adaptec box always present on your videos? :)
I love that they use line printer paper 😂😂 most kids probably wonder what's with the holes on the sides??
No, no one is wondering that
Only 90s kids will get this
r/gatekeeping
The obvious answer for them is when you get your copy, you can waste time ripping the hole strips off. Like popping bubble wrap, but more official.
You mention X windows using an encrypted tcp connection to poet 6000. I've always known ssh to use a standard port 23. When did that become the standard?
ssh uses port 22. The older unecrypted telnet protocol uses port 23.
@@chocolate_squiggle you are correct. Only thing i can think of is i made a typo on my cell phone 2 years ago.
Fun video. I have noticed something, when i minimise this video on yt app to bottom bar your shirt looks like static on a tv without signal. Anyone nows why is that?
Thank you sir, good job 🍉
would'nt it be possible to pose as an ssh server during the handshake process?
The first handshake, yes. The subsequent handshakes, however, compare the public key it just got and compares it to the key in its local store. If the two are different, SSH complains. That means you should always get the fingerprint through offline means before connecting to a new service over SSH.
So what is an ssh booter?
So packet padding is basically salt?
So padding is similar to salting a hashed password?
Not really. Sometimes it can be used as such, but normally padding is forced simply because encryption algorithms encrypt data in blocks of bytes (often 16 bytes). Nevertheless, if you've got to put bytes in there random is probably better than just zeros.
Not at all
Can you connect to a Bulletin Board System using Secure Shell Protocol (SSH) instead of Telnet?
...yeah...
i still dont get it. is it like a browser vpn?
What does it mean to forward a connection?
I understood this as meaning encapsulation, which means that when you want to establish a channel of communication over SSH, what you do is authenticate using the SSH protocol, then you say "create channel 1" down the wire, and then you send as individual SSH packets "send 'hello' to channel 1", "send 'world' to channel 1", and the program listening on channel 1 of the connection is going to just see "hello world". This way, you've forwarded a connection, over which you've just sent "hello world", over SSH, but the program doesn't care about what was happening at the SSH level.
Is there any limitation for ssh or channel from a machine to vast amount of routers/switches? We can't make more than 60 SSH connection simulatneouly.
What do you mean "we cant make".
For example cisco switches can have only opened max 16 connections to single switch. But it doesnt mean that switch cant forward SSH packets to different devices.
@@BLABLABLA-kl8eq when we establish 20 SSH cxns from a windows server to different routers/switches. We try to open new SSH cxns to different routers but new cxns holds or directly closed.
@@kylaxcry Tahts interesting.
What kind of ssh client are you using? at this point it soudns more like client limitation/configration.
Did you try on different ssh client? like instead of putty try mremote ng? Or moba xterm?
@@kylaxcry Just to be sure
Lets say you have hosts A,B,C,D to which you want to crate ssh connections.
After creating 20 connections (like 15 to host A and 5 to host B, you cant create new connection to any of other hosts ? Like host C?
@@BLABLABLA-kl8eq We use openSSH with Python's Paramiko Library. Each SSH cxn we make is unique from one server to unique devices (only cisco, huawei routers). We only wait a second for creating a new cxn to a new device using asynchronous programming.
Nice video
Today I learned what verbose means and does