Re: Rsync: Re: password prompts
On Sat, Apr 07, 2001 at 02:53:13AM +0100, M. Drew Streib wrote: The net-net is: On the box accepting the connection w/o a password from another box with the private key, the security of the accepting box is _only_ as good as the account on the originating box. Strike that "w/o a password" and I agree. Here is the principle I try to teach people: If any host is broken into, NO MATTER WHAT AUTHENTICATION MECHANISM IS USED to connect from there to a second host, the second host can also be broken into. If your password has to pass through the compromised host, it can be discovered. The vulnerability on the second host can be limited only by what the compromised host is permitted to do on the second host, such as some of the schemes that have been discussed here with the ssh authorized_keys. - Dave Dykstra
Re: Rsync: Re: password prompts (fwd)
On Sat, Apr 07, 2001 at 08:00:19PM +0100, L. Cranswick wrote: FTP and Rsync via SSH to update files - how many users do this? I don't think I have persuaded one person to do this - they all think it too inconvenient - too much new stuff to learn - and it takes discipline to stick with it. I hate to be a bofh, but... If decent security is "too inconvenient", then I refuse to be responsible for the compromised box. Good security takes discipline, in any implementation. As for the rsync integration: It is only a simple ssh setup and a '-e ssh'. Is that _really_ too much to ask? -drew -- M. Drew Streib [EMAIL PROTECTED], http://dtype.org "Email sigs waste valuable bandwidth." PGP signature
Re: Rsync: Re: password prompts (fwd)
Indeed, the biggest reason to use an external ssh program is that it
makes security updates *someone else's* problem -- ideally someone who
cares and/or is good at it. ("Put all your eggs in one basket and
*watch that basket*" :-) Seriously, when an ssh bug comes up (and more
will - it's written in C after all) we don't need the additional
leverage provided *to the attacker* of having to fix related attacks
in N different programs - we just have to fix ssh itself. Yay
abstraction.
That's exactly the way I like it as well. :) I had occaision once to
need passwordless rsyncing, but there was no way I was going to just plain
allow passwordless SSH.
So I recompiled OpenSSH to use a different port, and have a different name
(BrokenSSH, or "bs" for short). I installed it on the receiving box in a
chrooted environment, configured its sshd_config and ran it thorugh tcp
wrappers so that only one account could be accessed from only one
IP. Then I just called it on the sending box with rsync's -e
switch. rsync -varpogte bs --stats /var/www/ incoming@mirror:/var/www/
Are there any good tutorials on this?
One thing that is rarely stated is the amount of time and extra effort
needed to set things up. While in theory, users could be tunnelling
FTP and Rsync via SSH to update files - how many users do this?
I don't think I have persuaded one person to do this - they all
think it too inconvenient - too much new stuff to learn - and it
takes discipline to stick with it.
A tutorial I have done on this is at:
http://www.ccp14.ac.uk/ccp14admin/security/secure_routine_web_update_rsync.html
"Secure Routine Windows to UNIX Web updating using tunnelling
via Teraterm and Rsync"
But I don't know of anyone I know personally who can be bothered
with this - so protocols with clear text passwords are still the
done thing.
(Many of these secure techniques also assume admin rights on the remote
machine. Or that the remote admin has plenty of time to spend helping out
on this things. Both flawed assuptions.)
Re comments in previous Email about ease and convenience.
Microsoft is not the power it is today due to writing
good, solid software: they rule the world because they
write "convenient to use" software compared to rivals.
When given the choice of solid implementations, or
"convenience of use" - 99% of the population go for
"convenience of use". I believe the challenge of
Open Source software is to have "both" solid implementations
and convenience of use.
Lachlan.
--
Lachlan M. D. Cranswick
Geochemistry - Lamont-Doherty Earth Observatory, Columbia University
PO Box 1000, 61 Route 9W Palisades, New York 10964-1000 USA
Tel: (845) 365-8662 Fax: (845) 365-8155
E-mail: [EMAIL PROTECTED] WWW: http://www.ldeo.columbia.edu
CCP14 Xtal Software Website: http://www.ccp14.ac.uk
Re: Rsync: Re: password prompts (fwd)
On Sat, 7 Apr 2001, L. Cranswick wrote: So I recompiled OpenSSH to use a different port, and have a different name (BrokenSSH, or "bs" for short). I installed it on the receiving box in a chrooted environment, configured its sshd_config and ran it thorugh tcp wrappers so that only one account could be accessed from only one IP. Then I just called it on the sending box with rsync's -e switch. rsync -varpogte bs --stats /var/www/ incoming@mirror:/var/www/ Are there any good tutorials on this? Not yet. :) But, I might be persuaded to write one. Although, most people don't like the documentation I write, becuase my tendency would be to just make an RPM of the modified SSH rather than to write a HOWTO. One thing that is rarely stated is the amount of time and extra effort needed to set things up. While in theory, users could be tunnelling FTP and Rsync via SSH to update files - how many users do this? I don't think I have persuaded one person to do this - they all think it too inconvenient - too much new stuff to learn - and it takes discipline to stick with it. All my users. I'm mean. But, every single user that I've taught ssh/scp/rsync to has found them easier to use than telnet/ftp. I think it's all in the delivery - Most people teach SSH with "It might sound more complicated, but it's more secure," while I start off with "This is a lot easier once you've done it once or twice, and it's more secure too!" (Many of these secure techniques also assume admin rights on the remote machine. Or that the remote admin has plenty of time to spend helping out on this things. Both flawed assuptions.) Yup. I can't count the number of times I've installed sshd in my homedir on someone else's box that didn't want to run it. The only problem is that I have to make it listen on a higher port. But it gets really scary when I do this and the admins don't notice. I tell them, of course, but I think a good admin should be able to notice this stuff on their own. -- Rob Russell Senior Systems Analyst 613-224-6676 x332N-able Technologies fax: 613-228-1399http://www.N-ableIT.com 877-655-4689 [EMAIL PROTECTED]
Re: Rsync: Re: password prompts
On Sat, 7 Apr 2001, Randy Kramer wrote: I don't think our descriptions are very different, but why, once you create the account with restricted file permission is it called "chrooted" -- does the user of the account think it's a root account, or is it just that it's his "root" account, as a synonym for "home" account? Must you do something to make the restricted account "chrooted"? (I guess I'll have to look up "chroot" on google or similar.) chroot is the act of changing the root directory of a filesystem as it appears to the process. (man 1 chroot) So, if I make an [x]inetd entry that calls "chroot /var/ssh sshd" instead of sshd, then when inetd passes the connection on to sshd, sshd will see the directory /var/sshd as its root directory, and what it sees as /etc/passwd would actually be /var/sshd/etc/passwd on your real filesystem. The tricky part is building the fake filesystem so that it has everything it needs (ls, mkdir, rsync, libraries) but nothing that can be used to do anything nasty. The system also makes sure that so far as sshd knows, /var/ssh/.. is a link to /var/ssh. A good sysadmin can even build a chrooted filesystem such that users don't even know they're in a chrooted environment. Other resources (processes, memory, etc.) are the same in a chroot, it's only the filesystem that gets changed. You should be able to look in /var/ftp for an example - that's where ftpd chroots itself when an anonymous connection is made. -- Rob Russell Senior Systems Analyst 613-224-6676 x332N-able Technologies fax: 613-228-1399http://www.N-ableIT.com 877-655-4689 [EMAIL PROTECTED]
Rsync: Re: password prompts
Might there be a good set of tutorials on the web on how to do this while minimizing the risk of exposing systems as a consequence? (setup of private/public identity files that minimize the risk of hackers getting passwordless access to other remote machines). I must admit hating the passwordless ssh system - and possible implementation flaws that risk compromising remote systems. (But maybe that is just personal ignorance which can still be corrected?) Again, I think having a form of cut down ssh inside rsync would be a far better option for limiting security problems both when using rsync with and without external ssh programs. (e.g., giving a user easy rsync only access. - such things can be done via the Proftpd deamon for FTP only accounts) Lachlan. On Fri, Apr 06, 2001 at 05:42:25PM -0600, David Salisbury wrote: Is there a way to have rsync not prompt for a password. I've tried using .shosts and also the authorized_keys files, but neither seem to work. Is there anyway to modify the rsh or ssh commands that rsync uses? I assume you're using ssh and .ssh/authorized_keys. rsync, when using ssh as a transport, _cannot_ do anything that ssh can't do. You'll need to work out the ability to ssh without a password first. rsync does not perform its own authentication in the modes you're using, and thus is not in control of the problem you're having. If rsync could override your other system authentication, then you'd have a different problem. :) If you do want to ssh without a password, you should look into sshagent, or the ability to create a key with no password and use of an authorized_keys file. Get this to work with ssh before trying it with rsync. -drew -- M. Drew Streib [EMAIL PROTECTED], http://dtype.org "Email sigs waste valuable bandwidth." Attachment Converted: C:\Eudora\Attach\Re password prompts --- Lachlan M. D. Cranswick Geochemistry - Lamont-Doherty Earth Observatory, Columbia University PO Box 1000, 61 Route 9W Palisades, New York 10964-1000 USA Tel: (845) 365-8662 Fax: (845) 365-8155 E-mail: [EMAIL PROTECTED] WWW: http://www.ldeo.columbia.edu CCP14 Xtal Software Website: http://www.ccp14.ac.uk
Re: Rsync: Re: password prompts
Lachlan, Excuse me for jumping into this discussion, especially being something of a newbie. As I understand ssh without passwords, it is very secure because it is based on a public / private key scheme, something like PGP. When you set up a passwordless ssh system, you create a public and private key, and then you upload your public key to the remote server that you want to communicate with (and which is using an ssh something -- a server, I think). The ssh server can apply your public key to confirm that anything that comes in claiming to be from you really is from you, and similarly anything sent to you is encoded with your public key, so only your ssh client can decode it with your private key. Now, I may be wrong in my understanding, but, for a moment, please assume I'm right. If I am right, and the security provided by a passwordless ssh connection is just as good as, for example, PGP (assume I'm right about that too, please, for a moment), then do you still have concerns about ssh passwordless security? If so, is it because you don't trust the public / private key approach used by systems like PGP? Now, stopping again for a moment, if I am right in what I say above, I think I would be very happy with rsync not attempting to build a cut down form of ssh within itself, but instead keep a modular approach -- let rsync do what it does best, and, when appropriate, let rsync use the external ssh mechanism to provide security (which the external ssh would presumably do better than any cut down version of ssh within rsync). This modular approach also has the advantages of keeping rsync smaller, and allowing rsync to use a different and better security system than ssh if it comes into being. Thanks, Randy Kramer Lachlan Cranswick wrote: Might there be a good set of tutorials on the web on how to do this while minimizing the risk of exposing systems as a consequence? (setup of private/public identity files that minimize the risk of hackers getting passwordless access to other remote machines). I must admit hating the passwordless ssh system - and possible implementation flaws that risk compromising remote systems. (But maybe that is just personal ignorance which can still be corrected?) Again, I think having a form of cut down ssh inside rsync would be a far better option for limiting security problems both when using rsync with and without external ssh programs. (e.g., giving a user easy rsync only access. - such things can be done via the Proftpd deamon for FTP only accounts) Lachlan. On Fri, Apr 06, 2001 at 05:42:25PM -0600, David Salisbury wrote: Is there a way to have rsync not prompt for a password. I've tried using .shosts and also the authorized_keys files, but neither seem to work. Is there anyway to modify the rsh or ssh commands that rsync uses? I assume you're using ssh and .ssh/authorized_keys. rsync, when using ssh as a transport, _cannot_ do anything that ssh can't do. You'll need to work out the ability to ssh without a password first. rsync does not perform its own authentication in the modes you're using, and thus is not in control of the problem you're having. If rsync could override your other system authentication, then you'd have a different problem. :) If you do want to ssh without a password, you should look into sshagent, or the ability to create a key with no password and use of an authorized_keys file. Get this to work with ssh before trying it with rsync. -drew -- M. Drew Streib [EMAIL PROTECTED], http://dtype.org "Email sigs waste valuable bandwidth." Attachment Converted: C:\Eudora\Attach\Re password prompts --- Lachlan M. D. Cranswick Geochemistry - Lamont-Doherty Earth Observatory, Columbia University PO Box 1000, 61 Route 9W Palisades, New York 10964-1000 USA Tel: (845) 365-8662 Fax: (845) 365-8155 E-mail: [EMAIL PROTECTED] WWW: http://www.ldeo.columbia.edu CCP14 Xtal Software Website: http://www.ccp14.ac.uk
Re: Rsync: Re: password prompts
On Fri, Apr 06, 2001 at 09:33:04PM -0400, Randy Kramer wrote: Now, I may be wrong in my understanding, but, for a moment, please assume I'm right. If I am right, and the security provided by a passwordless ssh connection is just as good as, for example, PGP (assume I'm right about that too, please, for a moment), then do you still have concerns about ssh passwordless security? The net-net is: On the box accepting the connection w/o a password from another box with the private key, the security of the accepting box is _only_ as good as the account on the originating box. If the originating box is secure, then the passwordless ssh is also secure. The issue isn't really cracking ssh (for most applications), but rather whether or not you want the possibility that someone might crack your 'master' account and thus have your private key and passwordless access to some other number of boxes. As for implementing ssh inside of rsync, I'd like to continue to reiterate what a bad idea I think that is. Security is enough pain without worrying about every program carrying its own security model and implementation (and possible exploits). -drew -- M. Drew Streib [EMAIL PROTECTED], http://dtype.org "Email sigs waste valuable bandwidth." PGP signature
Re: Rsync: Re: password prompts
As for implementing ssh inside of rsync, I'd like to continue to reiterate what a bad idea I think that is. Security is enough pain without worrying about every program carrying its own security model and implementation (and possible exploits). What if such a feature was an optional module that was compiled in? Every program that is visible as a deamon on the internet carries a security model. At present rsync has a free text password as its model - just like FTP. This makes it inherently insecure compared to an encrupted password system. Lachlan. --- Lachlan M. D. Cranswick Geochemistry - Lamont-Doherty Earth Observatory, Columbia University PO Box 1000, 61 Route 9W Palisades, New York 10964-1000 USA Tel: (845) 365-8662 Fax: (845) 365-8155 E-mail: [EMAIL PROTECTED] WWW: http://www.ldeo.columbia.edu CCP14 Xtal Software Website: http://www.ccp14.ac.uk
Re: Rsync: Re: password prompts
Hello Lachlan, Lachlan Cranswick wrote: (Before waffling on a side tracked issue - there is still a request for good web based passwordless ssh tutorials) I don't really have anything to offer -- I learned some about public / private key systems over a lot of years starting with a signature system for signing contractor time sheets ~10 years ago (using an RSA product). I'm starting to use ssh to communicate with SourceForge, but the tutorials they have are focused on how to use ssh rather than "security theory". The remote machine can only confirm that someone/anyone has the correct key file. (authorised user or someone else - a hacker/cracker) You're right about that. Having it on my own machine makes me feel fairly secure, but ... So rather than only giving a hacker passwordless limited access to the rsync function on a remote machine - the hacker is getting complete access via ssh. At least (or only) to everything he is privileged to do on that remote machine. (Isn't having private key files like putting your pin number with your VISA/Mastercard/Cashcard? If the hacker gets into your machine (or a backup tape/cd-rom) and gets the private file?) Yes, if he get into your machine. If your machine is in a semi-public place (like a business or school), this could be more of a problem than if you have control of physical access to your machine. I'd have to think some more about your next two paragraphs -- I may respond later. I guess, recognizing that the developers of rsnyc don't have unlimited resources, I'd rather see them concentrate on rsync than be diverted to incorporate ssh into rsync. Not fully understanding the ramifications of chroot (as a Linux newbie) I don't really know whether limiting someone's access by chrooting is any more effective than limiting his access based on privileges provided to his account. Probably will give me something to learn about over the next several months. ;-) I would thus still put the argument that having an ssh system inside rsync could be very effective as if a client machine is hacked/cracked and rsync passwords are obtained - they are chrooted to some extent to what the rsync permissions will allow in terms of uploading and downloading files. Or at minimum - the hacker is in a more frustrated situation with respect to using these rsync passwords to "crack" a remote machine. However if they get the ssh private file - (which in the case of this discussion - was only generated to allow for secure rsync) then the world is their oyster(?) Having ssh inside rsync also means that only an rsync account has to be provided on the server rather than a complete ssh user account. One problem with UNIX is its habit of giving "all or nothing" when you may want something in between. (In this case only having an rsync based account) Lachlan. PS: If keeping rsync small is a priority for some people - compiling in an ssh module could be an option - as is done with apache modules to expand functionality. If people feel ssh is essential, I would prefer that it be a module. Thanks for the response! Randy Kramer
Re: Rsync: Re: password prompts
Not fully understanding the ramifications of chroot (as a Linux newbie) I don't really know whether limiting someone's access by chrooting is any more effective than limiting his access based on privileges provided to his account. Re: rsync, ssh, security and keeping hackers out. (just my 2 cents worth) While chroot'ing may be considered flawed: given 99% of present hacking seems to be by the unskilled running auto-scripts - (looking for suckers who have unpatched systems or setup flaws): anything that frustrates these scripts, minimizes un-needed services and/or provides "non-standard" (rsync?) chrooted environments which requiring custom/non-automated skills to overcome are going to be effective to a large degree. (also using a deception toolkit on all exposed and unexposed servers and UNIX clients (minimicking services) can also make things more interesting: e.g., http://www.all.net/dtk ) E.g., For running a remotely mirrored UNIX webserver - nothing more is needed than webserver(apache) and rsync. And, if given remote admin rights, a very tight custom OpenSSH install(?) Passwordless secureshell accounts for tunnelling rsync through is potentially one degree of freedom too many(!?) As the above confirms my irrational bigotry against passwordless ssh (and the various extra complications of getting it right) - I will now take my tablets and try and calm down. Lachlan. --- Lachlan M. D. Cranswick Geochemistry - Lamont-Doherty Earth Observatory, Columbia University PO Box 1000, 61 Route 9W Palisades, New York 10964-1000 USA Tel: (845) 365-8662 Fax: (845) 365-8155 E-mail: [EMAIL PROTECTED] WWW: http://www.ldeo.columbia.edu CCP14 Xtal Software Website: http://www.ccp14.ac.uk
