A very well welcome to my lovely reader! how are you, by the way?
Well, A long way back I heard about something called “Telnet”. At that time I got to know that it is used for remote login. That’s it! The book didn’t describe how did “Telnet” work the way it is explained. And nor ever I got the fair idea of what actually this Telnet is. Recently when I searched for the fact that was not discussed in that book. And I got to know that this “Telnet” is no more usable.
What is remote login? what is Telnet? why don’t we use it now? and If we don’t use it then what do we use now instead? and how do we use that novelty? Let’s see guys you gonna dive into something called SSH.
If you want to explore How SSH works, then you may refer to this [ultimate guide] How SSH works?
What is remote login?
It was a pretty interesting concept when I first heard about it. See, suppose you have a machine at your workplace and one at your home and you wanted to perform some tasks on the one at your workplace but the point is you can’t reach hands on that machine due to any reason. Therefore you have to use your home machine to operate commands on your remote machine. Now how would you be able to do it without reaching that machine? here is the concept of remote login. Basically fits better at a client-server model. We are going to discuss soon what this model is.
So, remote login is actually “remote login” nothing more than that. Remote means “somewhere far out of your reach” and login means simply “to login”.
What is Telnet?
So, if you found that “remote login” is quite an interest appealing concept. Then probably you wanted to know how to do it? how to perform commands on a remote machine. Suppose if your friend is stuck up somewhere in his Linux machine and you are repeatedly shouting at him to perform a particular sequence of commands or a bash script. But the fellow is not able to perform that correctly. So, what can you do is to actually get log into your friend’s machine and perform the set of commands which he wasn’t able to perform correctly? and the best part is without actually even touching your friend’s machine. Sounds cool! right? Yes exactly! And to give this facility of controlling a remote server here comes Telnet.
Telnet is a network protocol that allows a user on one computer to log into another computer that is part of the same network. Interesting!
Why don’t we use it now?
We don’t use it because of the fact that no matter How good this protocol was. But Using Telnet is not secure!
Oh my God, what I mean to say it isn’t secure? Oh, guys don’t get afraid, this is not going to hack your machine and delete some valuable data, this is not going to ruin your Operating System but…
This can do much worse! That is why we don’t use it now. Wanna know what worse it can do? Keep reading.
Not only the two use cases I discussed above are only use cases. You may found yourself working with a remote server with very much valuable and security needed pieces of information. You may transfer your valuable data between two machines. Or anything working with anything that needs attention on security measures. Now, this is the place where “Telnet” actually fails. It doesn’t provide any security of transmitting data or information. How?
When we use this protocol and send some information from a client to a remote or we get some info. form remote to your client. It inevitably transmits in signals and guys, these signals can be watched! Not only can watch but can be captured too! And what if that info. is your most secure “passwords” your most secure “commercial_stuffs” or your most secure “anything”.
That means if you use “telnet” for remote login and transfer information between two machines than that info. is clearly visible to outside world. All your signals can be easily watched by anyone with any intentions. You got it? Because Telnet does not encrypt your signals it simply transfer from one machine to another.
That is why, if you like your signals and want your information not to be leaked? You better not use the “Telnet”.
What do we use now instead?
If Telnet is not a worthy protocol to control a remote machine. Then what is?
Because we people are security lovers because we don’t feel like giving our valuable data to others because we don’t want to ruin our E-life. We use something called the “SSH”.
What is SSH?
SSH stands for Secure SHell. Secure Shell (SSH) is a cryptographic network protocol for operating network services securely over an unsecured network. It means if you use SSH instead of Telnet then your information that is going to transmit over a network is going to remain secure. How? let’s understand the protocol if brief.
Brief Explanation of SSH protocol:
Client-Server model: The client-server model is a distributed application structure that partitions tasks or workloads between the providers of a resource or service, called servers, and service requesters, called clients. (this is what you get at Wikipedia).
But in SSH, the server always doesn’t mean to say a big hardware component to host data and services. As I said that your friend’s laptop can also act as a server. Simply a client is a machine from where you may operate a server. In SSH you have an ssh-client and an ssh-server as well.
SSH-keys: SSH actually encrypts your signals while transmission and after reaching the destination machine it decrypts the signal. For encryption and decryption, we have something called SSH keys.
There are two SSH-keys that are created simultaneously:
- Public key ( that is your encryption key )
- Private key ( that is your decryption key )
How SSH works: when you set up an SSH network between your client machine and a remote server. What happens is either manually or command line network connection you put your “Public-Key” in the “authorized_keys” file of SSH of the server. And when the connection is established the server puts its “Public-Key” in your machine’s “known_hosts” file of SSH. But both of them never ever share their “Private-Keys”.
Now suppose client sends a signal to server. Now SSH will encrypt this signal using “server’s encryption (public) key” and will transmit over the network. When server will receive this signal, it will decrypt this using its own “decryption (private) key”. which also mean to say that after client machine encrypts its signal no one can decrypt this left alone server.
The same is followed by a signal coming from the server. From opposite side, the server will encrypt the signal using client’s public key and the client will decrypt it using its own private key.
With this, no one can sniff inside the signal and even if someone does. He or She won’t be able to understand what is being shared because of whatever info. they will get will be in encrypted form. And if someone wants to decrypt this. They would need the private key. THEREFORE NEVER EVER SHARE YOUR PRIVATE KEY OVER NETWORK!!
Why SSH better than others?:
- Simply because it provides security. It keeps the valuable information to be safe unless and until you share your private-key to someone, or unless and until you got connected to trusted servers. You are good to go!
- More controlled than FTP. Due to Unix Shell and if you have an experience of CLI your connection over SSH would be more controlled than FTP.
- Easy to use, and with command line interface it saves time.
You may see a detailed Blog post about Why SSH better than other here.
How to generate your SSH-keys:
By default in current Linux machines, this OpenSSH is coming pre-installed. But if your machine doesn’t have it, then you would need to install it via “sudo apt-get install openssh-client” and “sudo apt-get install openssh-server” (this second one is in case you want to use your machine as a server too).
You may generate your SSH-key pair (both public and private simultaneously) with this:-
$ ssh-keygen -t rsa -b 4096 -C "firstname.lastname@example.org" Generating public/private rsa key pair. Enter file in which to save the key (/home/localuser/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/localuser/.ssh/id_rsa. Your public key has been saved in /home/localuser/.ssh/id_rsa.pub. The key fingerprint is: e7:06:7f:2c:32:bf:84:a8:5b:8d:63:98:f3:ee:a2:8b email@example.com The key's randomart image is: +---[RSA 4096]----+ | | | | | | | | | S . | | o + * . | | + * = * o | |. .* . * o | |E ooo=+ o. | +-----------------+
You may enter a pass-phrase to create one more security layer to your SSH.
ABOUT PASS-PHRASE: pass-phrase is a more secure level of “password”. Because generally, your passwords are of 8-12 tokens. Which can be easily decrypted using a “Brute force” program and if that password is relevant that would be icing on the cake for a Brute force attack. So your Pass-phrase is not a single word, it is a complete sentence or a paragraph if you want. Which would increase the complexity of a brute force program to decrypt your pass-phrase. But yes the more lengthy your pass-phrase is the more time it would take to decrypt your private key the more time it would take to decrypt your signals as well. So, your choice!
.ssh folder structure:
when you are successful with key generation you would get a “.ssh” directory in your home directory (I am not talking about windows). This .ssh would have “id_rsa” that would be your private key and an “id_rsa.pub” that would be your public key. (maybe id_dsa)
Also, that would have “known_hosts” file to collect the public key of servers you got connected with. and “authorized_keys” file if your machine ever works like a server then this file keeps the public keys of clients’ machine.
Installing your Public Key to a server:
For an SSH connection, it is mandatory for a server to have your “Public-Key” in its “authorized_keys” file. So, you have to install your public-key to a server via two methods.
So here you would have 2 machines of yours one will work as a server and other will work as a client. In both of then, SSH must be installed.
Installing your public key manually:
You have to copy your public key that is in “~/.ssh/id_rsa.pub” to a server. Use command “scp ~/.ssh/id_rsa.pub server:.ssh/authorized_keys” e.i:
$ scp ~/.ssh/id_rsa.pub firstname.lastname@example.org:.ssh/authorized_keys
with hitting this command you’ll be prompted to enter the password of your remote (server) machine before transmitting your public key. But for this, you should have that “authorized_keys” file on your remote server.
To make this operation more restrictive you should apply for the required permissions on “.ssh” directory and “.ssh/authorized_keys” file on that remote machine by the following commands.
chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys
Also, you may simply copy and paste your public key from the client machine to remote machine’s .ssh/authorized_keys file.
Installing your public key automatically:
do this and give your password of the remote host and leave everything.
SSH agent program:
ssh-agent is a program that holds your private key efficiently. Because people use passphrases to keep their private keys securely, therefore, giving your long pass-phrases again and again may be a hectic task to perform. What better we can do at starting the ssh session you may add your private key after providing your pass-phrase only once to your ssh-agent program and ssh-agent will keep it for you. ssh-agent will itself use it whenever it demands. For this first, you have to start the ssh-agent process if it is already not started yet by:
eval "$(ssh-agent -s)" Agent pid 59566
Now your ssh-agent program is running, you may add your private key to it by
With this, you are all set to start an ssh session. In my next post.
Other SSH use cases:
Now, this is something I still want to read more about. But some less common use cases of SSH are:
- using passwordless, key-based login;
- setting up local per-host configurations;
- exporting a local service through a firewall;
- accessing a remote service through a firewall;
- setting up a SOCKS proxy for Firefox;
- executing commands remotely from scripts;
- transferring files to/from remote machines;
- mounting a filesystem through SSH; and
- triggering admin scripts from a phone.
Want to read a worthy article on these uses case click here.
Come back in the next blog of mine where we’ll be working on an ssh connection and perhaps will talk more about SSh use cases. See you soon till then This, is Geekyshacklebolt,
bidding you goodbye!