can't ssh from host to remote
Gilbert T. Gutierrez, Jr.
mailing-lists at phoenixinternet.net
Fri Jul 18 15:34:39 MST 2014
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
pass the communication through.
Gilbert
On 7/18/2014 2:44 PM, Michael Havens wrote:
> 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
> <mailto: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
> <mailto: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 <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 at 192.168.1.101 <mailto: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
> <mailto:PLUG-discuss at 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 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/143e630a/attachment.html>
More information about the PLUG-discuss
mailing list