can't ssh from host to remote

Sun Jul 20 18:44:36 MST 2014

cool.... apparently if I do the firmware upgrade I'll be able to receive as
well as send.

:-)~MIKE~(-:

On Sun, Jul 20, 2014 at 6:17 PM, Michael Havens <bmike1 at gmail.com> wrote:

> I think I should give you the models of my devices:
> the router is a wrt54g and the modem is a pk5000. I did a little more
> searching and read that I can change the firmware on the router but if
> memory is correct if I screw up it becomes a brick so I need to ask what
> the benefits are and if there is another way to do it. I just looked
> closely at the router and it is labled as a wireless router and a 4 port
> switch.
>
> :-)~MIKE~(-:
>
>
> On Sat, Jul 19, 2014 at 11:39 AM, Michael Havens <bmike1 at gmail.com> wrote:
>
>> >Why were rules written for the second router but not the first?
>> >Is it because it was connected first? Could we write the rules we need?
>>
>> What I meant was the second was connected to the first.
>>
>>
>> :-)~MIKE~(-:
>>
>>
>> On Sat, Jul 19, 2014 at 11:31 AM, Michael Havens <bmike1 at gmail.com>
>> wrote:
>>
>>> > Going the other way, you have no rules to pass
>>> > the communication through.
>>>
>>> Why were rules written for the second router but not the first? Is it
>>> because it was connected first? Could we write the rules we need?
>>>
>>>
>>> :-)~MIKE~(-:
>>>
>>>
>>> On Fri, Jul 18, 2014 at 3:34 PM, Gilbert T. Gutierrez, Jr. <
>>> mailing-lists at phoenixinternet.net> wrote:
>>>
>>>>  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>
>>>> 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> 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
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------
>>>> 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
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------
>>>> 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/20140720/949f74a3/attachment.html>