On 1/11/19 12:14 PM, Jordan Brown wrote:
On 1/10/2019 10:55 AM, Corey Minyard wrote:
It is unusual, perhaps, but I'm trying to implement something like
ssh does. I can't expect users of ser2net to obtain certificates
from a real certificate authority, that's too high a barrier for
entry. I want them to be able to generate a key pair, put the public
key on the server in their account, and authenticate against that.
Nobody said you needed a real certificate authority. You need a
*trusted* certificate authority.
You could put the user's self-signed certificate into their account as
a trusted CA.
Well, that's what I meant :) And the self-signed certificates is what
I've planned. If I used the default CA, then the user would have to get
a certificate from someplace else, they couldn't generate it themselves.
However... it seems like you're reinventing ssh. Your replacement for
ssh will likely require a custom client, which will be a pain in the
neck for your users. Maybe you should start with an existing ssh
library and hack it until it behaves the way you need.
Indeed, ssh is where I started, and I would love to use it. A custom
client will be a pain, for sure, and I'd like to avoid it if possible.
But openssh only allows one connection per process, which is definitely
not going to work with what I need.
libssh should be able to support multiple connections per process, but I
spent about a week hacking on it, and the code is all wrapped around
itself, not layered, and the changes to fix it would be huge. And I'm
not going to support a fork of something that complex, and the
maintainer didn't seem too keen on those types of changes.
I didn't find any other server libraries that were suitable. I'm not
going to write my own ssh library.
Plus no ssh client will do serial port control over the network
connection (like RFC2217), and many ser2net users use that. So I might
have been stuck with a custom client, anyway.
I don't really like my options, but I'm kind of boxed in. I'm not sure
why ssh doesn't run on top of ssl; that seems so sensible. I assume
that's for historical reasons.
Thanks,
-corey
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
