Re: Learning how to use "Remote Login"

On 2006-10-26, Mark Conrad <this-> wrote:

> ssh mark@169.254.2.33
>
> The darn G4 shook its head, scratched its hind end, and took a long time
> (15 seconds) - deciding whether or not it would let me connect to the G3
> Pismo.
>
> Finally popped up a mean-spirited message, something to the effect that
> it could not verify the authenticity of the host, whatever that means.
>
> Whatsa host?

Basically it is a computer, or in your case it refers to the hardware
running the sshd that was listening on port 22 of 169.254.2.33

Normally, when you run sshd for the first time on a host it generates
a public/private key pair referred to as the host key. The admin would
give the public key to anyone who wanted to ssh to that host. That key
would be places in a "known hosts" file on the client machine. When the
client connects it asks the host to verify that it really is the host
that the client thinks it is (in case someone has done some dns spoofing
or whatever and set up an imposter host to lure the unwary into handing
sensative info to the wrong host). Only the true host can verify its
identity because it has the private key.

So when you ssh to a host that is not in your known hosts file, ssh
warns you that it has no way of knowing whether the host you are
connecting to is the one you intend to connect to. It asks if you
trust the remote host to be the one it claims to be, and if so, it
retrieves the host's public host key and puts it in your known hosts
file. The next time you connect to that host you will be let straight
in. If it asks you again, then either the remote host key has changed
or you are connecting to the wrong machine.

Sorry I can't recommend any books. I learned it from ssh(1)
and sshd(1). But I did a quick Google and found:

Using SSH and Unix commands - a beginners tutorial
http://www.tamingthebeast.net/articl...x-commands.htm

Ian

--
Ian Gregory
http://www.zenatode.org.uk/ian/

> > Basically it is a computer, or in your case it refers to the hardware
> > running the sshd that was listening on port 22 of 169.254.2.33

>
> He's already been told all that numerous times over the last 2 or 3
> years. I think he's even been shown that exact tutorial.
>
> Greg
>
> --
> "All my time I spent in heaven
> Revelries of dance and wine
> Waking to the sound of laughter
> Up I'd rise and kiss the sky" - The Mekons

what no one has yet pointed out that no tutorial on ssh is going to
help.
one of his macs has an IP in the 169.254 range. this is an IP in the
range that the TCP/IP protocol says you'll be randomly assigned if your
machine is on DHCP and not receiving a dhcp address. it defaults to a
random IP in this range.

i'm presuming the OP has just run a n/w cable between two macs and not
set up static IP addresses on each in the appropriate range (i.e.
10.0.0.xxx or 192.168.0.xxx as examples) and so *nothing*'s going to
work until he does...

ric

In article <1hnssm5.kzq8xr1xptlweN%this->,
this-d (Mark Conrad) wrote:

[snip]

> It boils down to the shaky definition assigned to "host" in the computer
> world, which is totally different than the definition of "host" in
> normal usage.
>
> In normal usage of the word "host", a host is someone or something that
> provides a product/service for others, such as:
>
> 1) Host of a dinner, where that host provides food and/or entertainment
> for others.
> 2) City of Indianapolis is the host of the Indy 500, because the city
> provides services for use by the racing fraternity.
> 3) A restaurant is a host for its customers, because it provides food
> and service for its customers.

4) a computer which provides remote computing services for other
computers.
>
> In normal use of the word "host", the person or thing receiving the
> products and/or services is called a client/customer/guest.

As it does in the case of computers.
>
> In the computer world, all this is opposite from normal usage.
>
> For example, a host computer just sits around and soaks up the services
> provided by other computers, as in your statement about the meaning of a
> host computer:
>
> "Basically it is a computer, or in your case it refers to the hardware
> running the sshd that was listening on port 22 of 169.254.2,33"
>
> "Listening"? - - - really<g> - - - that doesn't sound to me like the
> supposed "host" is providing any service to anyone or anything.
>
> In fact, it sounds just the opposite of what a host is supposed to be,
> because it is 'listening' for what will be provided by other computers.
>
> Listening is passive, something a client/customer/guest would likely do
> while they are soaking up the services provided by others.

Oh, would you expect the waiter in a restaurant to "listen" for your
order? Would he be the server or the client? How can anyone on
anything provide a service if it does not "listen" for a request?
>
> No wonder the phrase "host computer" is so difficult to understand.

It's not difficult to understand if one opens one's mind to the context
of the use, rather than trying to force it into preconceived notions.

[snip]
> In my own mind, I will merely substitute the word "client" everywhere
> that I see the word "host", in your fine and detailed explanation.

That would be a mistake. You should consider the service being offered
and the context in which it is discussed. If make the effort, it will
be easy to distinguish the two in disparate situations such as XWindows
client/server and SSH client/server.
>
> Call me old fashioned, but I prefer the conventional ordinary meaning of
> "host", as used by everyone else in the civilized world.

"Old fashioned" it not the term I would use; try "stubbornly contrary."
The sad thing is that the more you celebrate your inflexible approach to
learning, the more you alienate those who earnestly try to help.

