Re: can't ssh from host to remote

>>> 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?)