[
https://issues.apache.org/jira/browse/SSHD-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew C updated SSHD-211:
--------------------------
Attachment: sshd-service-wip.patch
Update, seems to pass the test suite.
Briefly, the root object is org.apache.sshd.common.service.Service, the server
side then has ServiceProvider, and the client ServiceClient. For instance
UserAuthServiceProvider and UserAuthServiceClient.
One thing to focus on is how the client side works.
A critical issue is that code using sshd is allowed to manipulate client
services via the session before the service has been started. For instance,
ClientSession.authAgent(String) or ClientSession.createChannel(String) assume
that the ssh-userauth or ssh-connection service can be manipulated before it is
started (current).
To address this problem, the client code's been modified so that it has:
- a "current service" - which is where all service messages are sent - see
org.apache.sshd.common.service.Service
- "pending services" - which is a list of services that will eventually come
into play - see org.apache.sshd.common.service.ServiceClientsFactory and
ServiceClient
The client will then:
- when the session is first created, populate the "pending services" list
(default is ssh-userauth, ssh-connection) with the services it expects to use;
and sets "current service" to null
- once the server "accepts" the first pending service (here ssh-userauth), the
client sets "current service" to that so that messages are routed to
ssh-userauth
- once the server approves an authentication, the client updates the current
service to the next pending service - here ssh-connection and further service
messages are routed to that
So that code can manipulate a pending service, methods like
CLientSessionImpl.authAgent have been modified to check both the current and
pending services for the ssh-userauth service object.
Longer term I can think of two alternative solutions:
- remove the session methods that hard-wire specific services from
ClientSession (and ServerSession) and instead require code to directly call the
relevant service object (my preference)
- add fields such as:
UserAuthServiceClient userAuthServiceClient
to ClientSessionImpl which are assigned when the session is created if there is
a corresponding service object
(for a horrible example see ClientSessionImpl.waitFor) where it has to poke
around in side the ssh-userauth orbject to implement WAIT_AUTH).
> Allow custom server services
> ----------------------------
>
> Key: SSHD-211
> URL: https://issues.apache.org/jira/browse/SSHD-211
> Project: MINA SSHD
> Issue Type: Bug
> Affects Versions: 0.8.0
> Reporter: Andrew C
> Attachments: sshd-service-wip.patch, sshd-service-wip.patch
>
>
> I'm implementing a custom server/protocol over sshd but to do it I'm
> extending / modifying the existing ServerSession when instead I should be
> adding a custom service to the existing ServerSession.
> Attached a work-in-progress that is sufficient to illustrate the basic theory
> (but not much more):
> - add a Service interface
> - add a ServiceFactory to SshServer that instantiates a Service given its
> name (e.g., "ssh-userauth" or "ssh-connection")
> - implement UserAuthService (ssh-userauth) and ConnectionService
> (ssh-connection) using code extracted from *Session
> - add a currentService to ServerSession and set it when it receives
> aSSH_MSG_SERVICE_REQUEST and then pass messages along to that (the
> UserAuthService, once completed, does the same thing with its requested
> service)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
