NAT is the reason. The ping is being translated from one network to
another as well as telnet. Going the other way, you have no rules to
> so according to your tutorial 192.168.0.x is not on the same subnet as
> 192.168.1.x. If that is correct why can I ssh (and ping and
> telnet....) from client to host but not host to client?
>
> :-)~MIKE~(-:
>
>
> On Fri, Jul 18, 2014 at 12:30 PM, Michael Havens <bmike1@gmail.com
> <mailto:bmike1@gmail.com>> wrote:
>
> telnet localhost 22 from the server received no answer from the client
> telnet 192.168.1.101 22 from the client received no answer from
> the server
>
> I'll get back to you about the research project
> (and as a private message)
>
> :-)~MIKE~(-:
>
>
> On Fri, Jul 18, 2014 at 6:41 AM, <kitepilot@kitepilot.com
> <mailto:kitepilot@kitepilot.com>> wrote:
>
> Hello Michael:
> the 'Net' is a hodgepodge of protocols, all abiding to the
> 'OSI Layer Model' to work properly
> (http://en.wikipedia.org/wiki/OSI_model).
> Troubleshooting your SSH connection should be a fairly simple
> proposition, because there are only so many moving parts (Three!).
> As anything under the OSI model, nothing on an upper layer
> will work unless the necessary components of the lower layer
> are working.
> AND you *HAVE* to troubleshoot each layer separately.
> So how does this go?
> Well, lets take a look at your SSH problem...
> 1.- In order for the SSH connection to work you need 3 things:
> 1.1.- a SSH server,
> 1.2.- a SSH client and,
> 1.3.- a TCP/IP connection.
> *EACH* one of the lines above is a separate project and *HAS*
> to be addressed as such.
> Lets cover the basics first, the TCP/IP connection:
> You *HAVE* to *KNOW* The Mantra:
> "In order for any 2 devices to establish a TCP connection they
> have to share a physical link and they need addresses in the
> same subnet".
> The statement above is a pretty dense one, and has several
> implications, number one being: What does "subnet" mean?
> Another is: what about IPs in different subnets?
> We'll get there...
> As there are already several books written (and to be written)
> about the few lines above, I'll water it down to the bare minimum:
> The subnet is defined via the netmask, and implies that "ON"
> parts of the netmask are always equal in all the addresses on
> a network segment, so:
> Network:
> 192.168.0.0/24 <http://192.168.0.0/24> or
> 192.168.0.0 with netmask 255.255.255.0 means that
> *ALL* the addresses in *THIS* network are going to look like
> 192.168.0.${SOMETHING_ELSE}
> '192.168.0' is the "Network", and "${SOMETHING_ELSE}" is the
> "Host".
> You can not use "Host 0" (because that defines the network)
> and you can not use the highest number (255) because that's
> the 'broadcast address'.
> Which means that any '/24" (slash 24) network can address 254
> 'hosts'.
> Network:
> 192.168.0.0/16 <http://192.168.0.0/16> or
> 192.168.0.0 with netmask 255.255.0.0 means that
> *ALL* the addresses in *THIS* network are going to look like
> 192.168.${SOMETHING_ELSE}.${SOMETHING_ELSE}
> '192.168' is the "Network", and
> "${SOMETHING_ELSE}.${SOMETHING_ELSE}" is the "Host".
> You can not use "Host 0.0" (because that defines the network)
> and you can not use the highest number (255.255) because
> that's the 'broadcast address'.
> Which means that any '/16" (slash 16) network can address
> 65534 'hosts'.
> The reason why '255' is the highest number is because IPv4
> addresses (and netmasks) are represented in memory in 4 bytes,
> each number one byte.
> Bytes are 8 bits, but that's a different book that you need to
> read too, lets move on with the network.
> Things get pretty interesting (and math pretty convoluted)
> when you define networks like 192.168.127.0/25
> <http://192.168.127.0/25>
> If yo want to see all variations, you can be lazy (like me)
> and run:
> ipcalc 192.168.0.127/25 <http://192.168.0.127/25>
> Finally, "Netmasks" are a patch to the first defined (and
> shortsighted) 'Address Type' as class A,B,C or D, but I'll let
> you research that yourself.
>
> Well, that's all good, but how do you talk to other
> addresses?, I talk to google.com...
> That's a valid question, but
> 1.- it is not part of *THIS* SSH problem and
> 2.- you don't 'talk to google'.
> We'll talk more about how devices find each other in a network
> down below, but in order to talk to devices outside your
> network you need the 'Routing Protocol' (implemented at
> [SURPRISE!] 'the router') which is nothing else than a table
> of rules stating 'this IP goes that way'. In your case, all
> addresses go the same place (the router) so the router becomes
> the 'Default Gateway'. As to resolve google, you need the
> DNS, but you knew that... :)
>
> Now that we know what an IP address is, lets move on to the
> "Physical Link".
> Well, a cable will do...
> In the wireless world, the "Association" is the link.
> And how do you validate that?
> iwconfig will tell you what (if anything) you are associated
> to. No association, no link, no connection, no SSH.
> ifconfig will tell you what (if anything) you are wired to.
> No wire, no link, no connection, no SSH.
> Ain't that simple? ;-)
> So we have a link...
> And we have IP addresses in the same subnet.
> So we are connected!!! 8-)
> Not so fast Armando!!!
> The fact that your addresses match is not necessarily a
> validation, because each computer may be connected to a
> different router providing the same NAT(ed) address!
> NAT?
> Yes NAT (Network Address Translation protocol), but that's yet
> another book, so lets water it down:
> NAT is the protocol that allows you to have an 'outside
> visible address' and an 'inside invisible network' in a router.
> NAT (as Netmask) was implemented mainly to alleviate the IPv4
> shortage address because of the 'class A,B,C or D' mistake,
> but as a byproduct, you can 'hide' behind it, which provides
> some level of security. How you hide is yet another bookshelf
> and essentially means that you cannot access devices 'behind
> the router' unless the device initiates the connection first,
> and that's how you raise a WEB site from 'behind the router'
> and why you can SSH from 'inside to outside the router' but
> not the other way around, so lets move on...
> So, how do we know that we are connected to the same router?
> Ah, glad you asked:
> ARP!
> Or Address Resolution Protocol.
> *ALL* data transmission is done at OSI layer 2.
> Quick implementation manual:
> OSI layer 1: Cable or association.
> OSI layer 2: MAC address.
> OSI layer 3: IP address.
> Your network doesn't know (and doesn't care) about IP
> addresses. The IP address is there to resolve the MAC address.
> When you say:
> ping 192.168.0.1
> that generates a 'who has' request from the ARP protocol.
> That request is broadcasted to anyone on the physical link
> (OSI layer 1)
> The device with the IP address interrogated by 'who has'
> answers with its MAC address.
> This IP/MAC address pair is then saved to the ARP table.
> >From there on (and even though the IP address goes along in
> the TCP/IP header) all transmissions are sent to the MAC address.
> But then again, how do you know that your 2 boxes are talking
> to the same router?
> arp -n|grep 192.168.1.1
> Same MAC?
> Same box.
> Different MAC?
> Same Michael... ;-)
> What do we know so far?
> Well, we know something about line 3 of the very first paragraph.
> What about line 2?
> Type
> which ssh
> You have it or not, and you know what to do, so lets move to
> line 1.
> We now need to troubleshoot the SSH server.
> Well, that boils down to 2 things, it is working or not...
> You *KNOW* that the SSH server is 'listening' (although not
> necessarily working) when you can connect to the 'port'
> Port?
> Yeah, port...
> Lets move on up in the OSI model to the application layer.
> In order to establish a TCP connection you need an IP
> connection and a port (or a socket and a port)
> The port is to the application what the IP address is to the MAC.
> So if the port is listening, the application is awake.
> And how do we know?
> There are only 975143684 possible ways to validate a 'port is
> open' (or listening) but I am a simple boring guy, so I do:
> telnet localhost 22
> I either get an answer or not.
> If I get an answer, then we are most likely all good, but if I
> don't get an answer then the ramifications are staggering and
> I'm not even going to think about it.
> In order to check that the other port listens then you:
> telnet ${REMOTE} 22
> Again, we either get an answer or not. And the 'not' means
> another Sunday drive to the library...
> Finally, why 22?
> Because that's the SSH port and it is defined in the
> configuration file, which you can change to further complicate
> your (or someone else's) life.
> But who and where defined 22 as the SSH port?
> grep -i ssh /etc/services
> And who wrote /etc/services?
> http://www.iana.org/
> And how do I know all this crap?
> Because I finished LFS!!!! ;-)
> I hope you see everything now as clear as mud.
> Keep this message handy, you'll need to read it several times...
> Keep in mind that what I have written here is a GROSS
> oversimplification of several bookshelves contained in several
> buildings and written along several decades all over the
> World, it's free advice, you can't sue me... :)
> And always remember:
> For every question there exists a simple, direct and wrong answer.
> if you have any question,
> you will get any answer...
> ET
> PS: Research project:
> Why doesn't 'ping' use a port?
> Why is 'ping' 'setuid(ed)'
> What are 'routable' networks?
> What are 'non-routable' networks?
> What does it mean if you get and IP address like
> 169.254.0.0/16 <http://169.254.0.0/16>
> Why do you always have a 127.0.0.1 address in your boxes?
> Who defines (and where are the documents that define) all
> these protocols? (RFC anyone?)
>
>
> Michael Havens writes:
>
> okay, so I bought a used computer to do Linux from scratch
> on. Well, I'm
> going to ssh from my primary computer to the new computer
> but got a
> 'Connection timed out' error. After googling for a bit I
> discovered ufw was
> to blame.
> after I disabled the firewall I could ssh from
> 192.168.1.101 <parasite> to
> 192.168.0.4 <host>
> the error I got going the other way was the connection
> timed out error:
> ssh mike@192.168.1.101 <mailto:mike@192.168.1.101>
> ssh: connect to host 192.168.1.101 port 22: Connection
> timed out
> After googling some more I thought perhaps openssh-server
> wasn't
> installed... but it is. So please.... what is the problem?
> I verifed
> openssh-client is installed but I don't know what it could
> be. Could you
> help me out?
> :-)~MIKE~(-:
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
> <mailto:PLUG-discuss@lists.phxlinux.org>
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>
>
>
>
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
(text/plain)