vadi@cs.iastate.edu (Vadivelu Elumalai) (03/29/91)
I have used both rlogin and telnet to access a remote machine. But I don't know when to use telnet and when to use rlogin. I know that rlogin uses the ~/.rhosts and involves more set up than telnet. Is it possible to rlogin a machine, which could be accessed by telnet and vice-versa? I think it should be possible, because most of the machines have reserved ports for both. Could someone elicit the main differences between these two? Thanks. Vadi. ------------------------------------------------------------------------ Vadivelu Elumalai, U.Snail : 813, Wilson Avenue, B-20, Atanasoff, Ames, Iowa - 50010. Iowa State University, AT&T : (515) - 232 - 7220 Ames, IA - 50010 E-mail : vadi@judy.cs.iastate.edu ------------------------------------------------------------------------ -- ------------------------------------------------------------------------ Vadivelu Elumalai, U.Snail : 813, Wilson Avenue, B-20, Atanasoff, Ames, Iowa - 50010.
jik@athena.mit.edu (Jonathan I. Kamens) (04/04/91)
In order to understand the differences between telnet and rlogin, and the
reason why both of them exist, you have to have a little history. I'll try to
present some of that.
First of all, telnet came first. The first attempt to describe the telnet
protocol was in Internet RFC 95, dated February 1971. I admit that I don't
have copies of RFCs that far back :-), and it's not available on-line, so I
can't quote to you from it. There was significant discussion of the protocols
before it started to come into common use, and even more significant
discussion afterwards. The RFC which defines the current telnet protocol
specification is RFC 854, which *is* on-line, so I can quote its introduction:
The purpose of the TELNET Protocol is to provide a fairly general,
bi-directional, eight-bit byte oriented communications facility. Its
primary goal is to allow a standard method of interfacing terminal
devices and terminal-oriented processes to each other. It is
envisioned that the protocol may also be used for terminal-terminal
communication ("linking") and process-process communication
(distributed computation).
An important concept in the protocol is the idea of a "Network Virtual
Terminal." The original purpose of the protocol was to connect your terminal
to a remote host in such a way that it would seem like you were working on a
local host.
In the beginning, telnet was very basic. There was none of the automatic
terminal type negotiation, or binary modes, or character-at-a-time input
modes, or other protocol features that we take for granted in today's telnet.
However, the protocol was stable and robust, and was designed in such a way
that extensions would be easy to implement while allowing backward
compatibility. It did the job.
Then, the people at BSD decided that it wasn't enough. "Remote connections
should be able to figure out the terminal type automatically, just as they can
on a hard-wired terminal. Machines should be able to trust each other in a
way that makes passwords unnecessary. And furthermore, if we're going to
allow programs to ask for input a character at a time (a relatively new
thing), then we're going to have to be able to pass input a character at a
time over the connection." So they pointed out rlogin, rsh, the whole rcmd
shebang. Which was an incredible kludge, for many reasons, including:
1) It was capable of passing the terminal type, but was not easily
extensible to allow *other* parameters to be passed. The terminal type
passing was a hack.
2) The character-at-a-time input was doable, but once again, it was done in
a very specific manner. No negotiation between both sides of the connection
like in the telnet protocol. In the rlogin protocol, there's only one way to
go, and everybody has to talk the same way.
3) The security mechanism, involving a reserved port, was easily spoofable
by forging network packets, or simply by hooking a non-Unix box up to the
network and coming in on the reserved port. Another kludge.
Well, rlogin et al provided important features which, at the time, were
lacking in telnet. They did make the systems easier to use. However, it
would be reasonable to argue that the reserved port authentication should
never have been set up at all, and that rlogin's features should have been
implemented as extensions to the telnet protocol, rather than as an entirely
separate protocol.
And, in the end, that's exactly what happened. Telnet continued to develop,
catching up in functionality to what rlogin accomplished, while rlogin just
sort of sat around doing the same thing, other than a brief rejuvenation when
the Kerberos team decided to implement Kerberos-authenticated rlogin rather
than Kerberos-authenticated telnet. Another mistake.
At this point, telnet can do pretty much everything rlogin can do, although
the authentication isn't quite worked out yet (and when it is worked out,
it'll probably be based on Kerberos v5, which is a tad more secure than a
reserved TCP port).
And so, the question boils down to -- right now, which one should you use,
telnet or rlogin? Well, if the machine you're connecting to is running a
recent version of telnetd, and you've got a recent version of telnet, then the
only think telnet isn't going to be able to do that rlogin is going to be able
to do is the authentication so that you can log in without passwords. If you
can do that, you're probably better off with telnet. I believe CSRG isn't
even putting a lot of effort into rlogin for 4.4BSD, although I'm not certain
about that.
To answer your other question, yes, a machine can accept both rlogin and
telnet connections, and many do; they are completely separate protocols and
can operate at the same time independent of each other.
Well, I think I've got all this stuff right, and I'm sure someone will
correct me if I've said anything wrong or omitted anything.
--
Jonathan Kamens USnail:
MIT Project Athena 11 Ashford Terrace
jik@Athena.MIT.EDU Allston, MA 02134
Office: 617-253-8085 Home: 617-782-0710