What exactly the term SSH(Secure Shell) means ?
In: 7
The ability to remote login into other computers has been a staple of computing for the longest time. From your command prompt on machine X, you can get a command prompt on machine Y and run things from that computer instead. Programs such as `telnet` and `rsh` (Remote SHell) would allow this, but they were not encrypted so anyone with access to the network wires could view your password or impersonate other computers on the network to violate the trust in the network. And across the whole internet it was just a risk.
SSH is the secure version, adding encryption but also adding a ton of features for a more modern age. Besides just getting a command prompt on a different machine, you can see the server’s “certificate” to ensure it’s the machine you think you want to connect to, it can be used as a simplistic VPN, and you can login using methods other than passwords like using SSL-style certificates where the client itself can present a certificate and the server could accept it as a condition of logging in. There’s even an included file transfer tool. Lots of other apps build on it for accessing other systems safely.
(I use the word “certificate” very loosely here because it’s not the same thing as what SSL uses, and there are no signatures from trusted certificate issuers in most situations)
SSH is a protocol you can use to login to a remote machine. The “Secure” part is because it’s encrypted and can use various secure methods of authentication. A “Shell” is short for “login shell” — when you login to a UNIX-like system, you’re running a “shell” program.
If that’s not what your question is about, please clarify.
SSH gives you a command line interface to a remote machine which is, as the name suggests, secure. As in encrypted.
Way back in the day we used to use Telnet, which was the same thing but not encrypted. Anyone sitting at any of the nodes between you and the machine you were remoting into could watch what you were doing. SSH made a huge improvement by encrypting the traffic.
In the before time, long ago
In the time before computers, people had the idea of building really long typewriters, so you could push the keys in one building and a message would appear in another. They eventually made it work by using wires.
This technology was well-developed before computers, so once computers became powerful enough, the next idea was to use teletypewriters to talk to computers. People wired them together and invented computer languages.
Next they turned the wires into sounds that could be sent through phone calls (modems) and then packets over computer networks (telnet, etc.)
SSH is the most recent development. It uses asymmetric key cryptography so you can talk to a computer over a public packet switching network like the Internet. But it’s still like a data call which means it still can be used like a teletype using the same kind of human-computer languages that were developed in the 60s and 70s.
You can also send files, tunnel vpn connections, and even connect some kinds of GUI, but the teletype interface remains popular. SSH is frequently used to set up and troubleshoot servers, and talking to it is the most comfortable way to do that.
The cryptography part means every computer or user account has a pair of keys. The private key stays on the computer where it was generated and acts like a password. The public key is copied over to every system you need to connect to, and acts like a password-checker.
There are more complex options, but that’s the basic setup.
When you connect two computers they’re able to recognize each other and set up a tamper-proof connection that resists eavesdropping.
if you’ve ever seen one of those tools that you share your desktop with others, it’s basically that except with 2 terminals to type commands in, there’s also no middle man and it’s encrypted (like https or a vpn)
Typically it’s used by sysadmins to talk to a server directly instead of physically going to a building and logging in with a physical monitor.
When you think of SSH, don’t think “Secure shell” (even though it’s the proper acronym), think of “Securing *a* shell and sharing it remotely*. In other words, the person receiving my SSH request is responsible for responding to the input I provide, not necessarily SSH itself.
Latest Answers