OpenSSH library

[Ray Caruso]

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