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
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
The OpenSSH code is far from usable as a library. Throughout the OpenSSH code you'll find the use of globals and static globals and calls to fatal() (which is a fancy wrapper around exit()) and so on, to say nothing of the fact that OpenSSH has its own event loop and, if you want to use OpenSSH as a library, you have to either fit the app into that loop or abstract the loop so the library could fit into the app's event loop - or use multiple threads (but OpenSSH code is not thread-safe currently). So no, you can't make a useful library out of OpenSSH as it stands. A lot of the major issues that prevent OpenSSH from being made into a library could be fixed with some work. Stuff the globals into a context structure, make sure it gets passed around... give the app a way to register its own exit() and select() functions for use by the library (the app-provided exit() might just longjmp()), provide an I/O abstraction so the app can read/write from/to SSH channels, etc... Actually, that's a bit more than "some work"... But I kinda doubt that libopenssh is a goal or a high-priority goal for the OpenSSH folk. In the meantime you can use ssh w/ pipes and/or port forwarding to achieve mostly the same effect, though with more context switching and data copying. Cheers, Nico -- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.