From: lucio@proxima.alt.za
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Authenticated SMTPD or factotum's p9cr
Date: Tue, 21 Aug 2007 07:38:31 +0200 [thread overview]
Message-ID: <a7a62f91c8404185874e1e21c1d659eb@proxima.alt.za> (raw)
In-Reply-To: <57ac42c5f0899c4d58c066ca7e7f12c4@plan9.bell-labs.com>
> I can't answer all your questions immediately, but as long as smtpd
> can read the certificate it needs for TLS (typically
> /sys/lib/ssl/smtpd-cert.pem), tcp25 can reside in /rc/bin/service.
Hm, /rc/bin/service/tcp25 runs as "none" and where as it can read the certificate *that's easy), but I could have sworn it could not access the "eve" factotum (I use "proxima" as a replacement for "bootes", I have a feeling there are namespace issues that Bell Labs ought to take into consideration - but that's just a shot in the dark). I fixed it initially by running factotum within tcp25 and adding the essential keys to it, which improved things, but left me with the "protocol botch". My problem is that I cannot identify the casue of the botch (factotum's diagnostics - here's me looking a gift horse in the mouth - are no adequate) and that is where everything sticks. I don't want to mess with the factotum code unless it becomes essential, but I guess it's one route to identify the problem.
> There needs to be a corresponding key in your cpu server(s)'s bootes's
> factotum. We load ours automatically from bootes's secstore factotum
> file. It and our ssh server key look like this:
>
> key proto=rsa service=tls owner=* size=1024 ek=10001 n=[many hex digits] !dk? !p? !q? !kp? !kq? !c2?
> key proto=rsa service=sshserve owner=* size=1024 ek=91 n=[many hex digits] !dk? !p? !q? !kp? !kq? !c2?
>
The alternative here is:
key proto=rsa service=tls owner=* role=client size=1024 ek=1 n=[...] !dk? !p? !q? !kp? !kq? !c2?
key proto=rsa service=sshserve size=1024 ek=17 n=[...] !dk? !p? !q? !kp? !kq? !c2?
key proto=rsa service=tls role=client size=1024 ek=10001 n=[...] !dk? !p? !q? !kp? !kq? !c2?
Is it possible that the "owner=*" instance is messing up things? It
is a different entry. I note, incidentally:
term% ssh -l proxima huddle
server huddle not on keyring.
add key to keyfile (a), continue without adding key (c), or exit (e) [e]c
ssh: client authentication failed
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
and especially
term% telnet huddle
connected to tcp!huddle!telnet on /net/tcp/1
user: proxima
authentication failure:auth server protocol botch
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
whereas
term% cpu -h huddle -u proxima
huddle# cat
> Our tcp25 for the outside world ends with this invocation of smtpd:
>
> exec upas/smtpd -n $3 -gD -m /mail/lib/vfsend.alt -c /sys/lib/ssl/smtpd-cert.pem
I have:
exec upas/smtpd -d -a -c /sys/lib/tls/virtual.pem -n $3 >[2] /sys/log/smtpd
or, by shuffling the options:
exec upas/smtpd -n $3 -d -a -c /sys/lib/tls/virtual.pem >[2] /sys/log/smtpd
now I have to understand all the differences, I do presume that "-c"
implies "-a" or that lack of "-a" makes authentication optional. I
was going to put -gD in later and of course "-d" is temporary (and not
terribly useful, for some reason I need to understand better).
Oh, "-m" is undocumented. I see it selects a mailer with default
"send" and, yes, "-a" makes authentication mandatory, which is as I
want it.
Thank you for all your help.
++L
next prev parent reply other threads:[~2007-08-21 5:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-20 19:15 lucio
2007-08-20 20:53 ` geoff
2007-08-21 5:38 ` lucio [this message]
2007-08-21 18:10 ` erik quanstrom
2007-08-21 18:39 ` geoff
2007-08-21 18:48 ` lucio
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a7a62f91c8404185874e1e21c1d659eb@proxima.alt.za \
--to=lucio@proxima.alt.za \
--cc=9fans@cse.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).