(I have merged two replies into one - I hope nobody minds, I think it should be easier to keep track of one thread rather then two+) On Wed, Jun 30, 1999 at 11:51:40AM +0100, Philip Hands wrote: > The push mirrors use them. > > A push mirror admin can install the ``ftpsync'' script, without > trusting master, or any of it's users more than being willing to start > that script when asked to. > > The worst that could be done is a DOS attempt by starting it fifty > times a second, and there are easier ways of doing DOSs, that don't > require you to break into master first. Interesting - I always assumed that limiting what commands a given public key can execute was a nice feature, but didn't realize anyone actually used them... I know nothing about rsh or rlogin code, but I would presume it should be possible to add a mechanism similar to ksu. From the ksu man page: The .k5users file format: A single principal entry on each line that may be followed by a list of commands that the prin- cipal is authorized to execute. A principal name followed by a '*' means that the user is authorized to execute any command. Thus, in the following example: jqpublic@USC.EDU ls mail /local/kerberos/klist jqpublic/secure@USC.EDU * jqpublic/admin@USC.EDU jqpublic@USC.EDU is only authorized to execute ls, mail and klist commands. jqpub- lic/secure@USC.EDU is authorized to execute any command. jqpublic/admin@USC.EDU is not autho- rized to execute any command. Note, that jqpub- lic/admin@USC.EDU is authorized to execute the target shell (regular ksu, without the -e option) but jqpublic@USC.EDU is not. The commands listed after the principal name must be either a full path names or just the program name. In the second case, CMD_PATH specifying the location of authorized programs must be defined at the compilation time of ksu. On Wed, Jun 30, 1999 at 03:44:48PM +0000, Matt Zimmerman wrote: > This was my reply to a previously private message (which was later > forwarded to the list), so I guess it's appropriate to copy it here > for thread continuity... Now I am getting my threads really confused... > I use command limited trust of RSA keys quite frequently for automated > jobs, for example, synchronization of directory hierarchies. I can do > this in ~/.ssh/authorized_keys: > > command="rsync --server --sender -vrz /remotedir /localdir",no-agent-forwarding,no-X11-forwarding,no-pty,idle-timeout=1d <public key> > > And allow a user to log in only to rsync a directory. Obviously, this > doesn't work very well with all programs (CVS, for example, can be run in > server mode this way, but it's apparently not difficult to leverage > shell access from CVS). So far I have seen that mirroring is a common application of this feature. Are there any others? > Thanks...I've seen more broken links that were supposed to lead to > Kerberos FAQs... There seems to be a lot of broken links these days - try looking up the kerberos module for Apache, and you will see what I mean - it *does* exist, and it looks reasonably well maintained, but there are a lot of broken links, too. > As you have noted, ssh supports the use of Kerberos tickets (among other > better-than-traditional-passwords methods) for authentication. Then, > on top of the Kerberos single-sign-on model, you get some extra bonuses, > like strong session encryption (I remember the kerberized telnet client > using DES for this...but it was a while ago), port forwarding (a lifesaver > for getting X sessions through a firewall/NAT), and on-the-fly compression. I hope that support is eventually implemented for ssh 2, although I am not at all too confident. Just browsing through the draft RFC for ssh1, I can see support for kerberos tickets. I have yet to see kerberos written anywhere in the ssh 2 RFC (I may have missed it though). However, I have seen a message, on comp.protocols.kerberos I think, that says stub code for kerberos has been written in ssh2, but currently is hardcoded to return failure. -- Brian May <bam@snoopy.apana.org.au>
Attachment:
pgpFQL0lexSFL.pgp
Description: PGP signature