can't ssh from host to remote

[kitepilot at kitepilot.com]

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~(-: