OpenSSH library

[Rogan Dawes]

So, from what Ben is saying, the recommended method of doing this is to
develop your app as a "patch" to OpenSSH?

I.e. do "deep linking" directly to the various .o or .a files?

Is there a documented interface that one could consider to be fairly static,
that can be used? Or would any such use be done at the coder's risk?

It would be great to get an example of how this could be done, with a
recommended sequence of calls that would invoke all the right security
functions to achieve a secure authenticated transport, without leaving
anything out. I guess that could be inferred from the source of openssh
itself, but I would worry about leaving something out :-(

Rogan

----- Original Message -----
From: "Ben Lindstrom" <mouring at etoh.eviladmin.org>
To: "Ray Caruso" <Ray.Caruso at netvion.com>
Cc: "Rogan Dawes" <rdawes at mweb.co.za>; <openssh-unix-dev at mindrot.org>
Sent: Sunday, May 19, 2002 6:14 AM
Subject: Re: OpenSSH library


>
> This has come up a few times, but the issue as Markus has stated it the
> current libssh.a is really just a collection of object files to improve
> compile preformance.
>
> The other issue you will face is if you want to do hostbased
> authentication (like the .shost, etc style) the binary in question that
> is linked to libssh.a will have to be setuid root.
>
> I think it may more useful to take the sftp*.[ch] framework and build it
> into a library/wrapper.  That way you can leverage OpenSSH or SSH Corp or
> "John Joe's Local SSH install" without having to create yet another
> setuid binary.
>
> Personally I like this approach for a few reasons.  The main reason is I
> believe it could be provided with a simple interface like below.
>
> ssh_password_callback(callback_passwd);
> fd = ssh_connect("site");
> {int,int64,char*)get_buffer{_int,_int64,}(fd);
> ssh_close(fd);
>
> Granted, I'm not looking at the code so it may need a bit more TLC.  But
> if memory serves right that is pretty much all sftp does at it's core.
>
> The other advantage this could bring is the ability to pass -o commands to
> the ssh client which would not be part of the libssh.a since it would be
> too low level for such concepts.  Thus making code reuse much higher.
> Only issue is SSH Corp and OpenSSH's -o commands are different, but one
> could handle it cleanly if they spent some time and pondered it.
>
> Consider that, and have fun.=)
>
> - Ben
>
>
>
> On Sat, 18 May 2002, Ray Caruso wrote:
>
> > I think this is a great idea. There are many applications for this lib.
I
> > actually started to investigate this a while back.
> >
> >
> >
> > At 06:16 AM Saturday 5/18/2002, Rogan Dawes wrote:
> > >Hi folks,
> > >
> > >I was thinking about the possibility of separating the OpenSSH
transport and
> > >authentication functions from the terminal emulation functions, and
making
> > >it available as a library for other applications to use for secure
> > >authenticated transport.
> > >
> > >My thinking is along the lines of:
> > >
> > >A whole bunch of applications have implemented "secure" versions of the
> > >transport protocol, using SSL (e.g. POP3S, IMAPS, NNTPS, IRC - I
think),
> > >however, they did not address the authentication problems at the same
time
> > >in a more flexible manner than client certificates.
> > >
> > >E.g. POP3 over SSL, but you still use a possibly weak password to
> > >authenticate.
> > >
> > >I can certainly imagine a whole class of developers who would love to
be
> > >able to replace a standard connect() call, followed by an
authentication
> > >process, with a simple ssh_connect() call. That way, they would not
have to
> > >worry about handling the various possible authentication combinations,
as
> > >well as being able to handle new authentication methods as SSH matures
and
> > >evolves, with little effort on their part in reimplementing them, other
than
> > >adding a configuration option in the application config files.
> > >
> > >Ultimately, they would be able to know that, as a server process, any
data
> > >that comes out of the fd is securely authenticated as coming from the
user
> > >returned by a ssh_get_user() call.
> > >
> > >The OpenSSH daemon could be implemented something like:
> > >
> > >Daemon starts up, reads the config file, initialises the ssh_transport
> > >library with parameters such as acceptable auth methods, location of
keyauth
> > >files, port-forwarding allowed, etc, and then the library starts
listening
> > >for connections.
> > >
> > >When a connection is received, the library handles all the negotiation
of
> > >algorithms and authentication methods, and once an acceptable
authentication
> > >occurs, the file descriptor (fd) is returned to the daemon. A library
> > >function would return the UID of the user associated with the fd, and
the
> > >daemon would then continue with the shell specific functions, such as
> > >opening pty's, setuid(user), executing .ssh/rc, and spawning a shell.
> > >
> > >One immediate use I could see for this is in writing a graphical
SCP/SFTP
> > >client, since the GUI developer would not need to worry about
> > >re-implementing the security part, and could instead concentrate on the
> > >functionality and usability of the GUI client.
> > >
> > >Similarly, this could be used by someone writing an SFTPD, listening on
a
> > >non-port-22, where SFTPD includes all the functionality of, say,
wu-ftpd, or
> > >the openbsd ftpd, such as chroot, limits, etc, and does not need to
create
> > >chroot jails with shells, etc in them for users that just want to
transfer
> > >files.
> > >
> > >SFTPD users would have their own keyauth files, say in
> > >.ssh/sftpd_authorized_keys, which would not be read by a normal SSH
daemon,
> > >and thus would not imply allowing FTP only users access to a shell.
> > >
> > >I can imagine that I will get a bunch of answers saying that people who
are
> > >not interested in security should not be implementing things like FTP
> > >daemons, etc, but I think that it is more intelligent to rely on a
group
> > >that IS interested in security to do it properly, and reuse those
efforts
> > >where possible.
> > >
> > >I can also imagine answers like "We don't like libraries in security
> > >critical code, the fewer interfaces, the fewer mistakes". Maybe that's
> > >valid, I don't know, and will bow to experience.  I would just like to
see
> > >more use of secure protocols, and think that this might be one way of
> > >achieving it.
> > >
> > >Comments?
> > >
> > >Rogan
> > >
> > >
> > >_______________________________________________
> > >openssh-unix-dev at mindrot.org mailing list
> > >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> >
> > _______________________________________________
> > openssh-unix-dev at mindrot.org mailing list
> > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> >
>