--
Tom Stiller

PGP fingerprint = 5108 DDB2 9761 EDE5 E7E3
7BDA 71ED 6496 99C0 C7CF

In article <1hnssm5.kzq8xr1xptlweN%this->,
this-d (Mark Conrad) wrote:

> "Listening"? - - - really<g> - - - that doesn't sound to me like the
> supposed "host" is providing any service to anyone or anything.
>
> In fact, it sounds just the opposite of what a host is supposed to
> be, because it is 'listening' for what will be provided by other
> computers.
>
> Listening is passive, something a client/customer/guest would likely
> do while they are soaking up the services provided by others.

Sheesh! Just like a waiter, who listens to his customers to find out
what they want, and then delivers it, a host computer listens to its
clients to find out what they want, and then delivers it.

> No wonder the phrase "host computer" is so difficult to understand.

No wonder you find it so difficult to understand.

> Call me old fashioned, but I prefer the conventional ordinary meaning
> of "host", as used by everyone else in the civilized world.

Are you Tony W. in disguise?

--
Stop Mad Cowboy Disease: Impeach the son of a Bush.

In article <1hnt6t9.122p9h61sowbcwN%this->,
this-d (Mark Conrad) wrote:

> > > Listening is passive, something a client/customer/guest would
> > > likely do while they are soaking up the services provided by
> > > others.
> >
> > Sheesh! Just like a waiter, who listens to his customers to find
> > out what they want, and then delivers it, a host computer listens
> > to its clients to find out what they want, and then delivers it.
>
> At least learn to use correct terminology, and call a spade a spade,
> for crying out loud.
>
> A waiter does not just "wait", because the _major_ part of his
> duties are to "serve", therefore he is a "server" with everything
> that implies.
>
> A waiter who stood around waiting would soon get fired.
>
> Very poor analogy on your part, shame on you.

I didn't say that he waits. I said that he listens for your order and
then serves it.

If you don't like the waiter analogy, substitute a butler; the butler
literally waits for orders for you and then executes them.

Refusal to understand on your part. Shame on you.

> > Are you Tony W. in disguise?
>
> No, look at the detailed headers on my posts dummy, have been posting
> here for 17 years.

That was sarcasm; you're just too humor impaired to recognize it.

> You seem to be more dense than usual today, are you getting senile
> like me?

No one could be as senile as you.

--
Stop Mad Cowboy Disease: Impeach the son of a Bush.

On 2006-10-26, Mark Conrad <this-> wrote:
> Michelle Steiner <> wrote:
>
>> > Listening is passive, something a client/customer/guest would likely
>> > do while they are soaking up the services provided by others.
>>
>> Sheesh! Just like a waiter, who listens to his customers to find out
>> what they want, and then delivers it, a host computer listens to its
>> clients to find out what they want, and then delivers it.
>
> At least learn to use correct terminology, and call a spade a spade, for
> crying out loud.
>
> A waiter does not just "wait", because the _major_ part of his duties
> are to "serve", therefore he is a "server" with everything that implies.

Michelle gave an excellent example. What you need to understand is

a) What is a TCP/IP connection
b) What is a client-server protocol

In this context, the server is often referred to the host, because
it hosts the service. In any client-server protocol, eg HTTP, or
(less obviously) ssh, the client makes a request and the server acts
on the request and sends a response. On the internet, client-server
protocols are implemented on top of TCP or (less typically, UDP,
but both are themselves implemented on top of IP).

So the server (host) always "listens" on a TCP (or UDP) port for client
connection requests. The client first sends a TCP syn packet, and
in the well known "three way handshake", the server sends a syn/ack
and finally the client responds with an ack. At this point a TCP
connection has been established and the client can then start sending
requests to the server using the appropriate higher level protocol.

In the case of HTTP, the client would typically send an HTTP GET
request over the TCP connection, asking for the resource at a given
URL. The server (a web server) would do some work and send back that
resource (a web page) in an HTTP response, and the client (a web
browser) would render the page.

This is exactly paralled in the waiter example. The waiter is the
server, who listens for client requests. Once the customer gets
the waiter's attention, perhaps just by walking in the door, a
connection is established. The customer then makes requests using
the approriate protocol. For example, "what is the soup of the day?"
The waiter does some work (perhaps goes to ask the chef), and gives
a response (minestrone). The client (who hates minestrone) makes
another request "OK, just bring me a plate of tripe", the waiter
complies, and the customer eats the tripe.

Once this analogy has fully sunk in, you may actually start to make
some progress.

There are of course more complex examples, such as X11 - don't
even think about that until you have understood the basics.

Ian

--
Ian Gregory
http://www.zenatode.org.uk/ian/

In article <1hnt83i.12wwtak7a1bcsN%this->,
this-d (Mark Conrad) wrote:

> However that same client provides services to the host in the form of
> files, and in the form of manipulating the host's existing files.

No, that is not providing services to the host, any more than eating the
meal that the server/waiter brought you is providing a service to the
restaurant.

