(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