[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SSH Server side development
[Thread Prev] | [Thread Next]
- Subject: SSH Server side development
- From: "Preston A. Elder" <prez@xxxxxxxxxxxxxx>
- Reply-to: libssh@xxxxxxxxxx
- Date: Sat, 25 Jul 2009 00:36:13 -0400
- To: libssh@xxxxxxxxxx
Hey, I'm still looking at embedding an SSH server into my application. It looks like libssh has had a fair bit of work done since 0.2, which is good. One important change I notice is that it is now possible to do asynchronous operations on server side. This is a huge plus. I have made some modifications to libssh, and I've included a patch you can use to help with server-side stuff. It changes the following: - Fixes a spelling error in originator_port. - Enables channel_request_open types of DIRECT_TCPIP, FORWARDED_TCPIP and X11 (ie. implemented the handling of those channel_request_open types). - Adds functions to retrieve the extra information relating to channel_request_open messages and channel_request messages. - Adds a channel_write_stderr method (obviously for writing to the STDERR channel from server side) - well, technically just converted the exiting channel_write to take an extra argument and created two wrapper functions. - Actually does the invoking of message_handle() from channel_recv_request. - Implemented the handling of the window-change and env channel_requests. - Implemented a few functions in server.h that were declared but not defined (eg. ssh_message_channel_request_channel). I have also attached a sample app (c++) I've been using that implements an sshd server (well, not fully, the 'shell' just echos back what you type, but it's relatively easy to replace that part with a real shell). And I have set it up so that it could easily support forwarded ports too. There are still several things that worry me on the server side of things. Mainly to do with implementing non-blocking servers. For example the channel_write function is ONLY ever a blocking call, this is just not good enough. Similarly several other calls make blocking calls under the hood (things like ssh_accept()) also do blocking calls, which apart from the fact it means I could be waiting on I/O (which severly hampers my ability to have a server handle multiple sessions in a single thread) - it opens the server up to malicious attack from someone who deliberately makes their client go cso far then hang, causing my server to hang. Ideally it would be best if the actual communications layer were completely separated from the rest of the code, such that it could be replaced. I know I would love to replace the socket layer in libssh with ASIO for my own purposes, and I'm sure others have socket layers of their own which do things a certain way that is beneficial for their environment. I will say SSH_POLL does help in that regard, but it's still a little klugy. Finally, to get my server to work properly, apart from modifying the server.h (and message.c) to actually allow me to retrieve the extra data for channel_requests and channel_request_opens, I also had to use a few things from priv.h. Not in the least was the ssh_poll interface, but also things like ssh_handle_packets and ssh_execute_message_callbacks. I'm not sure if I'm quite willing to put in the effort to separate out the comms from the rest of the library (protocol and crypto parts), but I really do believe it should be done - and have the existing comms library be able to be one implementation, but allow others. The major changes I guess would be things like: - The ssh_bind interface would change dramatically (or at least, become part of the 'socket' version of the implementation), and the functionality that does not pretain to socket operations would go into ssh_session. - The ssh_session_new would take as an argument a callback to use for sending data (raw bytes) - There would be an extra function call to receive data (ssh_recv or something) that takes a session and data received as arguments, and that data would basically just be stored in the session until some call is invoked to try and decrypt said data and turn make use of it (which it might not be able to do due to half messages, but that's fine). I'm not saying it is an easy task, but it IS doable. But maybe I'm the only one who thinks so ;) PreZ :)
Attachment:
server_changes.diff.gz
Description: application/gzip
Attachment:
mysshd.cpp.gz
Description: application/gzip
Re: SSH Server side development | Andreas Schneider <mail@xxxxxxxxxxxx> |