0

It is always said to use Secure Shell (SSH) instead of Telnet or rsh/rcp/rlogin, for security reason.

SSH and rsh are both remote shells. I wonder if telnet is also a remote shell? If yes, why is it a remote shell, or how shall I understand that it is a remote shell?

The definition of a remote shell is

The remote shell (rsh) is a command line computer program that can execute shell commands as another user, and on another computer across a computer network.

I looked up how telnet is used. What I found was that a telnet client can connects to a telnet server (when connecting to the telnet port) or another process (when connecting to a port other than the telnet port), which is already running on a server machine. It seems to me that telnet can't execute i.e. launch a shell command on a server machine, which is part of the definition of a remote shell.

When I looked for alternatives to telnet which is based on UDP, some mentioned that netcat and nc are such alternative programs. If I am correct, netcat and nc are both used to connect to a process already running on a machine, but not to execute i.e. launch a process on a machine. Does it also suggest that telnet is used to connect to a process already running on a machine, but not to execute i.e. launch a process on a machine?

If it is true that telnet is used to connect to a process already running on a machine, but not to execute i.e. launch a process on a machine, why is it compared to SSH, given that SSH and telnet are doing different things?

Thanks.

p.s.

I just realized the Wikipedia article for remote shell seems to be for a particular program rsh and rshd.

What I mean by a "remote shell" in my post is a type of programs or protocols that can be used to connect to a remote machine, launch a shell on the remote, and launch commands or programs in the shell.

3

telnet was the traditional way to get a remote shell on a networked unix machine. rsh was the other. ssh is a relative newcomer in comparison.

telnet typically talks to a remote telnet daemon (or "server" process). At that point you authenticate with a username and password to login and then you get a shell. So, yes, it's a method of getting a remote shell.

The telnet client can also be used for other connections by specifying another port (eg telnet host 80 will talk to the web server); this isn't a remote shell. It's the combination of telnet talking to telnetd and authenticating that gives the remote shell.

telnet is not recommended for remote shell because the username and password are typically passed over the network in plain text; a network sniffer or "man in the middle" attack can steal your password. Not good! ssh encrypts the traffic to help prevent this.

Example of telnet giving a remote shell:

% telnet server.name
Trying 192.168.100.100...
Connected to server.name
Escape character is '^]'.

NetBSD/i386 (server.name) (pts/51)

login: fred
Password:
Last login: Fri Jun 24 21:45:29 2016 from 192.168.1.1 on pts/23

No mail.

$ whoami
fred

$ pwd
/home/fred

$ logout
Connection closed by foreign host.
  • thanks. 1. for your second paragraph, can you give commands that can give a remote shell, so that I can execute some command in the remote shell afterwars, just like what I can do after logging in via ssh? 2. for your third paragraph, when a telnet client connects to a port which is different from the telnet server's port, you mentioned it is not a remote shell. Then does the following sentence " It's the combination of telnet talking to telnetd and authenticating that gives the remote shell" mean that it gives a remote shell? – Tim Jun 26 '16 at 23:14
  • Example of telnet to get a remote shell added. This is only a remote shell because it talks to telnetd and lets you login and get a command shell. – Stephen Harris Jun 26 '16 at 23:21
  • Thanks. That addresses the first part in my previous comment, and there is part 2 about the third paragraph in your post. – Tim Jun 26 '16 at 23:25
  • telnet server 80 talks to the web server. This isn't telnetd and so doesn't give a remote shell. It'd allow you to pretend to be a dumb web client. Remeber, it's the server that grants the shell and not the client. telnetd, rlogind, sshd... So if you talk to httpd then you won't get a shell. – Stephen Harris Jun 26 '16 at 23:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.