9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
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



  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).