can't ssh from host to remote

[Michael Havens]

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/a808c26e/attachment.html>