Telnet?

Hva er telnet?

Er learner nu på spil med sit hacking igen? var det ikke ham der ville lære alt muligt om det?

Telnet :

A terminal emulation program for TCP/IP networks such as the Internet. The Telnet program runs on your computer and connects your PC to a server on the network. You can then enter commands through the Telnet program and they will be executed as if you were entering them directly on the server console. This enables you to control the server and communicate with other servers on the network. To start a Telnet session, you must log in to a server by entering a valid username and password. Telnet is a common way to remotely control Web servers.

Quote

Originally posted by GrillRotten
Telnet :

A terminal emulation program for TCP/IP networks such as the Internet. The Telnet program runs on your computer and connects your PC to a server on the network. You can then enter commands through the Telnet program and they will be executed as if you were entering them directly on the server console. This enables you to control the server and communicate with other servers on the network. To start a Telnet session, you must log in to a server by entering a valid username and password. Telnet is a common way to remotely control Web servers.

Så blev det sat på plads

Quote

Originally posted by cla
Så blev det sat på plads

Ja, det skulle jeg mene... Det var det letteste... Folk ville nok glo hvis jeg skrev "Internet DOS with remote options and other means of intergration"... *G*

Quote

Originally posted by Bastard
Telnet er fra Unix til kommunikation på hjemmenetværk. MS tog det med i windows, så de kan/kunne kommunikere med unix-maskiner.

Ja, noget i den retning... Unix var vist de første der brugte det....

Det er pre-dino teknologi... men stadig brugbar for de rette folk...

http://www.How-To-Learn-To-Hac…Get-Real-In-Less-Time.now

Quote

Originally posted by GrillRotten
http://www.How-To-Learn-To-Hac…Get-Real-In-Less-Time.now

Du har meget sjov ud af sådanne link lige for tiden hva ?

Quote

Originally posted by cla
Du har meget sjov ud af sådanne link lige for tiden hva ?

Jeps. Hvem siger at én sætning ikke kan sige en hel del ? ...

TELNET OPTION SPECIFICATIONS
This RFC specifies a standard for the ARPA Internet community. Hosts on
the ARPA Internet are expected to adopt and implement this standard.

The intent of providing for options in the TELNET Protocol is to permit
hosts to obtain more elegant solutions to the problems of communication
between dissimilar devices than is possible within the framework
provided by the Network Virtual Terminal (NVT). It should be possible
for hosts to invent, test, or discard options at will. Nevertheless, it
is envisioned that options which prove to be generally useful will
eventually be supported by many hosts; therefore it is desirable that
options should be carefully documented and well publicized. In
addition, it is necessary to insure that a single option code is not
used for several different options.

This document specifies a method of option code assignment and standards
for documentation of options. The individual responsible for assignment
of option codes may waive the requirement for complete documentation for
some cases of experimentation, but in general documentation will be
required prior to code assignment. Options will be publicized by
publishing their documentation as RFCs; inventors of options may, of
course, publicize them in other ways as well.

Option codes will be assigned by:

Jonathan B. Postel
University of Southern California
Information Sciences Institute (USC-ISI)
4676 Admiralty Way
Marina Del Rey, California 90291
(213) 822-1511

Mailbox = POSTEL@USC-ISIF

Documentation of options should contain at least the following sections:

Section 1 - Command Name and Option Code

Section 2 - Command Meanings

The meaning of each possible TELNET command relevant to this
option should be described. Note that for complex options, where

RFC 855 May 1983

"subnegotiation" is required, there may be a larger number of
possible commands. The concept of "subnegotiation" is described
in more detail below.

Section 3 - Default Specification

The default assumptions for hosts which do not implement, or use,
the option must be described.

Section 4 - Motivation

A detailed explanation of the motivation for inventing a
particular option, or for choosing a particular form for the
option, is extremely helpful to those who are not faced (or don't
realize that they are faced) by the problem that the option is
designed to solve.

Section 5 - Description (or Implementation Rules)

Merely defining the command meanings and providing a statement of
motivation are not always sufficient to insure that two
implementations of an option will be able to communicate.
Therefore, a more complete description should be furnished in most
cases. This description might take the form of text, a sample
implementation, hints to implementers, etc.

A Note on "Subnegotiation"

Some options will require more information to be passed between hosts
than a single option code. For example, any option which requires a
parameter is such a case. The strategy to be used consists of two
steps: first, both parties agree to "discuss" the parameter(s) and,
second, the "discussion" takes place.

The first step, agreeing to discuss the parameters, takes place in
the normal manner; one party proposes use of the option by sending a
DO (or WILL) followed by the option code, and the other party accepts
by returning a WILL (or DO) followed by the option code. Once both
parties have agreed to use the option, subnegotiation takes place by
using the command SB, followed by the option code, followed by the
parameter(s), followed by the command SE. Each party is presumed to
be able to parse the parameter(s), since each has indicated that the
option is supported (via the initial exchange of WILL and DO). On
the other hand, the receiver may locate the end of a parameter string
by searching for the SE command (i.e., the string IAC SE), even if
the receiver is unable to parse the parameters. Of course, either
party may refuse to pursue further subnegotiation at any time by
sending a WON'T or DON'T to the other party.

RFC 855 May 1983

Thus, for option "ABC", which requires subnegotiation, the formats of
the TELNET commands are:

IAC WILL ABC

Offer to use option ABC (or favorable acknowledgment of other
party's request)

IAC DO ABC

Request for other party to use option ABC (or favorable
acknowledgment of other party's offer)

IAC SB ABC <parameters> IAC SE

One step of subnegotiation, used by either party.

Designers of options requiring "subnegotiation" must take great care
to avoid unending loops in the subnegotiation process. For example,
if each party can accept any value of a parameter, and both parties
suggest parameters with different values, then one is likely to have
an infinite oscillation of "acknowledgments" (where each receiver
believes it is only acknowledging the new proposals of the other).
Finally, if parameters in an option "subnegotiation" include a byte
with a value of 255, it is necessary to double this byte in
accordance the general TELNET rules.

http://www.scit.wlv.ac.uk/~jphb/comms/telnet.html