Mike, whenever you see "connection refused", it's usually a layer 4
issue (osi model here), meaning you don't have a service listening on
the port (ie. openssh-server not installed/running), or there's a
firewall blocking you (that sends rst/fin's back). I'm loathe to say
firewalls even, as there IS no firewall local to a vlan (unless your
network engineers get crazy with vlan acl's on managed enterprise gear).
Pick up a CCNA/N+ book, would do you some good to understand layer 1-4
troubleshooting, but it's something like this:
Test Layer 1 - Link light on both ports to a switch, check
Test Layer 2 - Look for arp entries after you try to pass traffic, no
arp, no vlan/switch communication, check
Test layer 3 - Ping between devices, if ping works, move to layer 4
Test layer 4 - Telnet to the tcp service port (ssh==22), if you can't
connect or refused, check the service or for presence of firewall, if
you can, app issue - go to os/app
"sudo netstat -anp | grep tcp | grep LISTEN" is your friend, look for
the port/service listening to make sure it is accepting connections,
like for ssh you'll see "0.0.0.0:22 0.0.0.0:* LISTEN". This means it
is accepting connections on port 22 on/for all ip's, which is what you
want for public services. Worst case, try to telnet localhost 22
locally to make sure it works there, that'll disprove firewalls in the mix.
This is quite basic, but usually good enough for most appdev's that come
beating me about the ears with "network problems" to diagnose their own
poop first. Usually ends up with something stupid like "service wasn't
running" or "opps, it only bound itself to listen on
localhost/127.0.0.1)". Much like here. :)
<rant>
Unfortunately I've found in most rapid development/deployment
methodologies (umm, microsofties mostly), they instill this mindset of
"you don't have to know networking, call this magical function that
makes data appear in your buffer - easy see!", at least until it doesn't
work the first time. Anything else == "contact your network
administrator", and they wonder why network people hate nothing more
than to see an app person walking toward them with a clueless, panicked
look on their face. Network engineers hate this, as more often than
not, the services they're trying to use simply don't work, and they have
no idea how to even troubleshoot it (neither of which amount to a
network problem per se, just theirs). Developers really need taught
some network 101 (and beyond actually) with how to use their servers still.
</rant>
Funny part is I don't usually have this issue with unix apps/devs, as
most unix/linux admins are forced by nature to know what a tcp/udp
socket is, and how it works.
As a network guy, I learned AD, Windoze server stuff, and even
Unix/Linux to simply be able to combat clueless users on my networks,
including most sysadmins that don't understand networking. Not to say
they're all clueless in general, but most that deal with network-based
services know far less networking than they should. Simply telling them
their apps are broken are not sufficient, more often than not even
telling them why it's broken is not sufficient, but simply I end up
having to log in, and fix it for them as they have no concept of a tcp
socket or how they work.
-mb
On 07/10/2012 11:20 PM, Michael Havens wrote:
> and that, my friend solved the problem! openssh-server was not installed
> on the laptop but openssh-client was. Now that both client and server
> are installed on both systems they both rsync in both directions again.
> Yipee!
> Thank you so much.
>
> On Tue, Jul 10, 2012 at 10:32 PM, James Dugger <james.dugger@gmail.com
> <mailto:james.dugger@gmail.com>> wrote:
>
> Type: dpkg --get-selections | grep openssh-* to find out if Openssh
> is installed on the system. If it is you should see the following:
>
> openssh-client install
> openssh-server install
>
> To install it if it isn't installed type: sudo apt-get install
> openssh-server
> --
> James
>
>
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> <mailto:PLUG-discuss@lists.plug.phoenix.az.us>
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>
>
>
>
> --
> :-)~MIKE~(-:
>
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)