From: Robert E. W. <rbr...@co...> - 2012-10-10 17:19:22
|
I have been using Backuppc for a few years now. Recently I upgraded my machine to newer, faster hardware. Hence, I have experience exchanging ssh keys, etc. It seems I have one client that refuses to connect via ssh. When I exchanged keys and ran "ssh -l root /[clientip]/ whoami" the client properly returns 'root'. When I "sudo -u backuppc /usr/share/backuppc/BackupPC_dump -v -f /[clienthostname]/" I get 'dump failed: Unable to read 4 bytes'. I have checked versions of rsync, ssh and openssh-server on both the backuppc machine and the client. They are the same on both (both running Ubuntu 12.04LTS.) I have tailed the clients auth.log file it shows "sshd[10109]: Connection closed by /[backuppc-ip]/ [preauth]" so, the backuppc machine is closing the connection. (I might be tailing the wrong file, I am not sure.) Why won't this client connect? -- Robert Wooden Nashville, TN. USA Computer Freedom? . . . Linux |
From: Les M. <les...@gm...> - 2012-10-10 17:32:09
|
On Wed, Oct 10, 2012 at 12:19 PM, Robert E. Wooden <rbr...@co...> wrote: > I have been using Backuppc for a few years now. Recently I upgraded my > machine to newer, faster hardware. Hence, I have experience exchanging ssh > keys, etc. > > It seems I have one client that refuses to connect via ssh. When I exchanged > keys and ran "ssh -l root [clientip] whoami" the client properly returns > 'root'. Are you executing this test as the backuppc user? -- Les Mikesell les...@gm... |
From: Ray F. <ray...@av...> - 2012-10-10 17:38:29
|
What happens when you run sudo -u backuppc rsync -aP root@client:/tmp /tmp/client On Wed, Oct 10, 2012 at 11:19 AM, Robert E. Wooden <rbr...@co...>wrote: > I have been using Backuppc for a few years now. Recently I upgraded my > machine to newer, faster hardware. Hence, I have experience exchanging ssh > keys, etc. > > It seems I have one client that refuses to connect via ssh. When I > exchanged keys and ran "ssh -l root *[clientip]* whoami" the client > properly returns 'root'. When I "sudo -u backuppc > /usr/share/backuppc/BackupPC_dump -v -f *[clienthostname]*" I get 'dump > failed: Unable to read 4 bytes'. > > -- Ray Frush "Either you are part of the solution T:970.288.6223 or part of the precipitate." -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Avago Technologies, Inc. | Technical Computing | IT Engineer |
From: Richard S. <hob...@gm...> - 2012-10-10 17:41:48
|
On Wed, Oct 10, 2012 at 12:19 PM, Robert E. Wooden <rbr...@co...> wrote: > I have been using Backuppc for a few years now. Recently I upgraded my > machine to newer, faster hardware. Hence, I have experience exchanging ssh > keys, etc. > > It seems I have one client that refuses to connect via ssh. When I exchanged > keys and ran "ssh -l root [clientip] whoami" the client properly returns > 'root'. When I "sudo -u backuppc /usr/share/backuppc/BackupPC_dump -v -f > [clienthostname]" I get 'dump failed: Unable to read 4 bytes'. Quick check... When you ran "ssh -l root [client ip] whoami", did you run that as the backuppc user on the server or as root or another user? Richard |
From: Robert E. W. <rbr...@co...> - 2012-10-11 06:34:40
|
Yes, when I ran "ssh -l root [clientip] whoami" I was indeed backuppc user. Thanks Les Mikesell and Richard Shaw. Ray Frush, I ran "admin@wdnbkup01:~$ sudo -u backuppc rsync -aP root@[myclientip]:/tmp /tmp/client [sudo] password for admin: receiving incremental file list created directory /tmp/client tmp/ tmp/.X0-lock 11 100% 10.74kB/s 0:00:00 (xfer#1, to-check=40/42) tmp/indicator-weather-1010.pid 5 100% 0.07kB/s 0:00:00 (xfer#2, to-check=39/42) tmp/qtsingleapp-homebo-c768-3f2 tmp/qtsingleapp-homebo-c768-3f2-lockfile 0 100% 0.00kB/s 0:00:00 (xfer#3, to-check=37/42) tmp/tmp9rfGGH 0 100% 0.00kB/s 0:00:00 (xfer#4, to-check=36/42) tmp/tmpTJVb6u 0 100% 0.00kB/s 0:00:00 (xfer#5, to-check=35/42) tmp/tmpdvZaiW 0 100% 0.00kB/s 0:00:00 (xfer#6, to-check=34/42) tmp/tmpklVFkz 0 100% 0.00kB/s 0:00:00 (xfer#7, to-check=33/42) tmp/unity_support_test.0 0 100% 0.00kB/s 0:00:00 (xfer#8, to-check=32/42) tmp/.ICE-unix/ tmp/.ICE-unix/13650 tmp/.X11-unix/ tmp/.X11-unix/X0 tmp/at-spi2/ tmp/at-spi2/socket-10572-1804289383 tmp/at-spi2/socket-13312-1804289383 tmp/at-spi2/socket-1360-1804289383 tmp/at-spi2/socket-4936-1804289383 tmp/keyring-vALUtM/ tmp/keyring-vALUtM/control tmp/keyring-vALUtM/gpg tmp/keyring-vALUtM/pkcs11 tmp/keyring-vALUtM/ssh tmp/orbit-bob/ tmp/pulse-2L9K88eMlGn7/ tmp/pulse-PKdhtXMmr18n/ tmp/pulse-ikLM6dQvIz5H/ tmp/pulse-ikLM6dQvIz5H/native tmp/pulse-ikLM6dQvIz5H/pid 6 100% 0.07kB/s 0:00:00 (xfer#9, to-check=10/42) tmp/sni-qt_skype_13737-Us8Air/ tmp/sni-qt_skype_13737-Us8Air/icons/ tmp/sni-qt_skype_13737-Us8Air/icons/hicolor/ tmp/sni-qt_skype_13737-Us8Air/icons/hicolor/24x24/ tmp/sni-qt_skype_13737-Us8Air/icons/hicolor/24x24/apps/ tmp/sni-qt_skype_13737-Us8Air/icons/hicolor/24x24/apps/skype_13737_0972e5fde53a4a87346ebb91c4c2b159.png 935 100% 8.70kB/s 0:00:00 (xfer#10, to-check=5/42) tmp/sni-qt_skype_13737-Us8Air/icons/hicolor/24x24/apps/skype_13737_6cbeda8e2c9f56d3ac75ccdf8d282a69.png 888 100% 8.18kB/s 0:00:00 (xfer#11, to-check=4/42) tmp/sni-qt_skype_13737-Us8Air/icons/hicolor/24x24/apps/skype_13737_c2ee5f08e8df31fd4dcef88f95ed4a16.png 1389 100% 12.80kB/s 0:00:00 (xfer#12, to-check=3/42) tmp/sni-qt_skype_13737-Us8Air/icons/hicolor/24x24/apps/skype_13737_dad77418071bead905e2dbe605715dcd.png 968 100% 8.83kB/s 0:00:00 (xfer#13, to-check=2/42) tmp/sni-qt_skype_13737-Us8Air/icons/hicolor/24x24/apps/skype_13737_f2fc4a539a7b9553f5b35241d1154e84.png 911 100% 8.31kB/s 0:00:00 (xfer#14, to-check=1/42) tmp/ssh-UauLqpz13650/ tmp/ssh-UauLqpz13650/agent.13650 sent 376 bytes received 7160 bytes 15072.00 bytes/sec total size is 5113 speedup is 0.68 You clearly know more about rsync than I do. What does this tell you? And for the record, I have three other clients working properly. For what ever reason this particular client (that use to work fine) has decided to resist exchanging keys and after I got it to exchange keys and answer whoami with 'root' still will not backup. Robert Wooden Nashville, TN. USA Computer Freedom? . . . Linux |
From: Ray F. <ray...@av...> - 2012-10-11 15:43:21
|
On Thu, Oct 11, 2012 at 12:34 AM, Robert E. Wooden <rbr...@co...>wrote: > I ran "admin@wdnbkup01:~$ sudo -u backuppc rsync -aP root@[myclientip]:/tmp > /tmp/client > > [sudo] password for admin: > receiving incremental file list > created directory /tmp/client > > I was hoping for some kind of informative failure. But we got none. That rules out the .ssh keys and any obvious mis-configurations. When you rund "BackupPC_dump" part of what it runs is an rsync server on the client to be backed up. The rest of the script is a perl based rsync receiver. backuppc 32396 24278 2 09:31 ? 00:00:00 /usr/bin/perl /usr/share/BackupPC/bin/BackupPC_dump -i hostname backuppc 32406 32396 0 09:31 ? 00:00:00 /usr/bin/ssh -q -x -l root hostname /usr/bin/rsync --server --sender --numeric-ids --perms --owner --group -D --links --hard-links --times --block-size=2048 --recursive . This is where my knowledge breaks down BackupPC_dump tries to talk to the "rsync --server..." running on the client, but in your case it is failing. In our environment that's usually because the client disconnects from the network before any data is transferred. (We backup a lot of laptops that wander around). You'll have to see if there's any evidence that the client becomes "unavailable" after a backup is started. Also check that the 'rsync --server' is actually getting started on the client. -- Ray Frush "Either you are part of the solution T:970.288.6223 or part of the precipitate." -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Avago Technologies, Inc. | Technical Computing | IT Engineer |
From: Robert E. W. <rbr...@co...> - 2012-10-11 16:13:23
|
Thanks everyone. I will add that I am not running SELinux nor am I running ufw (Ubuntu firewall.) I am an Ubuntu OS house. I have even considered a ssh blacklist but, I cannot find one anywhere (unless I am looking in the wrong directories.) I am beginning to consider possible hardware issues but, it worked before I re-installed the OS. So, that doesn't make much sense. What can this issue be??? Robert Wooden Nashville, TN. USA Computer Freedom? . . . Linux |
From: Les M. <les...@gm...> - 2012-10-11 16:51:15
|
On Thu, Oct 11, 2012 at 11:13 AM, Robert E. Wooden <rbr...@co...> wrote: > Thanks everyone. > > I will add that I am not running SELinux nor am I running ufw (Ubuntu > firewall.) > > I am an Ubuntu OS house. > > I have even considered a ssh blacklist but, I cannot find one anywhere > (unless I am looking in the wrong directories.) > > I am beginning to consider possible hardware issues but, it worked > before I re-installed the OS. So, that doesn't make much sense. > > What can this issue be??? One other thing that can cause trouble is any output sent before the rsync program starts (from /etc/profile, .bashrc, etc.). Stock rsync will ignore that and work anyway, but the backuppc implementation will fail. I didn't see any in your test, but perhaps you didn't paste the entire results. Also, you might look at /var/log/secure on the target system to see if any problem is reported for the ssh connection. -- Les Mikesell les...@gm... |
From: Robert E. W. <rbr...@co...> - 2012-10-13 06:10:27
|
I still haven't figured this out so I ran the following: admin@wdnbkup01:~$ su backuppc Password: $ ssh -vvv root@bob-desktop2 OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to bob-desktop2 [192.168.242.120] port 22. >>>>>>>>>>>>>>>> snip <<<<<<<<<<<<<<<<<<<<<<<<< >>>>>>>>>>>>>>>> snip <<<<<<<<<<<<<<<<<<<<<<<<< debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel_input_status_confirm: type 99 id 0 debug2: PTY allocation request accepted on channel 0 debug2: channel 0: rcvd adjust 2097152 debug2: channel_input_status_confirm: type 99 id 0 debug2: shell request accepted on channel 0 Welcome to Ubuntu 12.04.1 LTS (GNU/Linux 3.2.0-32-generic x86_64) * Documentation: https://help.ubuntu.com/ Last login: Fri Oct 12 11:52:49 2012 from wdnbkup01 root@bob-desktop2:~# As you can see, it logs into root@bob-desktop2 like it is suppose too! I know very little about rsync. But, doesn't this mean I have an issue with rsync? (Ok, somebodies gonna just say it, then yes, it is time to learn rsync but, if you think I am heading in the correct direction, please, please let me know.) Robert Wooden Nashville, TN. USA Computer Freedom? . . . Linux |
From: Robert E. W. <rbr...@co...> - 2012-10-13 13:33:46
|
I work nights, so, last night when I got home I sent my previous email. This morning I got up early and while (software) updating my backuppc server I decided to try "sudo -u backuppc /usr/share/backuppc/BackupPC_dump -v -f [clienthostname]" and the client is backup as I write this. What happened, I am asking myself. Last night I was running "ssh -vvv [clienthostname]" to test my ssh connection. ssh was 'complaining' that I had some bad lines in my /var/lib/backuppc/.ssh/known_hosts file. I removed those 'bad lines' with "ssh-keygen -f "/var/lib/backuppc/.ssh/known_hosts" -R bob-desktop2" and long story short, this morning (half asleep) decided to let my backuppc server fail again trying to backuppc this troubled client. To my amazement, half asleep, it did not fail! Thank you everyone for your help. Somehow, during this journey, I stumbled onto the solution but, I might never have found it without the help of the mailing list. So, thank you everyone! Robert Wooden Nashville, TN. USA Computer Freedom? . . . Linux |
From: Tyler J. W. <ty...@to...> - 2012-10-13 15:08:44
|
On 2012-10-13 14:33, Robert E. Wooden wrote: > What happened, I am asking myself. Last night I was running "ssh -vvv > [clienthostname]" to test my ssh connection. ssh was 'complaining' that I > had some bad lines in my /var/lib/backuppc/.ssh/known_hosts file. I removed > those 'bad lines' with "ssh-keygen -f "/var/lib/backuppc/.ssh/known_hosts" > -R bob-desktop2" and long story short, this morning (half asleep) decided > to let my backuppc server fail again trying to backuppc this troubled > client. To my amazement, half asleep, it did not fail! Some related SSH tips: 1. Remove your known_hosts file now. 2. Create an ~/.ssh/config file, owned by the right user, mode 644, containing: HashKnownHosts no StrictHostKeyChecking no This means that: 1. Lines will be added to known_hosts without prompting (no more pressing yes to accept new fingerprints). 2. Key mismatches will be tolerated with SSH key logins. A warning will be printed, and password logins are still blocked. 3. Lines added to known_hosts will have a readable host/ip entry at the begin of line. This makes removing conflicts easier. Some people think this reduces security. It does. But I consider it a fair balance versus usability, especially when you work with a large number of hosts. Regards, Tyler -- "Human subcultures are nested fractally. There's no bottom." -- Randal Munrow, http://xkcd.com/1095/ |
From: Robert E. W. <rbr...@co...> - 2012-10-13 20:14:10
|
I'll keep this for future reference. Thanks! Robert Wooden Nashville, TN. USA Computer Freedom? . . . Linux On 10/13/2012 10:08 AM, Tyler J. Wagner wrote: > On 2012-10-13 14:33, Robert E. Wooden wrote: >> What happened, I am asking myself. Last night I was running "ssh -vvv >> [clienthostname]" to test my ssh connection. ssh was 'complaining' that I >> had some bad lines in my /var/lib/backuppc/.ssh/known_hosts file. I removed >> those 'bad lines' with "ssh-keygen -f "/var/lib/backuppc/.ssh/known_hosts" >> -R bob-desktop2" and long story short, this morning (half asleep) decided >> to let my backuppc server fail again trying to backuppc this troubled >> client. To my amazement, half asleep, it did not fail! > Some related SSH tips: > > 1. Remove your known_hosts file now. > 2. Create an ~/.ssh/config file, owned by the right user, mode 644, containing: > > HashKnownHosts no > StrictHostKeyChecking no > > This means that: > > 1. Lines will be added to known_hosts without prompting (no more pressing > yes to accept new fingerprints). > 2. Key mismatches will be tolerated with SSH key logins. A warning will be > printed, and password logins are still blocked. > 3. Lines added to known_hosts will have a readable host/ip entry at the > begin of line. This makes removing conflicts easier. > > Some people think this reduces security. It does. But I consider it a fair > balance versus usability, especially when you work with a large number of > hosts. > > Regards, > Tyler > |
From: Pedro M. S. O. <pms...@gm...> - 2012-10-11 08:51:56
|
Hi, If you are using a redhat 6 or one of it's clients check if you're using selinux. If so configure it's policies to allow ssh with keys loggin or put it in permissive mode. Check redhat documentation for details. Cheers, Pedro Oliveira http://www.linux-geex.com On Oct 10, 2012 6:25 PM, "Robert E. Wooden" <rbr...@co...> wrote: > I have been using Backuppc for a few years now. Recently I upgraded my > machine to newer, faster hardware. Hence, I have experience exchanging ssh > keys, etc. > > It seems I have one client that refuses to connect via ssh. When I > exchanged keys and ran "ssh -l root *[clientip]* whoami" the client > properly returns 'root'. When I "sudo -u backuppc > /usr/share/backuppc/BackupPC_dump -v -f *[clienthostname]*" I get 'dump > failed: Unable to read 4 bytes'. > > I have checked versions of rsync, ssh and openssh-server on both the > backuppc machine and the client. They are the same on both (both running > Ubuntu 12.04LTS.) > > I have tailed the clients auth.log file it shows "sshd[10109]: Connection > closed by *[backuppc-ip]* [preauth]" so, the backuppc machine is closing > the connection. (I might be tailing the wrong file, I am not sure.) > > Why won't this client connect? > > -- > Robert Wooden > Nashville, TN. USA > > Computer Freedom? . . . Linux > > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > BackupPC-users mailing list > Bac...@li... > List: https://lists.sourceforge.net/lists/listinfo/backuppc-users > Wiki: http://backuppc.wiki.sourceforge.net > Project: http://backuppc.sourceforge.net/ > > |