The Maverick Legacy Server 1.6 introduces a few more simple interfaces to make extending the server easier and more intuitive. This article discusses the necessary tasks required to migrate your server from 1.4 to the new designs made available in Maverick Legacy Server 1.6.7+.
Authentication
The NativeAuthenticationProvider was the main point for extending authentication in 1.4. This has been removed and replaced with a more modular method of authenticating users. You now have the option of implementing any number of Authenticator instances. These are added to a factory object and you can add multiple Authenticators of each type so you can easily mix users from different endpoint databases.
sshContext.setAuthenicationMechanismFactory(new DefaultAuthenticationMechanismFactory());
We provide the following abstract classes / interfaces that can be extended.
PasswordAuthenticationProvider - extend this abstract class to verify users passwords if you want to support password or password over keyboard-interactive authentication. Simply implement the verifyPassword and changePassword methods.
sshContext.getAuthenticationMechanismFactory().addProvider(new AllowAnythingPasswordAuthenticator());
KeyboardInteractiveProvider - for those wanting a custom challenge-response authentication flow this interface remains from the 1.4 release, with a slight small change in the init method. Rather than the username being passed in, its now a Connection instance which you can use to store state and get the username from. Rather than configuring this directly on the SshContext you add this to the AuthenticationMechanismFactory.
sshContext.getAuthenticationMechanismFactory().addProvider(
new KeyboardInteractiveAuthenticationProvider() {
public KeyboardInteractiveProvider createInstance(Connection con) {
return new PasswordKeyboardInteractiveProvider(
new PasswordAuthenticationProvider[] {
new AllowAnythingPasswordAuthenticator() }, con);
}
});
PublicKeyAuthenticationProvider - replaces the PublicKeyStore interface. This has additional methods for iterating over a users keys, adding and removing keys too. These were added to support the PublicKeySubsystem which will be available in a later release. For those replacing PublicKeyStore it should be straight forward, you make throw a RuntimeException from the additional methods if you do not want to support or intend to use the PublicKeySubsystem.
Again add the PublicKeyAuthenticationProvider to the AuthenticationMechanismFactory.
sshContext.getAuthenticationMechanismFactory().addProvider(
new AuthorizedKeysPublicKeyAuthenticationProvider());
File Systems
1.4 provided the NativeFileSystemProvider interface to extend the SFTP subsystem with your own file system. This interface has been removed and whilst a similar FileSystem interface has been created, we do not recommend porting and will not support ports from NativeFileSystemProvider to FileSystem
Implementing a FileSystem requires that you follow certain guidelines to ensure the system behaves in the way an SFTP client would expect. We have provided a simpler alternative that shields the developer from these responsibilities in the AbstractFile interface. This new design requires the implementation of AbstractFile and an AbstractFileFactory. Being similar to java.io.File this allows the developer to concentrate on the specifics of the file I/O whilst we provide an implementation of FileSystem that adheres correctly to the SFTP protocol.
For those customers that previously used our VirtualFileSystem implementation, a new more flexible implementation that uses AbstractFile has been created to replace VirtualFileSystem. For more information on VirtualFileFactory see our article here.
Access Manager
The AccessManager interface remains for now in a slightly modified form. In many methods the session id was previously passed as a byte[] and it is now passed as a String. You can use the session id to get the Connection for the current client by using the following code:
Connection con = ConnectionManager.getInstance().getConnectionById(sessionid);
In addition to these changes, the canConnect(SocketAddress remoteAddress) has been modified to include a second parameter for the local SocketAddress of the incoming connection.
public boolean canConnect(SocketAddress remoteAddress, SocketAddress localAddress);
Sessions and Commands
There are no changes in 1.6.x with the architecture of SessionChannel and ExecutableCommand. Your existing sessions and command implementations should run with minimal modification. However we have introduced a new ChannelFactory mechanism to facilitate better creation of the session which will allow you to support different types of sessions within a single context.
The recommended way to configure creation of SessionChannel is now to add a DefaultChannelFactory implementation and override the createSessionChannel method. This replaces the now depreacted setSessionProvider method which will continue to work but will be removed in a future release.
sshContext.setChannelFactory(new DefaultChannelFactory() {
protected Channel createSessionChannel(Connection con) {
return new UnsupportedSession();
}
});
Further Support
Please contact us if you have any questions about your migration from 1.4 to 1.6. We will endeavour to keep this documentation updated with the latest updates from our customer base as they migrate from 1.4 to 1.6.
