Author | SHA1 | Message | Date |
---|---|---|---|
Thomas Wolf | 2cb842ef02 |
SshdSessionFactory: generalize providing default keys
Provide a mechanism for a subclass to provide its own set of default identities from anywhere as an Iterable<KeyPair>. The default implementation is functionally unchanged and uses the known default identity files in the ~/.ssh directory. A subclass can override the getDefaultKeys() function and return whatever keys are appropriate. Bug: 543152 Change-Id: I500d63146bc67e20e051f617790eb87c7cb500b6 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch> |
5 years ago |
Thomas Wolf | 7aaeb6489f |
Apache MINA sshd client: don't leak upstream classes and interfaces
We will get an API evolution problem if we expose as API classes and interfaces that derive from upstream classes or interfaces. Upstream interfaces also evolve quite erratically and evolution doesn't seem to follow semantic versioning. Introduce a new KeyPasswordProvider interface so that we don't have to depend on the upstream FilePasswordProvider in our API. (We do need _some_ abstraction for getting passwords for encrypted keys in the API; EGit will need to provide its own implementation.) Move some other upstream dependencies (HostConfigEntry, and various previously protected methods in SshdSessionFactory) out of the API: classes moved to internal space, and methods made private. The only dependencies on upstream interfaces are thus in a few method parameter types. Those cannot be avoided, but should also not pose problems. Bug: 520927 Change-Id: Idc9c6b0f237f29f46343c0fe15179242f2007bec Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch> |
5 years ago |
Thomas Wolf | c56fa51709 |
Apache MINA sshd: use NumberOfPasswordPrompts for encrypted keys
sshd only asks exactly once for the password. C.f. upstream issue SSHD-850.[1] So we have to work around this limitation for now. Once we move to sshd > 2.1.0, this can be simplified somewhat. [1] https://issues.apache.org/jira/browse/SSHD-850 Bug: 520927 Change-Id: Id65650228486c5ed30affa9c62eac982e01ae207 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch> |
5 years ago |