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