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. :) 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. 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 > 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 > > 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