OpenSSH library

[Rogan Dawes]

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