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