Welcome! » Log In » Create A New Profile

securing ssh keys on backuppc server

Posted by Anonymous 
securing ssh keys on backuppc server
July 28, 2016 03:56AM
Hi,

Just trying to harden security. My concern is if someone had physical access to backuppc server they could easily logon as backuppc user by resetting the password and therefore gain access to the ssh keys. Now I see it is possible to put the ssh keys in an encrypted private directory (See [url=https://help.ubuntu.com/community/EncryptedPrivateDirectory#Storing_Your_Keys.2C_Email_and_other_Data_in_.2BAH4-.2FPrivate]EncryptedPrivateDirectory - Community Help Wiki[/url]). This would mean that even if someone could reset the password and logon as backuppc they wouldn't have access to the keys.

Has anyone done this or would recommend this way or got any other suggestions?

[url=https://help.ubuntu.com/community/EncryptedPrivateDirectory#Storing_Your_Keys.2C_Email_and_other_Data_in_.2BAH4-.2FPrivate]EncryptedPrivateDirectory - Community Help Wiki[/url]Please refer to EncryptedFilesystems for further documentation. See EncryptedHome for details of encrypting your whole home directory rather than a sub-directory as described here.

[url=https://help.ubuntu.com/community/EncryptedPrivateDirectory#Storing_Your_Keys.2C_Email_and_other_Data_in_.2BAH4-.2FPrivate]View on help.ubuntu.com[/url]
Preview by Yahoo
securing ssh keys on backuppc server
July 28, 2016 05:13AM
On 07/28 10:53 , lanceh1412-business < at > yahoo.co.uk wrote:
[quote]Just trying to harden security. My concern is if someone had physical access to backuppc server they could easily logon as backuppc user by resetting the password and therefore gain access to the ssh keys. Now I see it is possible to put the ssh keys in an encrypted private directory (See EncryptedPrivateDirectory - Community Help Wiki). This would mean that even if someone could reset the password and logon as backuppc they wouldn't have access to the keys.
Has anyone done this or would recommend this way or got any other suggestions?
[/quote]
My logic for my setup is:
if someone has access to the BackupPC server, they have all the data on all
the computers being backed up. At that point, the risk is whether they could
modify data on the live server.

To avoid that risk, I don't allow the BackupPC server write access to the
machines being backed up, only read access. The restores aren't really much
more inconvenient (I tend to use tar+netcat for restores on Linux boxen, and
zipfile downloads on Windows boxen), and I feel like I have more confidence
that I'm not going to accidentally clobber the wrong data.

--
Carl Soderstrom
Systems Administrator
Real-Time Enterprises
www.real-time.com

------------------------------------------------------------------------------
_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
securing ssh keys on backuppc server
July 28, 2016 06:07AM
I hadn't really thought about the danger from a restore. I guess that would require quite a bit of technical knowledge of backuppc to engineer an attack on a server? It would require significantly less knowledge to steal the ssh keys on an unencrypted server and then have root access.

On Thursday, 28 July 2016, 13:11, Carl Wilhelm Soderstrom <chrome < at > real-time.com> wrote:

On 07/28 10:53 , lanceh1412-business < at > yahoo.co.uk ([email]lanceh1412-business < at > yahoo.co.uk[/email]) wrote:> Just trying to harden security. My concern is if someone had physical access to backuppc server they could easily logon as backuppc user by resetting the password and therefore gain access to the ssh keys. Now I see it is possible to put the ssh keys in an encrypted private directory (See EncryptedPrivateDirectory - Community Help Wiki). This would mean that even if someone could reset the password and logon as backuppc they wouldn't have access to the keys.> Has anyone done this or would recommend this way or got any other suggestions?
My logic for my setup is:if someone has access to the BackupPC server, they have all the data on allthe computers being backed up. At that point, the risk is whether they couldmodify data on the live server.To avoid that risk, I don't allow the BackupPC server write access to themachines being backed up, only read access. The restores aren't really muchmore inconvenient (I tend to use tar+netcat for restores on Linux boxen, andzipfile downloads on Windows boxen), and I feel like I have more confidencethat I'm not going to accidentally clobber the wrong data.-- Carl SoderstromSystems AdministratorReal-Time Enterpriseswww.real-time.com
securing ssh keys on backuppc server
July 28, 2016 06:24AM
"if someone had physical access to backuppc server they could easily logon as backuppc user by resetting the password"

How would that work?  Unless you leave the backuppc user logged in, they would still need to either know the password or use some sort of hack to get access before being able to reset the password (such as rebooting with a live cd and accessing the OS partition directly).

Always protect physical access to important computers.  If someone has physical access to your server, all bets are off.  Also, if a user account has passwordless ssh keys giving root access to any of your systems, then you should make sure that the account has a strong password (at the least), or that the ssh keys that give access do require (strong) passwords.

Bowie

On 7/28/2016 9:01 AM, lanceh1412-business < at > yahoo.co.uk ([email]lanceh1412-business < at > yahoo.co.uk[/email]) wrote:

[quote] I hadn't really thought about the danger from a restore. I guess that would require quite a bit of technical knowledge of backuppc to engineer an attack on a server? It would require significantly less knowledge to steal the ssh keys on an unencrypted server and then have root access. 

On Thursday, 28 July 2016, 13:11, Carl Wilhelm Soderstrom <chrome < at > real-time.com> ([email]chrome < at > real-time.com[/email]) wrote:

On 07/28 10:53 , lanceh1412-business < at > yahoo.co.uk ([email]lanceh1412-business < at > yahoo.co.uk[/email]) wrote: > Just trying to harden security. My concern is if someone had physical access to backuppc server they could easily logon as backuppc user by resetting the password and therefore gain access to the ssh keys. Now I see it is possible to put the ssh keys in an encrypted private directory (See EncryptedPrivateDirectory - Community Help Wiki). This would mean that even if someone could reset the password and logon as backuppc they wouldn't have access to the keys. > Has anyone done this or would recommend this way or got any other suggestions?
My logic for my setup is: if someone has access to the BackupPC server, they have all the data on all the computers being backed up. At that point, the risk is whether they could modify data on the live server. To avoid that risk, I don't allow the BackupPC server write access to the machines being backed up, only read access. The restores aren't really much more inconvenient (I tend to use tar+netcat for restores on Linux boxen, and zipfile downloads on Windows boxen), and I feel like I have more confidence that I'm not going to accidentally clobber the wrong data. -- Carl Soderstrom Systems Administrator Real-Time Enterprises [url=http://www.real-time.com]www.real-time.com[/url]

[quote]------------------------------------------------------------------------------
[/quote]

[quote]_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net ([email]BackupPC-users < at > lists.sourceforge.net[/email])
List: [url=https://lists.sourceforge.net/lists/listinfo/backuppc-users]https://lists.sourceforge.net/lists/listinfo/backuppc-users[/url]
Wiki: [url=http://backuppc.wiki.sourceforge.net]http://backuppc.wiki.sourceforge.net[/url]
Project: [url=http://backuppc.sourceforge.net/]http://backuppc.sourceforge.net/[/url]
[/quote] [/quote]
securing ssh keys on backuppc server
July 28, 2016 06:40AM
On 07/28 01:01 , lanceh1412-business < at > yahoo.co.uk wrote:
[quote]I hadn't really thought about the danger from a restore. I guess that would require quite a bit of technical knowledge of backuppc to engineer an attack on a server? It would require significantly less knowledge to steal the ssh keys on an unencrypted server and then have root access. 
[/quote]
Oh, on the client machines I have the ssh allowed commands locked down so
that (provided no security flaws are found), the BackupPC process logs in as
an unprivileged user, who automatically runs only the command needed to
backup the data.

Here's a document I wrote up several years ago on how to do this. It's
getting pretty dated (I believe DSA keys are deprecated now, software
versions have changed), but you should
get the general idea.

-=Introduction=-

Here's a quick & dirty explanation of how to set up a client machine to be
backed up with rsync, using sudo and restricted command rights to give some
protection against unauthorized writes. If you are logging in as root on the
hosts to be backed up, then someone cracking the backup server could easily
get access to modify files on the machines being backed up. If you set your
clients up this way, it provides a couple of layers of restriction which
prevent the backup process from being able to modify files.

For purposes of this explanation, I'm going to use 'rsyncbackup' as the
user. It actually doesn't matter what the remote user's name is, so long as
it's unique. (It shouldn't collide with any other username).

--==Setup==--

If you do not have a DSA key pair for passwordless authentication with ssh,
you will need to create one. Otherwise backups would require someone
manually typing in the password every time the backup is run. This is done
with the ssh-keygen command, and you should use the 'dsa' type (instead of
the obsolete rsa type). If you need to create a key, become root and type
the following command:

ssh-keygen -t dsa

If it asks you for a passphrase, just hit <enter>, to avoid putting one in.
Otherwise we're back at the original problem of having to put a password in
whenever a backup should be run.

This will create a pair of files in ~root/.ssh/ called id_dsa and
id_dsa.pub. The id_dsa file is the private side of the keypair, and should
be kept secret. The id_dsa.pub file is the public side of the keypair, and
shoud be put on any remote machine you wish to log into without a password.

-=On the Client Machine to be Backed Up=-
First, create the 'rsyncbackup' user on the intended client machine. Make
the home directory /var/lib/rsyncbackup. This will be the user that we log
in as, and then use sudo to run the actual rsync commands. The actual
command to run is likely to be something resembling:

useradd -r -m -d /var/lib/rsyncbackup -c "Backuppc User" rsyncbackup

Note that the '-r' option is a RedHat-ism (though I believe it applies to
SuSE as well). It creates a 'system' (low-UID) account. On other
distributions (like Debian), just manually assign an unallocated low UID
number.

Once the rsyncbackup user has been created, you will need to create a .ssh
directory to hold the public side of the keypair that the backup user will
log in with.

- First, change to the backup user's home directory.
cd ~rsyncbackup

- Next, make a .ssh directory
mkdir .ssh

- Transfer the public side of the keypair to the client machine by some
mechanism (scp is a good one). You can upload it to /var/tmp/,
temporarily. (You should not be transferring files in as root, so you
wouldn't be able to upload directly to ~rsyncbackup/.ssh). We then transfer
it from there to the ~rsyncbackup/.ssh/authorized_keys file. Note that it is
possible to have multiple keys in the authorized_keys file; but since this
is a brand-new account, we will just move the file into place.
mv /var/tmp/id_dsa.pub ~rsyncbackup/.ssh/authorized_keys

- Next we need to make sure the ownership and permissions on the key file
and directory is correct; otherwise it will not authorize correctly.
chown -R rsyncbackup:users ~rsyncbackup/.ssh
chmod 700 ~rsyncbackup/.ssh

Now edit /etc/sudoers with the 'visudo' command and add some lines to allow
the rsyncbackup user to run the rsync command as root, thereby giving them
access to the whole filesystem. (Without allowing other commands to be run
with access to the whole filesystem).
# allow backup user to run rsync as root
rsyncbackup ALL= NOPASSWD: /usr/bin/rsync

(One should run the 'which rsync' command to verify that rsync is indeed
installed, and what its actual path is. /usr/bin/rsync is just a common
place to find it).

On the backuppc server, su to backuppc ( su - backuppc -s /bin/bash); then
try to ssh to rsyncbackup < at > client. Make sure that works without a password
being entered. if not, check that the permissions and ownership on the
~rsyncbackup/.ssh directory are correct.
Doing this also adds the host to backuppc's list of known_hosts; so it won't
hang waiting for confirmation that the host's key is acceptable.

Make sure when you ssh to the client, that you refer to it by the name you
call it in the backuppc configuration files (so if you will list the machine
in /etc/backuppc/hosts as foo.example.tld, ssh to it as
rsyncbackup < at > foo.example.tld instead of rsyncbackup < at > foo). Otherwise the key
caching will not work, and backups will fail because ssh prompts for
acceptance of the host key.

Now add the rsync/sudo restrictions to the authorized_keys file. Here is a
starting example of what a key might look like (of course, the ...AAA..
section should be replaced with your actual DSA public key). The 'ssh-dss'
is where the automatically-generated part of the key begins. Everything
before that is additional restrictions on what can be done after logging in
with this key.

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="sudo
/usr/bin/rsync --server --sender -logDtpr --exclude='/proc/*'
--exclude='/sys/*' --exclude='/tmp/*' --exclude='/mnt/*'
--exclude='/staff/*' --delete --numeric-ids --block-size=2048 . /" ssh-dss
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
root < at > backupserver.example.tld

-=On the Server=-
Become root on the server again; then go to /etc/backuppc.
Copy one of the other per-host configuration files and edit the options
therein, if necessary.

Add the host to the /etc/backuppc/hosts file, and specify which users should
have authority over it.

You will likely need to restart/rehup the backuppc process, before it will
resolve the hostname of the new box. So run:

/etc/init.d/backuppc reload

Go to the web interface, choose your new host to be backed up from the Host
Summary page by clicking on its link, and click on the 'start full backup'
button for that host.

Check the running processes on the client and server; see if there is an
rsync running on both of them. (Use the 'ps ax' command).
if not, go to the debugging section.

--==Removing Clients==--

If you wish to stop backups of a client; don't remove them from the list of
hosts.
just add the following lines to their config file:

#Going to disable backups for the near-term. Setting FullPeriod=-2 means
#it will never be backed up, and EMailNotifyMinDays=365 means it won't
notify
#about the lack of backups for a year.
$Conf{FullPeriod} = -2;
$Conf{EMailNotifyMinDays} = 365;

--==Debugging==--

In some cases, it may be necessary to put a password on the 'rsyncbackup'
account before DSA logins will be accepted.
you'll see an error in syslog like:
"User rsyncbackup not allowed because account is locked"
Just generate a long string up characters with md5sum against some file, or
the like, and use that as a password. (you'll never need to know it).

If DSA-keyed logins still don't work; make sure the authorized_keys file
hasn't become corrupt. (often happens when you copy-and-paste the key,
you'll miss the first character, or put an extraneous line break in).

On older SSH implementations:
- it's authorized_keys2 instead of authorized_keys
- the authorized_keys2 file must be chmod'ed 600 or 400; even if the
directory is already.

To get more debugging information out of the rsync transfers, in the
per-host configuration file, add the line:
$Conf{RsyncLogLevel} = 6;

Better yet, become backuppc, and try running the BackupPC_dump command by
hand, and look at the output. 99% of the time, this will tell you what's
wrong.
# su - backuppc -s /bin/bash
$ /usr/share/backuppc/bin/BackupPC_dump -v -f berzerker

Note that rsync-2.5.5 is supposedly needed for backuppc-2.0.2 and later.
(tho it looks like rsync-2.4.6 [protocol v24] works anyway).

Rsync protocols >26 should work (maybe lower, don't know); I think protocol
v28 is the current one. the protocol version is apparent when you run
backuppc_dump by hand. if there is a protocol mismatch; the connections will
open, and the rsync process start; but nothing will be transferred.

--
Carl Soderstrom
Systems Administrator
Real-Time Enterprises
www.real-time.com

------------------------------------------------------------------------------
_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
securing ssh keys on backuppc server
July 28, 2016 07:04AM
I'll have a go at that. It looks like it'll make work harder for the enemy!

On Thursday, 28 July 2016, 14:38, Carl Wilhelm Soderstrom <chrome < at > real-time.com> wrote:

On 07/28 01:01 , lanceh1412-business < at > yahoo.co.uk ([email]lanceh1412-business < at > yahoo.co.uk[/email]) wrote:> I hadn't really thought about the danger from a restore. I guess that would require quite a bit of technical knowledge of backuppc to engineer an attack on a server? It would require significantly less knowledge to steal the ssh keys on an unencrypted server and then have root access. Oh, on the client machines I have the ssh allowed commands locked down sothat (provided no security flaws are found), the BackupPC process logs in asan unprivileged user, who automatically runs only the command needed tobackup the data.Here's a document I wrote up several years ago on how to do this. It'sgetting pretty dated (I believe DSA keys are deprecated now, softwareversions have changed), but you shouldget the general idea.-=Introduction=-Here's a quick & dirty explanation of how to set up a client machine to bebacked up with rsync, using sudo and restricted command rights to give someprotection against unauthorized writes. If you are logging in as root on thehosts to be backed up, then someone cracking the backup server could easilyget access to modify files on the machines being backed up. If you set yourclients up this way, it provides a couple of layers of restriction whichprevent the backup process from being able to modify files.For purposes of this explanation, I'm going to use 'rsyncbackup' as theuser. It actually doesn't matter what the remote user's name is, so long asit's unique. (It shouldn't collide with any other username).--==Setup==--If you do not have a DSA key pair for passwordless authentication with ssh,you will need to create one. Otherwise backups would require someonemanually typing in the password every time the backup is run. This is donewith the ssh-keygen command, and you should use the 'dsa' type (instead ofthe obsolete rsa type). If you need to create a key, become root and typethe following command:ssh-keygen -t dsaIf it asks you for a passphrase, just hit <enter>, to avoid putting one in.Otherwise we're back at the original problem of having to put a password inwhenever a backup should be run.This will create a pair of files in ~root/.ssh/ called id_dsa andid_dsa.pub. The id_dsa file is the private side of the keypair, and shouldbe kept secret. The id_dsa.pub file is the public side of the keypair, andshoud be put on any remote machine you wish to log into without a password.-=On the Client Machine to be Backed Up=-First, create the 'rsyncbackup' user on the intended client machine. Makethe home directory /var/lib/rsyncbackup. This will be the user that we login as, and then use sudo to run the actual rsync commands. The actualcommand to run is likely to be something resembling:useradd -r -m -d /var/lib/rsyncbackup -c "Backuppc User" rsyncbackupNote that the '-r' option is a RedHat-ism (though I believe it applies toSuSE as well). It creates a 'system' (low-UID) account. On otherdistributions (like Debian), just manually assign an unallocated low UIDnumber. Once the rsyncbackup user has been created, you will need to create a .sshdirectory to hold the public side of the keypair that the backup user willlog in with.- First, change to the backup user's home directory.cd ~rsyncbackup- Next, make a .ssh directorymkdir .ssh- Transfer the public side of the keypair to the client machine by some mechanism (scp is a good one). You can upload it to /var/tmp/,temporarily. (You should not be transferring files in as root, so youwouldn't be able to upload directly to ~rsyncbackup/.ssh). We then transferit from there to the ~rsyncbackup/.ssh/authorized_keys file. Note that it ispossible to have multiple keys in the authorized_keys file; but since thisis a brand-new account, we will just move the file into place.mv /var/tmp/id_dsa.pub ~rsyncbackup/.ssh/authorized_keys- Next we need to make sure the ownership and permissions on the key file and directory is correct; otherwise it will not authorize correctly.chown -R rsyncbackup:users ~rsyncbackup/.sshchmod 700 ~rsyncbackup/.sshNow edit /etc/sudoers with the 'visudo' command and add some lines to allowthe rsyncbackup user to run the rsync command as root, thereby giving themaccess to the whole filesystem. (Without allowing other commands to be runwith access to the whole filesystem).# allow backup user to run rsync as rootrsyncbackup ALL= NOPASSWD: /usr/bin/rsync (One should run the 'which rsync' command to verify that rsync is indeedinstalled, and what its actual path is. /usr/bin/rsync is just a commonplace to find it).On the backuppc server, su to backuppc ( su - backuppc -s /bin/bash); thentry to ssh to rsyncbackup < at > client. ([email]rsyncbackup < at > client.[/email]) Make sure that works without a passwordbeing entered. if not, check that the permissions and ownership on the~rsyncbackup/.ssh directory are correct.Doing this also adds the host to backuppc's list of known_hosts; so it won'thang waiting for confirmation that the host's key is acceptable.Make sure when you ssh to the client, that you refer to it by the name youcall it in the backuppc configuration files (so if you will list the machinein /etc/backuppc/hosts as foo.example.tld, ssh to it asrsyncbackup < at > foo.example.tld ([email]rsyncbackup < at > foo.example.tld[/email]) instead of rsyncbackup < at > foo ([email]rsyncbackup < at > foo[/email])). Otherwise the keycaching will not work, and backups will fail because ssh prompts foracceptance of the host key.Now add the rsync/sudo restrictions to the authorized_keys file. Here is astarting example of what a key might look like (of course, the ...AAA..section should be replaced with your actual DSA public key). The 'ssh-dss'is where the automatically-generated part of the key begins. Everythingbefore that is additional restrictions on what can be done after logging inwith this key.no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="sudo/usr/bin/rsync --server --sender -logDtpr --exclude='/proc/*'--exclude='/sys/*' --exclude='/tmp/*' --exclude='/mnt/*'--exclude='/staff/*' --delete --numeric-ids --block-size=2048 . /" ssh-dssAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=root < at > backupserver.example.tld ([email]root < at > backupserver.example.tld[/email])-=On the Server=-Become root on the server again; then go to /etc/backuppc.Copy one of the other per-host configuration files and edit the optionstherein, if necessary.Add the host to the /etc/backuppc/hosts file, and specify which users shouldhave authority over it.You will likely need to restart/rehup the backuppc process, before it willresolve the hostname of the new box. So run:/etc/init.d/backuppc reloadGo to the web interface, choose your new host to be backed up from the HostSummary page by clicking on its link, and click on the 'start full backup'button for that host.Check the running processes on the client and server; see if there is anrsync running on both of them. (Use the 'ps ax' command).if not, go to the debugging section.--==Removing Clients==--If you wish to stop backups of a client; don't remove them from the list ofhosts.just add the following lines to their config file:#Going to disable backups for the near-term. Setting FullPeriod=-2 means #it will never be backed up, and EMailNotifyMinDays=365 means it won'tnotify#about the lack of backups for a year.$Conf{FullPeriod} = -2;$Conf{EMailNotifyMinDays} = 365;--==Debugging==--In some cases, it may be necessary to put a password on the 'rsyncbackup'account before DSA logins will be accepted. you'll see an error in syslog like:"User rsyncbackup not allowed
because account is locked"Just generate a long string up characters with md5sum against some file, orthe like, and use that as a password. (you'll never need to know it).If DSA-keyed logins still don't work; make sure the authorized_keys filehasn't become corrupt. (often happens when you copy-and-paste the key,you'll miss the first character, or put an extraneous line break in).On older SSH implementations:- it's authorized_keys2 instead of authorized_keys- the authorized_keys2 file must be chmod'ed 600 or 400; even if the directory is already.To get more debugging information out of the rsync transfers, in theper-host configuration file, add the line:$Conf{RsyncLogLevel} = 6;Better yet, become backuppc, and try running the BackupPC_dump command byhand, and look at the output. 99% of the time, this will tell you what'swrong.# su - backuppc -s /bin/bash$ /usr/share/backuppc/bin/BackupPC_dump -v -f berzerkerNote that rsync-2.5.5 is supposedly needed for backuppc-2.0.2 and later.(tho it looks like rsync-2.4.6 [protocol v24] works anyway).Rsync protocols >26 should work (maybe lower, don't know); I think protocolv28 is the current one. the protocol version is apparent when you runbackuppc_dump by hand. if there is a protocol mismatch; the connections willopen, and the rsync process start; but nothing will be transferred.-- Carl SoderstromSystems AdministratorReal-Time Enterpriseswww.real-time.com
securing ssh keys on backuppc server
July 28, 2016 08:02AM
It is quite easy to reset your user password in ubuntu if you have physical access to the machine. See [url=https://help.ubuntu.com/community/LostPassword]https://help.ubuntu.com/community/LostPassword[/url]. This is why I wanted to encrypt the ssh keys. That way if someone resets the password they can't access the keys.

On Thursday, 28 July 2016, 14:23, Bowie Bailey <Bowie_Bailey < at > BUC.com> wrote:

"if someone had physical access to backuppc server they could easily logon as backuppc user by resetting the password" How would that work? Unless you leave the backuppc user logged in, they would still need to either know the password or use some sort of hack to get access before being able to reset the password (such as rebooting with a live cd and accessing the OS partition directly). Always protect physical access to important computers. If someone has physical access to your server, all bets are off. Also, if a user account has passwordless ssh keys giving root access to any of your systems, then you should make sure that the account has a strong password (at the least), or that the ssh keys that give access do require (strong) passwords. Bowie On 7/28/2016 9:01 AM, lanceh1412-business < at > yahoo.co.uk ([email]lanceh1412-business < at > yahoo.co.uk[/email]) wrote:
[quote] I hadn't really thought about the danger from a restore. I guess that would require quite a bit of technical knowledge of backuppc to engineer an attack on a server? It would require significantly less knowledge to steal the ssh keys on an unencrypted server and then have root access.

On Thursday, 28 July 2016, 13:11, Carl Wilhelm Soderstrom <chrome < at > real-time.com> ([email]chrome < at > real-time.com[/email]) wrote:
On 07/28 10:53 , lanceh1412-business < at > yahoo.co.uk ([email]lanceh1412-business < at > yahoo.co.uk[/email]) wrote: > Just trying to harden security. My concern is if someone had physical access to backuppc server they could easily logon as backuppc user by resetting the password and therefore gain access to the ssh keys. Now I see it is possible to put the ssh keys in an encrypted private directory (See EncryptedPrivateDirectory - Community Help Wiki). This would mean that even if someone could reset the password and logon as backuppc they wouldn't have access to the keys. > Has anyone done this or would recommend this way or got any other suggestions?
My logic for my setup is: if someone has access to the BackupPC server, they have all the data on all the computers being backed up. At that point, the risk is whether they could modify data on the live server. To avoid that risk, I don't allow the BackupPC server write access to the machines being backed up, only read access. The restores aren't really much more inconvenient (I tend to use tar+netcat for restores on Linux boxen, and zipfile downloads on Windows boxen), and I feel like I have more confidence that I'm not going to accidentally clobber the wrong data. -- Carl Soderstrom Systems Administrator Real-Time Enterprises [url=http://www.real-time.com/]www.real-time.com[/url]

[quote]------------------------------------------------------------------------------
[/quote] [quote]_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net ([email]BackupPC-users < at > lists.sourceforge.net[/email])
List: [url=https://lists.sourceforge.net/lists/listinfo/backuppc-users]https://lists.sourceforge.net/lists/listinfo/backuppc-users[/url]
Wiki: [url=http://backuppc.wiki.sourceforge.net/]http://backuppc.wiki.sourceforge.net[/url]
Project: [url=http://backuppc.sourceforge.net/]http://backuppc.sourceforge.net/[/url]
[/quote] [/quote]

------------------------------------------------------------------------------

_______________________________________________BackupPC-users mailing listBackupPC-users < at > lists.sourceforge.net ([email]BackupPC-users < at > lists.sourceforge.net[/email])List: [url=https://lists.sourceforge.net/lists/listinfo/backuppc-users]https://lists.sourceforge.net/lists/listinfo/backuppc-users[/url]Wiki: [url=http://backuppc.wiki.sourceforge.net/]http://backuppc.wiki.sourceforge.net[/url]Project: [url=http://backuppc.sourceforge.net/]http://backuppc.sourceforge.net/[/url]
securing ssh keys on backuppc server
July 28, 2016 09:51AM
If an attacker has physical access to your system, you lose.  That's why data centers and computer rooms in large companies have keycard access, locked racks, and video monitoring.

The best defenses against someone with physical access are a bios password, which will at least force them to shut down and open up the computer to move the jumper around to reset it, or an encrypted filesystem.  However, both of those prevent an unattended remote reboot, which make them unsuited for some applications and the overhead for an encrypted filesystem may make it unsuitable for BackupPC pool storage.

Bowie

On 7/28/2016 10:59 AM, lanceh1412-business < at > yahoo.co.uk ([email]lanceh1412-business < at > yahoo.co.uk[/email]) wrote:

[quote] It is quite easy to reset your user password in ubuntu if you have physical access to the machine. See [url=https://help.ubuntu.com/community/LostPassword]https://help.ubuntu.com/community/LostPassword[/url]. This is why I wanted to encrypt the ssh keys. That way if someone resets the password they can't access the keys.

On Thursday, 28 July 2016, 14:23, Bowie Bailey <Bowie_Bailey < at > BUC.com> ([email]Bowie_Bailey < at > BUC.com[/email]) wrote:

"if someone had physical access to backuppc server they could easily logon as backuppc user by resetting the password" How would that work?  Unless you leave the backuppc user logged in, they would still need to either know the password or use some sort of hack to get access before being able to reset the password (such as rebooting with a live cd and accessing the OS partition directly). Always protect physical access to important computers.  If someone has physical access to your server, all bets are off.  Also, if a user account has passwordless ssh keys giving root access to any of your systems, then you should make sure that the account has a strong password (at the least), or that the ssh keys that give access do require (strong) passwords. Bowie On 7/28/2016 9:01 AM, lanceh1412-business < at > yahoo.co.uk ([email]lanceh1412-business < at > yahoo.co.uk[/email]) wrote:
[quote] I hadn't really thought about the danger from a restore. I guess that would require quite a bit of technical knowledge of backuppc to engineer an attack on a server? It would require significantly less knowledge to steal the ssh keys on an unencrypted server and then have root access. 

On Thursday, 28 July 2016, 13:11, Carl Wilhelm Soderstrom <chrome < at > real-time.com> ([email]chrome < at > real-time.com[/email]) wrote:
On 07/28 10:53 , lanceh1412-business < at > yahoo.co.uk ([email]lanceh1412-business < at > yahoo.co.uk[/email]) wrote: > Just trying to harden security. My concern is if someone had physical access to backuppc server they could easily logon as backuppc user by resetting the password and therefore gain access to the ssh keys. Now I see it is possible to put the ssh keys in an encrypted private directory (See EncryptedPrivateDirectory - Community Help Wiki). This would mean that even if someone could reset the password and logon as backuppc they wouldn't have access to the keys. > Has anyone done this or would recommend this way or got any other suggestions?
My logic for my setup is: if someone has access to the BackupPC server, they have all the data on all the computers being backed up. At that point, the risk is whether they could modify data on the live server. To avoid that risk, I don't allow the BackupPC server write access to the machines being backed up, only read access. The restores aren't really much more inconvenient (I tend to use tar+netcat for restores on Linux boxen, and zipfile downloads on Windows boxen), and I feel like I have more confidence that I'm not going to accidentally clobber the wrong data. -- Carl Soderstrom Systems Administrator Real-Time Enterprises [url=http://www.real-time.com/]www.real-time.com[/url]

[quote]------------------------------------------------------------------------------
[/quote] [quote]_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net ([email]BackupPC-users < at > lists.sourceforge.net[/email])
List: [url=https://lists.sourceforge.net/lists/listinfo/backuppc-users]https://lists.sourceforge.net/lists/listinfo/backuppc-users[/url]
Wiki: [url=http://backuppc.wiki.sourceforge.net/]http://backuppc.wiki.sourceforge.net[/url]
Project: [url=http://backuppc.sourceforge.net/]http://backuppc.sourceforge.net/[/url]
[/quote] [/quote]

------------------------------------------------------------------------------

_______________________________________________ BackupPC-users mailing list BackupPC-users < at > lists.sourceforge.net ([email]BackupPC-users < at > lists.sourceforge.net[/email]) List:    [url=https://lists.sourceforge.net/lists/listinfo/backuppc-users]https://lists.sourceforge.net/lists/listinfo/backuppc-users[/url] Wiki:    [url=http://backuppc.wiki.sourceforge.net/]http://backuppc.wiki.sourceforge.net[/url] Project: [url=http://backuppc.sourceforge.net/]http://backuppc.sourceforge.net/[/url]

[quote]------------------------------------------------------------------------------
[/quote]

[quote]_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net ([email]BackupPC-users < at > lists.sourceforge.net[/email])
List: [url=https://lists.sourceforge.net/lists/listinfo/backuppc-users]https://lists.sourceforge.net/lists/listinfo/backuppc-users[/url]
Wiki: [url=http://backuppc.wiki.sourceforge.net]http://backuppc.wiki.sourceforge.net[/url]
Project: [url=http://backuppc.sourceforge.net/]http://backuppc.sourceforge.net/[/url]
[/quote] [/quote]
securing ssh keys on backuppc server
July 30, 2016 12:12AM
lanceh1412-business < at > yahoo.co.uk schrieb am 28.07.2016 um 16:01:
[quote]I'll have a go at that. It looks like it'll make work harder for the enemy!

[/quote]
Here's another possibility
https://sdeziel.info/backuppc/index.html

I mean the restriction per wrapper script and/or ip within
.ssh/authorized_keys:

command="/usr/local/bin/backuppc-wrapper",from="172.24.30.64,2607:f2c0:f00e:794a::64",no-agent-forwarding,no-port-forwarding,no-user-rc,no-X11-forwarding
ssh-rsa ....

Using this wrapper, only backup is possible - no restore.

Falko

------------------------------------------------------------------------------
_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
Sorry, only registered users may post in this forum.

Click here to login