As for providing files; that's not providing a service to the host. The
host is providing the service by storing the files for you.

> ...all services of which the "host" probably asked to be done for
> himself previously, in much the same way as a guest client at a
> dinner party asks his host to serve more potatoes to him.

That does not make sense. What service done for himself is a dinner
host providing that is analogous to a guest asking for more potatoes?

> Especially when you consider that two TB2 computers can be exchanging
> files with each other at the same time, so it is impossible to say
> which one of them is the host, and which one is the client.

The one that stores the files for the use of the other is the host. The
one that processes files for the benefit of the other is the host. The
one that provides files to be stored on another computer is the client.
The one that processes files for itself is the client.

--
Stop Mad Cowboy Disease: Impeach the son of a Bush.

On 2006-10-26, Mark Conrad <this-> wrote:

> I still have difficulty resolving the idea of a server simultaneously
> serving something while simultaneously listening.

Well an example of a server serving something without listening
would be something like a traditional television broadcast, where
the transmitter just beams The Simpsons out to the whole universe
and anyone who wants that service just tunes in.

That is not what we are talking about though. We are talking about
servers which serve things to particular clients *only* in response
to client requests. The server therefore must always be listening
for client requests in order to serve those clients.

I suppose another thing to realise (and if you can grasp this it
may be key) is that that servers are generally multi-tasking.
So, for example, sshd will always have a listener process listening
on port 22 for client connections. However, once it has accepted
a connection from a client, it will fork a separate process to
handle that connection, and then carry on listening for requests.
If lots of clients connect then there will be lots of sshd
processes running simultaneously on the host, one serving each
active client connection, and there will *also* be the listener
listening for new connections. Does that make things any clearer?

Ian

PS, the reason you can have multiple simultaneous TCP connections
to port 22 on the host IP address is that TCP connections are
uniquely defined by *four* values - host IP, host PORT, client IP
and client PORT. This means you can even have multiple TCP connections
from the *same* client, because each will be using a different port
number on the client. When an ssh client process establishes a TCP
connection to an ssh server, it is uses the next *available* PORT
number on the client.

PPS, all this info is readily available in numerous beginner's
guides on the web. Please use them.

--
Ian Gregory
http://www.zenatode.org.uk/ian/

In article <1hntchs.irsjqbv9mgkkN%this->,
this-d (Mark Conrad) wrote:

> Ian Gregory <> wrote:
>
> > So the server (host) always "listens" on a TCP (or UDP) port
> > for client connection requests.
>
>
> That reasoning conflicts with what Tom Stiller posted below, because the
> machine doing the listening can't initiate a connection, it is busy
> "listening", by your definition. No criticism of either one of you,
> just trying to sort things out in my own mind.

No it doesn't, except that there's no such thing as a UDP connection. :-)
Upon "hearing a connection request, the (potential) host will accept the
connection and initiate the protocol to provide the requested service.
>
> > > Whatsa host?
> >
> > The machine to which you are connecting.

> > This is exactly paralled in the waiter example. The waiter is the
> > server, who listens for client requests. Once the customer gets
> > the waiter's attention, perhaps just by walking in the door, a
> > connection is established. The customer then makes requests using
> > the approriate protocol. For example, "what is the soup of the day?"
> > The waiter does some work (perhaps goes to ask the chef), and gives
> > a response (minestrone). The client (who hates minestrone) makes
> > another request "OK, just bring me a plate of tripe", the waiter
> > complies, and the customer eats the tripe.
>
> I can find no fault with any of that, in fact it helps me better
> understand the difference between host and client.
>
> I would hate to have to explain it all to an "average Mac user".
>
> I still have difficulty resolving the idea of a server simultaneously
> serving something while simultaneously listening.

Oh come on! We're listening to your [badly formulated] queries and
serving you answers.
>
> In my own mind, I got it mixed up because I thought the _client_ was
> the one doing the listening, listening for whatever service was about to
> be dispensed to him by the server (host). Does the explanation of my
> confusion aboit this subtle point make any sense to you? I hope so.

No! The key to any client/server process is the dialog through the
client and server negotiate exactly what is to be served and the
client's right to receive the service.
>
> I realize my subtle error now, but only because of the excellent posts
> here. I never would have found the error in my reasoning by reading
> arcane books about:
> > a) What is a TCP/IP connection
> > b) What is a client-server protocol

I think you would once you resign yourself to the fact that the author
will develop the subject according to _his_ plan and not necessarily
according to your [unknown (unknowable?)] desires.

[snip]

--
Tom Stiller

PGP fingerprint = 5108 DDB2 9761 EDE5 E7E3
7BDA 71ED 6496 99C0 C7CF

Mark Conrad wrote:
> Fooey, I will have to connect via the Internet by more conventional
> means.

Take a look at what you can get for free at http://www.dyndns.org
No man pages, I promise.

--
Wes Groleau
----
The man who reads nothing at all is better educated
than the man who reads nothing but newspapers.
-- Thomas Jefferson