Atsuhiko Yamanaka schrieb:
> Hi,
>
> +-From: Paul Ebermann <paul-eberm...@gmx.de> --
> |_Date: Mon, 09 May 2011 21:30:39 +0200 __
> |
> |on writing documentation in the wiki and reading RFC 4252 [1],
> |I noticed that there is no implementation of host based authentication
> | (section 9).
>
> There is no plan to support that authentication method.
> It is really easy to support it, but, as you know, it requires the accesses
> to the host key, which is usually inaccessible without root privilege.
> On this list, there had been requests for that method, but it has not been
> implemented due to security concerns.
Yes, I understand that one normally don't want this. I think I described a
usecase where
this might be useful (not with the real host key), though.
If this isn't added to JSch, could we at least do something to enable external
extensions
to do this (or other custom authentication methods)?
As I wrote:
>> - I tried to do this as an independent extension, but it turns out we need
>> to be in
>> the com.jcraft.jsch package to access some package-local methods/variables
>> in
>> Session (.jsch, .getSessionID), JSch (.getLogger(), .identities) and
>> Buffer (.buffer),
>> as well as the JSchPartialAuthException.
Could these methods/fields/class be made accessible somehow for authentication
methods
outside the core package?
- JSchPartialAuthException will be needed for *any* authentication method. I
see no
problem in making this public (and noting "only to be thrown from
UserAuth.start()").
- I think the sessionID and .jsch could be put as protected variables/methods
into
UserAuth, and initialized in .start().
- For the identities, I think there could be a method like this in JSch:
public Identity getIdentity(String name)
Alternatively, we would need some way to pass information to the authentication
objects
from the application, like `setAuthProperty(String key, Object value)`, which
the auth
property then either could retrieve or receives per method call.
- I think the `JSch.getLogger()` method could be public without any problem.
- The access to Buffer.buffer is not really needed, we could alternatively just
use
`getByte` (and maybe some clever index/offset manipulation). It saves us an
additional
copy here, though.
Paul
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
JSch-users mailing list
JSch-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jsch-users
