OpenSSH library

[Ben Lindstrom]

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
>