can't ssh from host to remote

[Michael Havens]

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 at 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 at 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 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 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
>> If yo want to see all variations, you can be lazy (like me) and run:
>> ipcalc 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
>> 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 at 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 at lists.phxlinux.org
>> To subscribe, unsubscribe, or to change your mail settings:
>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phxlinux.org/pipermail/plug-discuss/attachments/20140718/4001b9fb/attachment.html>