> so according to your tutorial 192.168.0.x is not on the same subnet as > 192.168.1.x. This is an incomplete statement without the netmask. > If that is correct why can I ssh (and ping and telnet....) > from client to host but not host to client? As stated, the your previous statement is incomplete, so: If they see each other they are in the same subnet with a (at least) /16 netmask or: There is router, well... routing the thing. :) ET Michael Havens writes: > > :-)~MIKE~(-: > > > On Fri, Jul 18, 2014 at 12:30 PM, Michael Havens 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, 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 >>>> to >>>> 192.168.0.4 >>>> the error I got going the other way was the connection timed out error: >>>> ssh mike@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@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@lists.phxlinux.org To subscribe, unsubscribe, or to change your mail settings: http://lists.phxlinux.org/mailman/listinfo/plug-discuss