Re: Best way to duplicate HDs--talk more about rsync+ssh system
quote who=Patrick Hsieh 3) Add this to authorized_keys for the above account, specifying the command that logins with this key are allowed to run. See command= in sshd(1). I can't find the document about this section, can you show me some reference or examples? Many thanks. man sshd, down the bottom. - Jeff -- No clue is good clue.
Re: Best way to duplicate HDs--talk more about rsync+ssh system
3) Add this to authorized_keys for the above account, specifying the command that logins with this key are allowed to run. See command= in sshd(1). I can't find the document about this section, can you show me some reference or examples? Many thanks. -- Patrick Hsieh [EMAIL PROTECTED] GPG public key http://pahud.net/pubkeys/pahudatpahud.gpg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Best way to duplicate HDs--talk more about rsync+ssh system
3) Add this to authorized_keys for the above account, specifying the command that logins with this key are allowed to run. See command= in sshd(1). I can't find the document about this section, can you show me some reference or examples? Many thanks. -- Patrick Hsieh [EMAIL PROTECTED] GPG public key http://pahud.net/pubkeys/pahudatpahud.gpg
Re: Best way to duplicate HDs--talk more about rsync+ssh system
Hello Ted, Your mail is very informative to me. I wonder how to define cmd to run automatically in authorized_hosts? I thought there's nothing but pub keys in authorized_hosts file. And, do I need ssh-agent in this case? Do I need to leave passphrase blank? Thank you for your patience and kindness. On Wed, Jan 02, 2002 at 03:15:20PM +0800, Patrick Hsieh wrote: I've read some doc. using ssh-keygen to generate key pairs, appending the public keys to ~/.ssh/authorized_hosts on another host to prevent ssh authentication prompt. Is it very risky? Chances are a cracker could compromise one machine and ssh login others without any authentication. use ssh-keygen to generate a new key for *every* machine, and *every* application you want to use. In the authorized_hosts section, you limit what a single key can do by specifying a cmd that is run automatically... in other words, use of the key executes only the command you want, and not simply a shell. That does not limit an attacker from exploiting whatever the passwordless identity cmds you've setup, but they can't run rampant w/ root over an entire machine. -- Ted Deppner http://www.psyber.com/~ted/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Patrick Hsieh [EMAIL PROTECTED] GPG public key http://pahud.net/pubkeys/pahudatpahud.gpg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Best way to duplicate HDs--talk more about rsync+ssh system
quote who=Patrick Hsieh OK. My problem is, if I use rsync+ssh with blank passphrase among servers to automate rsync+ssh backup procedure without password prompt, then the cracker will not need to send any password as well as passphrase when ssh login onto another server, right? No, password and rsa/dsa authentication are different authentication mechanisms. Is there a good way to automate rsync+ssh procedure without password/passphrase prompt, while password/passphrase is still requierd when someone attempts to ssh login? 1) Use a minimally-privileged account for the rsync process, disable the password on this account, so it cannot be used to login. 2) Generate a passphrase-less ssh key with ssh_keygen. 3) Add this to authorized_keys for the above account, specifying the command that logins with this key are allowed to run. See command= in sshd(1). Thus, no one can actually log in with the account normally, you can only connect with the rsa/dsa key, and you can only run a particular process. ssh-agent doesn't really help you in this instance, it's generally used to provide single passphrase authentication for a user's session. (I use it to log in to the ~30-40 machines I have my public key on, without typing passwords every five minutes.) - Jeff -- jwz? no way man, he's my idle - James Wilkinson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Best way to duplicate HDs--talk more about rsync+ssh system
On Wed, Jan 02, 2002 at 03:35:43PM +0800, Patrick Hsieh wrote: OK. My problem is, if I use rsync+ssh with blank passphrase among servers to automate rsync+ssh backup procedure without password prompt, then the cracker will not need to send any password as well as passphrase when ssh login onto another server, right? Is there a good way to automate rsync+ssh procedure without password/passphrase prompt, while password/passphrase is still requierd when someone attempts to ssh login? quote who=Patrick Hsieh I am sorry I could be kind of off-topic. But I want to know how to cross-site rsync without authentication, say ssh auth.,? That's the best way. I've read some doc. using ssh-keygen to generate key pairs, appending the public keys to ~/.ssh/authorized_hosts on another host to prevent ssh authentication prompt. Is it very risky? Chances are a cracker could compromise one machine and ssh login others without any authentication. It's not without authentication - you're still authenticating, you're just using a different means. There's two parts to rsa/dsa authentication with ssh; first there's the key, then there's the passphrase. If a cracker gets your key, that's tough, but they'll need the passphrase to authenticate. If you make a key without a passphrase (generally what you'd do for scripted rsyncs, etc) then they *only need the key*. So, you should keep the data available with passphrase-less keys either read-only or backed up, depending on its importance, etc. Automation with keys stored on machines is better than doing it manually and forgetting to back up. :-) It **does** provide a path by which someone can gain access from one machine to another. Even accounts with minimal privs can be compromised. We happen to be in process of overhauling our backup architecture. We're installing rsyncd (daemons) on the client machines, and initiating rsync -e ssh backups from a dedicated backup machine on a private LAN with non-routable addresses. That machine packages up the backups and spools them off for storage elsewhere. The [modules] in rsyncd.conf provide a nice way to package what you want to back up. You can also specify what ip addresses connect to rsyncd. So in theory only the backup machine can connect to the rsyncd daemons; we've set those to read-only. It **seems** that even though we are pulling the data of with rsync -e ssh there is no need for a key on the server machine. Maybe I was working on it too late last night; at any rate, tcpdump will tell. Can it build an ssh tunnel without keys at both ends? YMMV. The idea is that if someone got root on the client machines, the only additional path they would have to backups is an interface on the private LAN. Not foolproof, but lower hanging fruit elsewhere would be easier picking. cfm -- Christopher F. Miller, Publisher [EMAIL PROTECTED] MaineStreet Communications, Inc 208 Portland Road, Gray, ME 04039 1.207.657.5078 http://www.maine.com/ Content/site management, online commerce, internet integration, Debian linux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Best way to duplicate HDs--talk more about rsync+ssh system
ssh-agent does help here. Have the cron job which is doing the backup look to see if there's an ssh agent running as its user (presumably 'backup', maybe root) and if not send mail to somebody's pager, complaining about the missing agent. If the agent is running, the cron job can reconnect to it and use it for authentication. It's still possible for a cracker to get the passphrased key, and to plant a keystroke logger to get your passphrase. Getting a usable key out of the agent is *hard*. -Brian -- Brian Sniffen [EMAIL PROTECTED] msg04668/pgp0.pgp Description: PGP signature
Re: Best way to duplicate HDs--talk more about rsync+ssh system
On Wed, Jan 02, 2002 at 09:19:11AM -0500, [EMAIL PROTECTED] wrote: Automation with keys stored on machines is better than doing it manually and forgetting to back up. :-) Agreed. Like excercise, the kind you do is better than the kind you don't. It **does** provide a path by which someone can gain access from one machine to another. Even accounts with minimal privs can be compromised. A universal fact, hopefully known to all list members. The [modules] in rsyncd.conf provide a nice way to package what you want to back up. You can also specify what ip addresses connect to rsyncd. So in theory only the backup machine can connect to the rsyncd daemons; we've set those to read-only. Ack! If you're doing file level rsync backups to rsyncd, rsyncd *must* be running as root (DON'T DO THAT), else your perms will be useless. rsyncd just isn't something that should run with root perms... therefore it's rather useless for file level rsync backups. If you tar up the source, and send those to your rsyncd that's less of a security risk from rsyncd itself, HOWEVER your root only file data is now in a userland tar file, so your data is now less secure on the backup server than it was on the source machine. Very bad backup design. It **seems** that even though we are pulling the data of with rsync -e ssh there is no need for a key on the server machine. Maybe I was working on it too late last night; at any rate, tcpdump will tell. Can it build an ssh tunnel without keys at both ends? YMMV. No need to guess. if you're using one :, your using rsh by default unless modified by -e or RSYNC_RSH. If you're using two ::, you're using rsyncd. The idea is that if someone got root on the client machines, the only additional path they would have to backups is an interface on the private LAN. Not foolproof, but lower hanging fruit elsewhere would be easier picking. Maybe, maybe not. If they can get all the goodies off your backup server, without having to break all the security of the source machines, you're still just as comprimised. -- Ted Deppner http://www.psyber.com/~ted/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Best way to duplicate HDs--talk more about rsync+ssh system
On Wed, Jan 02, 2002 at 10:17:38AM -0800, Ted Deppner wrote: The [modules] in rsyncd.conf provide a nice way to package what you want to back up. You can also specify what ip addresses connect to rsyncd. So in theory only the backup machine can connect to the rsyncd daemons; we've set those to read-only. Ack! If you're doing file level rsync backups to rsyncd, rsyncd *must* be running as root (DON'T DO THAT), else your perms will be useless. rsyncd just isn't something that should run with root perms... therefore it's rather useless for file level rsync backups. We're pulling **from** a read-only rsyncd. It has to run as root because we require the right archive, permissions, etc I'm confused; is that much different from running an rsync otherwise except for the convenience of the [modules] thing? Or is rsync wrong tool for job? We want to reduce the load on the production servers. Some clients need 4x daily backups, but for others nothing changes for months at a time. The new system is only going to snapshot and archive only the changed versions, not every day. All the zipping, sorting and file checking will take place on backup machine, not on servers so we don't care how greedy the process gets as long as the process pulling the mirror off the production machine is as light as possible. Is there something better than rsync for that? If you tar up the source, and send those to your rsyncd that's less of a security risk from rsyncd itself, HOWEVER your root only file data is now in a userland tar file, so your data is now less secure on the backup server than it was on the source machine. Very bad backup design. I must have described it poorly: dedicated backup machine, no other services, no random users, private routing on physically separate lan, outbound connections only. I'd hope that would be better than a production server. -- Christopher F. Miller, Publisher [EMAIL PROTECTED] MaineStreet Communications, Inc 208 Portland Road, Gray, ME 04039 1.207.657.5078 http://www.maine.com/ Content/site management, online commerce, internet integration, Debian linux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Best way to duplicate HDs--talk more about rsync+ssh system
[cc: trimed to something a little more sane] On Wed, Jan 02, 2002 at 04:21:33PM -0500, [EMAIL PROTECTED] wrote: We're pulling **from** a read-only rsyncd. It has to run as root because we require the right archive, permissions, etc I'm confused; is that much different from running an rsync otherwise except for the convenience of the [modules] thing? Or is rsync wrong tool for job? To, from, no difference. rsyncd uses cleartext transport (it appears to do a challenge/response for the password). using ssh for the transport (no rsyncd), gives you encrypted data on the network, and password management in the form of identity keys. I trust rsync to move files around in a convient manner. I trust ssh to transport data in a secure manner. I do not trust rsync to be secure. If you deeply trust your private network, trust programs not written with security in mind to be secure, and don't mind your data being exposed (during transport) as a result of your backup system, maybe this isn't a big concern for you. We want to reduce the load on the production servers. Some clients need 4x daily backups, but for others nothing changes for months at a time. The new system is only going to snapshot and archive only the changed versions, not every day. All the zipping, sorting and file checking will take place on backup machine, not on servers so we don't care how greedy the process gets as long as the process pulling the mirror off the production machine is as light as possible. Is there something better than rsync for that? rsync is a fine tool for that. All I'm suggesting is you don't use rsyncd for your data transport and that you use something more secure, eg ssh. [rsyncd] backup-server# rsync -avrP production::everything /backups/production/ - relying on rsync for password (if used) and transport security - keys are stored plaintext (or not at all w/ your read-only rsyncd design) becomes [ssh] production# RSYNC_RSH='ssh -c blowfish -i pathto/bkup-identity' rsync -avrP / backup-server:/backups/production/ - relying on ssh for password (or identity key), and transport security - keys stored encrypted, (passwordless identities or via ssh-agent) -- Ted Deppner http://www.psyber.com/~ted/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Best way to duplicate HDs--talk more about rsync+ssh system
Hello, I am sorry I could be kind of off-topic. But I want to know how to cross-site rsync without authentication, say ssh auth.,? I've read some doc. using ssh-keygen to generate key pairs, appending the public keys to ~/.ssh/authorized_hosts on another host to prevent ssh authentication prompt. Is it very risky? Chances are a cracker could compromise one machine and ssh login others without any authentication. Idea? On Tue, Jan 01, 2002 at 08:39:39AM -0500, Keith Elder wrote: This brings up a question. How do you rsync something but keep the ownership and permissions the same. I am pulling data off site nightly and that works, but the permissions are all screwed up. rsync -avxrP --delete $FILESYSTEMS backup-server:backups/$HOSTNAME Some caveats if you want to fully automate this... - remove -vP (verbose w/ progress) - --delete is NECESSARY to make sure deleted files get deleted from the backup - FILESYSTEMS should be any local filesystems you want backed up (-x won't cross filesystems, makes backing up in NFS environment easier) - obviously this doesn't preclude a bad guy checking out backup-server:backups/otherhostname (use ssh keys, and invoke cmd=cd backups/hostname; rsync with whatever daemon options will limit that) -- Patrick Hsieh [EMAIL PROTECTED] GPG public key http://pahud.net/pubkeys/pahudatpahud.gpg
Re: Best way to duplicate HDs--talk more about rsync+ssh system
quote who=Patrick Hsieh I am sorry I could be kind of off-topic. But I want to know how to cross-site rsync without authentication, say ssh auth.,? That's the best way. I've read some doc. using ssh-keygen to generate key pairs, appending the public keys to ~/.ssh/authorized_hosts on another host to prevent ssh authentication prompt. Is it very risky? Chances are a cracker could compromise one machine and ssh login others without any authentication. It's not without authentication - you're still authenticating, you're just using a different means. There's two parts to rsa/dsa authentication with ssh; first there's the key, then there's the passphrase. If a cracker gets your key, that's tough, but they'll need the passphrase to authenticate. If you make a key without a passphrase (generally what you'd do for scripted rsyncs, etc) then they *only need the key*. So, you should keep the data available with passphrase-less keys either read-only or backed up, depending on its importance, etc. - Jeff -- I think we agnostics need a term for a holy war too. I feel all left out. - George Lebl
Re: Best way to duplicate HDs--talk more about rsync+ssh system
OK. My problem is, if I use rsync+ssh with blank passphrase among servers to automate rsync+ssh backup procedure without password prompt, then the cracker will not need to send any password as well as passphrase when ssh login onto another server, right? Is there a good way to automate rsync+ssh procedure without password/passphrase prompt, while password/passphrase is still requierd when someone attempts to ssh login? quote who=Patrick Hsieh I am sorry I could be kind of off-topic. But I want to know how to cross-site rsync without authentication, say ssh auth.,? That's the best way. I've read some doc. using ssh-keygen to generate key pairs, appending the public keys to ~/.ssh/authorized_hosts on another host to prevent ssh authentication prompt. Is it very risky? Chances are a cracker could compromise one machine and ssh login others without any authentication. It's not without authentication - you're still authenticating, you're just using a different means. There's two parts to rsa/dsa authentication with ssh; first there's the key, then there's the passphrase. If a cracker gets your key, that's tough, but they'll need the passphrase to authenticate. If you make a key without a passphrase (generally what you'd do for scripted rsyncs, etc) then they *only need the key*. So, you should keep the data available with passphrase-less keys either read-only or backed up, depending on its importance, etc. - Jeff -- I think we agnostics need a term for a holy war too. I feel all left out. - George Lebl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Patrick Hsieh [EMAIL PROTECTED] GPG public key http://pahud.net/pubkeys/pahudatpahud.gpg
Re: Best way to duplicate HDs--talk more about rsync+ssh system
On Wed, Jan 02, 2002 at 03:15:20PM +0800, Patrick Hsieh wrote: I've read some doc. using ssh-keygen to generate key pairs, appending the public keys to ~/.ssh/authorized_hosts on another host to prevent ssh authentication prompt. Is it very risky? Chances are a cracker could compromise one machine and ssh login others without any authentication. use ssh-keygen to generate a new key for *every* machine, and *every* application you want to use. In the authorized_hosts section, you limit what a single key can do by specifying a cmd that is run automatically... in other words, use of the key executes only the command you want, and not simply a shell. That does not limit an attacker from exploiting whatever the passwordless identity cmds you've setup, but they can't run rampant w/ root over an entire machine. -- Ted Deppner http://www.psyber.com/~ted/
Re: Best way to duplicate HDs--talk more about rsync+ssh system
Hello Ted, Your mail is very informative to me. I wonder how to define cmd to run automatically in authorized_hosts? I thought there's nothing but pub keys in authorized_hosts file. And, do I need ssh-agent in this case? Do I need to leave passphrase blank? Thank you for your patience and kindness. On Wed, Jan 02, 2002 at 03:15:20PM +0800, Patrick Hsieh wrote: I've read some doc. using ssh-keygen to generate key pairs, appending the public keys to ~/.ssh/authorized_hosts on another host to prevent ssh authentication prompt. Is it very risky? Chances are a cracker could compromise one machine and ssh login others without any authentication. use ssh-keygen to generate a new key for *every* machine, and *every* application you want to use. In the authorized_hosts section, you limit what a single key can do by specifying a cmd that is run automatically... in other words, use of the key executes only the command you want, and not simply a shell. That does not limit an attacker from exploiting whatever the passwordless identity cmds you've setup, but they can't run rampant w/ root over an entire machine. -- Ted Deppner http://www.psyber.com/~ted/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Patrick Hsieh [EMAIL PROTECTED] GPG public key http://pahud.net/pubkeys/pahudatpahud.gpg
Re: Best way to duplicate HDs--talk more about rsync+ssh system
quote who=Patrick Hsieh OK. My problem is, if I use rsync+ssh with blank passphrase among servers to automate rsync+ssh backup procedure without password prompt, then the cracker will not need to send any password as well as passphrase when ssh login onto another server, right? No, password and rsa/dsa authentication are different authentication mechanisms. Is there a good way to automate rsync+ssh procedure without password/passphrase prompt, while password/passphrase is still requierd when someone attempts to ssh login? 1) Use a minimally-privileged account for the rsync process, disable the password on this account, so it cannot be used to login. 2) Generate a passphrase-less ssh key with ssh_keygen. 3) Add this to authorized_keys for the above account, specifying the command that logins with this key are allowed to run. See command= in sshd(1). Thus, no one can actually log in with the account normally, you can only connect with the rsa/dsa key, and you can only run a particular process. ssh-agent doesn't really help you in this instance, it's generally used to provide single passphrase authentication for a user's session. (I use it to log in to the ~30-40 machines I have my public key on, without typing passwords every five minutes.) - Jeff -- jwz? no way man, he's my idle - James Wilkinson
Re: Best way to duplicate HDs--talk more about rsync+ssh system
On Wed, Jan 02, 2002 at 03:35:43PM +0800, Patrick Hsieh wrote: OK. My problem is, if I use rsync+ssh with blank passphrase among servers to automate rsync+ssh backup procedure without password prompt, then the cracker will not need to send any password as well as passphrase when ssh login onto another server, right? Is there a good way to automate rsync+ssh procedure without password/passphrase prompt, while password/passphrase is still requierd when someone attempts to ssh login? quote who=Patrick Hsieh I am sorry I could be kind of off-topic. But I want to know how to cross-site rsync without authentication, say ssh auth.,? That's the best way. I've read some doc. using ssh-keygen to generate key pairs, appending the public keys to ~/.ssh/authorized_hosts on another host to prevent ssh authentication prompt. Is it very risky? Chances are a cracker could compromise one machine and ssh login others without any authentication. It's not without authentication - you're still authenticating, you're just using a different means. There's two parts to rsa/dsa authentication with ssh; first there's the key, then there's the passphrase. If a cracker gets your key, that's tough, but they'll need the passphrase to authenticate. If you make a key without a passphrase (generally what you'd do for scripted rsyncs, etc) then they *only need the key*. So, you should keep the data available with passphrase-less keys either read-only or backed up, depending on its importance, etc. Automation with keys stored on machines is better than doing it manually and forgetting to back up. :-) It **does** provide a path by which someone can gain access from one machine to another. Even accounts with minimal privs can be compromised. We happen to be in process of overhauling our backup architecture. We're installing rsyncd (daemons) on the client machines, and initiating rsync -e ssh backups from a dedicated backup machine on a private LAN with non-routable addresses. That machine packages up the backups and spools them off for storage elsewhere. The [modules] in rsyncd.conf provide a nice way to package what you want to back up. You can also specify what ip addresses connect to rsyncd. So in theory only the backup machine can connect to the rsyncd daemons; we've set those to read-only. It **seems** that even though we are pulling the data of with rsync -e ssh there is no need for a key on the server machine. Maybe I was working on it too late last night; at any rate, tcpdump will tell. Can it build an ssh tunnel without keys at both ends? YMMV. The idea is that if someone got root on the client machines, the only additional path they would have to backups is an interface on the private LAN. Not foolproof, but lower hanging fruit elsewhere would be easier picking. cfm -- Christopher F. Miller, Publisher [EMAIL PROTECTED] MaineStreet Communications, Inc 208 Portland Road, Gray, ME 04039 1.207.657.5078 http://www.maine.com/ Content/site management, online commerce, internet integration, Debian linux
Re: Best way to duplicate HDs--talk more about rsync+ssh system
ssh-agent does help here. Have the cron job which is doing the backup look to see if there's an ssh agent running as its user (presumably 'backup', maybe root) and if not send mail to somebody's pager, complaining about the missing agent. If the agent is running, the cron job can reconnect to it and use it for authentication. It's still possible for a cracker to get the passphrased key, and to plant a keystroke logger to get your passphrase. Getting a usable key out of the agent is *hard*. -Brian -- Brian Sniffen [EMAIL PROTECTED] pgpsrBkku8pYc.pgp Description: PGP signature
Re: Best way to duplicate HDs--talk more about rsync+ssh system
On Wed, Jan 02, 2002 at 09:19:11AM -0500, [EMAIL PROTECTED] wrote: Automation with keys stored on machines is better than doing it manually and forgetting to back up. :-) Agreed. Like excercise, the kind you do is better than the kind you don't. It **does** provide a path by which someone can gain access from one machine to another. Even accounts with minimal privs can be compromised. A universal fact, hopefully known to all list members. The [modules] in rsyncd.conf provide a nice way to package what you want to back up. You can also specify what ip addresses connect to rsyncd. So in theory only the backup machine can connect to the rsyncd daemons; we've set those to read-only. Ack! If you're doing file level rsync backups to rsyncd, rsyncd *must* be running as root (DON'T DO THAT), else your perms will be useless. rsyncd just isn't something that should run with root perms... therefore it's rather useless for file level rsync backups. If you tar up the source, and send those to your rsyncd that's less of a security risk from rsyncd itself, HOWEVER your root only file data is now in a userland tar file, so your data is now less secure on the backup server than it was on the source machine. Very bad backup design. It **seems** that even though we are pulling the data of with rsync -e ssh there is no need for a key on the server machine. Maybe I was working on it too late last night; at any rate, tcpdump will tell. Can it build an ssh tunnel without keys at both ends? YMMV. No need to guess. if you're using one :, your using rsh by default unless modified by -e or RSYNC_RSH. If you're using two ::, you're using rsyncd. The idea is that if someone got root on the client machines, the only additional path they would have to backups is an interface on the private LAN. Not foolproof, but lower hanging fruit elsewhere would be easier picking. Maybe, maybe not. If they can get all the goodies off your backup server, without having to break all the security of the source machines, you're still just as comprimised. -- Ted Deppner http://www.psyber.com/~ted/
Re: Best way to duplicate HDs--talk more about rsync+ssh system
[cc: trimed to something a little more sane] On Wed, Jan 02, 2002 at 04:21:33PM -0500, [EMAIL PROTECTED] wrote: We're pulling **from** a read-only rsyncd. It has to run as root because we require the right archive, permissions, etc I'm confused; is that much different from running an rsync otherwise except for the convenience of the [modules] thing? Or is rsync wrong tool for job? To, from, no difference. rsyncd uses cleartext transport (it appears to do a challenge/response for the password). using ssh for the transport (no rsyncd), gives you encrypted data on the network, and password management in the form of identity keys. I trust rsync to move files around in a convient manner. I trust ssh to transport data in a secure manner. I do not trust rsync to be secure. If you deeply trust your private network, trust programs not written with security in mind to be secure, and don't mind your data being exposed (during transport) as a result of your backup system, maybe this isn't a big concern for you. We want to reduce the load on the production servers. Some clients need 4x daily backups, but for others nothing changes for months at a time. The new system is only going to snapshot and archive only the changed versions, not every day. All the zipping, sorting and file checking will take place on backup machine, not on servers so we don't care how greedy the process gets as long as the process pulling the mirror off the production machine is as light as possible. Is there something better than rsync for that? rsync is a fine tool for that. All I'm suggesting is you don't use rsyncd for your data transport and that you use something more secure, eg ssh. [rsyncd] backup-server# rsync -avrP production::everything /backups/production/ - relying on rsync for password (if used) and transport security - keys are stored plaintext (or not at all w/ your read-only rsyncd design) becomes [ssh] production# RSYNC_RSH='ssh -c blowfish -i pathto/bkup-identity' rsync -avrP / backup-server:/backups/production/ - relying on ssh for password (or identity key), and transport security - keys stored encrypted, (passwordless identities or via ssh-agent) -- Ted Deppner http://www.psyber.com/~ted/
Re: Best way to duplicate HDs--talk more about rsync+ssh system
quote who=Patrick Hsieh I am sorry I could be kind of off-topic. But I want to know how to cross-site rsync without authentication, say ssh auth.,? That's the best way. I've read some doc. using ssh-keygen to generate key pairs, appending the public keys to ~/.ssh/authorized_hosts on another host to prevent ssh authentication prompt. Is it very risky? Chances are a cracker could compromise one machine and ssh login others without any authentication. It's not without authentication - you're still authenticating, you're just using a different means. There's two parts to rsa/dsa authentication with ssh; first there's the key, then there's the passphrase. If a cracker gets your key, that's tough, but they'll need the passphrase to authenticate. If you make a key without a passphrase (generally what you'd do for scripted rsyncs, etc) then they *only need the key*. So, you should keep the data available with passphrase-less keys either read-only or backed up, depending on its importance, etc. - Jeff -- I think we agnostics need a term for a holy war too. I feel all left out. - George Lebl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Best way to duplicate HDs--talk more about rsync+ssh system
OK. My problem is, if I use rsync+ssh with blank passphrase among servers to automate rsync+ssh backup procedure without password prompt, then the cracker will not need to send any password as well as passphrase when ssh login onto another server, right? Is there a good way to automate rsync+ssh procedure without password/passphrase prompt, while password/passphrase is still requierd when someone attempts to ssh login? quote who=Patrick Hsieh I am sorry I could be kind of off-topic. But I want to know how to cross-site rsync without authentication, say ssh auth.,? That's the best way. I've read some doc. using ssh-keygen to generate key pairs, appending the public keys to ~/.ssh/authorized_hosts on another host to prevent ssh authentication prompt. Is it very risky? Chances are a cracker could compromise one machine and ssh login others without any authentication. It's not without authentication - you're still authenticating, you're just using a different means. There's two parts to rsa/dsa authentication with ssh; first there's the key, then there's the passphrase. If a cracker gets your key, that's tough, but they'll need the passphrase to authenticate. If you make a key without a passphrase (generally what you'd do for scripted rsyncs, etc) then they *only need the key*. So, you should keep the data available with passphrase-less keys either read-only or backed up, depending on its importance, etc. - Jeff -- I think we agnostics need a term for a holy war too. I feel all left out. - George Lebl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Patrick Hsieh [EMAIL PROTECTED] GPG public key http://pahud.net/pubkeys/pahudatpahud.gpg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Best way to duplicate HDs--talk more about rsync+ssh system
On Wed, Jan 02, 2002 at 03:15:20PM +0800, Patrick Hsieh wrote: I've read some doc. using ssh-keygen to generate key pairs, appending the public keys to ~/.ssh/authorized_hosts on another host to prevent ssh authentication prompt. Is it very risky? Chances are a cracker could compromise one machine and ssh login others without any authentication. use ssh-keygen to generate a new key for *every* machine, and *every* application you want to use. In the authorized_hosts section, you limit what a single key can do by specifying a cmd that is run automatically... in other words, use of the key executes only the command you want, and not simply a shell. That does not limit an attacker from exploiting whatever the passwordless identity cmds you've setup, but they can't run rampant w/ root over an entire machine. -- Ted Deppner http://www.psyber.com/~ted/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
