Re: can't ssh from host to remote

Top Page
Attachments:
Message as email
+ (text/plain)
+ (text/html)
+ (text/plain)
Delete this message
Reply to this message
Author: Gilbert T. Gutierrez, Jr.
Date:  
To: Main PLUG discussion list
Subject: Re: can't ssh from host to remote
Mike, what I was trying to walk you through is outlined on several web
pages if you do a search. I have included one of those links for your
convenience. Your provided modem/router (router 1) uses either DSL or
Cable for its WAN/Internet port. I would heavily suggest against you
making any changes to router 1. SOHO routers typically have a cluster of
ports which can be lumped together under the title LAN. Most SOHO
routers will have a port off the side from that grouping to help you
distinguish the fact that it is the WAN/Internet port.

http://library.techguy.org/wiki/Connecting_two_SOHO_broadband_routers_together

Gilbert


On 7/20/2014 8:19 PM, Michael Havens wrote:
> there is my problem..... I can't get into the settings page of the
> extra router. hmmmm. I tried lynx from the computer w/o (one of the
> computers connected to it) the gui and now it is asking for login
> credentials.... I wonder what they are? found it! Okay... well lynx is
> useless with this!
>
> Goofy me..... I can use my brother's computer (which is connected to
> the router in question). There is a setting for DHCP Server.... I'll
> disable that!
> As for setting it to bridge mode...
> I think there is one setting it might be: a choice in the operating
> mode between "Gateway" and "Router"
>
> Thanks for letting me know about the LAN ports.
>
> :-)~MIKE~(-:
>
>
> On Sun, Jul 20, 2014 at 6:47 PM, sean <
> <mailto:sean.a.ritzler@gmail.com>> wrote:
>
>     You don't have to change the firmware. Just make your extra wireless
>     device a wireless bridge + ethernet switch without DHCP. Problem
>     solved. By the way, those 4 ports ARE the LAN ports.

>
>     On Sun, Jul 20, 2014 at 6:44 PM, Michael Havens <
>     <mailto:bmike1@gmail.com>> wrote:
>     > 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
>     < <mailto:bmike1@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
>     < <mailto:bmike1@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
>     < <mailto:bmike1@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.
>     >>>> <
>     <mailto:mailing-lists@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
>     < <mailto:bmike1@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, <
>     <mailto:kitepilot@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@192.168.1.101 <mailto: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 -
>     
>     <mailto: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 - 
>     <mailto: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 - 
>     <mailto: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 - 
>     <mailto: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 - 
>     <mailto: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 -
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.phxlinux.org/mailman/listinfo/plug-discuss


---------------------------------------------------
PLUG-discuss mailing list -
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss