3 ms·

SSF one year later: cross platform shell, proxy support and new features

2 points by ssfdeveloper 10y ago

ssfdeveloper 10y ago
We unveiled the SSF project about one year ago and we wanted to make a retrospective on its evolution since then. SSF is a network tool and toolkit. Its first version was released in June 2015 and we released 2.2.0 a week ago. Here are some highlights of the project activity: # Cross platform Shell A feature we wanted to provide in a new version was a cross platform shell. At the moment, the shell feature makes it possible to interact with cmd.exe on Windows and bash on Linux/OS X (default settings). Actually, the shell is completely customizable, so it is possible to set Powershell or whichever shell is available on the machine. Shell feature is not enabled in the default configuration, you must enable it explicitly in the configuration file. At the moment, this feature is quite different from SSH: this is only the first draft! It will be improved over time. # Proxy Some users requested support for connection through HTTP proxy (CONNECT), so we implemented it. SSF also supports proxy authentications such as Basic, Digest, NTLM (Windows only) and Negotiate. Windows NTLM and Negotiate authentications are based on SSPI and Linux/OS X Negotiate authentication is based on the GSS API. # Transport protocol enhancement After taking a step back, the process of establishing a connection was clearly not modular enough. Indeed, some users wanted to establish a connection through a proxy, we wanted to add an extra encryption layer on top of the relay layer... As a result, rewriting this component took us a lot of time. SSF business logic (multiplexing, microservices, features) is transport agnostic. It relies only on the Boost.Asio API (acceptor and stream socket interfaces). This means that the transport logic can be easily replaced by anything which complies with those APIs, at minimal cost. We have a side project that is a Boost.Asio UDT implementation (stream over UDP, development is currently in its very early stage). In a near future, we could imagine to have SSF use TLS over UDT. # Target platform: Windows >= Vista, Debian >=6 We improved the build process to support more platforms. Now, prebuilt binaries can be run without any dependencies on: * Debian >= 6 (32/64 bits): limitation resides in the GLIBC version (2.9 required at the moment) * Windows >= Vista (32/64 bits): Workaround for Windows XP is to select the XP toolset before building the project. XP support is planned for a next release. # What's next? This project is still young. We appreciate feedback and new ideas. Shell will be the first feature that we will improve. Supporting connection through SOCKS proxy is also planned. We put aside the UDT library to focus on SSF but we think this lib really has some potential so we may resume its development. Feel free to join the adventure :-)

2 points by ssfdeveloper 10y ago

We unveiled the SSF project about one year ago and we wanted to make a retrospective on its evolution since then. SSF is a network tool and toolkit. Its first version was released in June 2015 and we released 2.2.0 a week ago. Here are some highlights of the project activity: # Cross platform Shell A feature we wanted to provide in a new version was a cross platform shell. At the moment, the shell feature makes it possible to interact with cmd.exe on Windows and bash on Linux/OS X (default settings). Actually, the shell is completely customizable, so it is possible to set Powershell or whichever shell is available on the machine. Shell feature is not enabled in the default configuration, you must enable it explicitly in the configuration file. At the moment, this feature is quite different from SSH: this is only the first draft! It will be improved over time. # Proxy Some users requested support for connection through HTTP proxy (CONNECT), so we implemented it. SSF also supports proxy authentications such as Basic, Digest, NTLM (Windows only) and Negotiate. Windows NTLM and Negotiate authentications are based on SSPI and Linux/OS X Negotiate authentication is based on the GSS API. # Transport protocol enhancement After taking a step back, the process of establishing a connection was clearly not modular enough. Indeed, some users wanted to establish a connection through a proxy, we wanted to add an extra encryption layer on top of the relay layer... As a result, rewriting this component took us a lot of time. SSF business logic (multiplexing, microservices, features) is transport agnostic. It relies only on the Boost.Asio API (acceptor and stream socket interfaces). This means that the transport logic can be easily replaced by anything which complies with those APIs, at minimal cost. We have a side project that is a Boost.Asio UDT implementation (stream over UDP, development is currently in its very early stage). In a near future, we could imagine to have SSF use TLS over UDT. # Target platform: Windows >= Vista, Debian >=6 We improved the build process to support more platforms. Now, prebuilt binaries can be run without any dependencies on: * Debian >= 6 (32/64 bits): limitation resides in the GLIBC version (2.9 required at the moment) * Windows >= Vista (32/64 bits): Workaround for Windows XP is to select the XP toolset before building the project. XP support is planned for a next release. # What's next? This project is still young. We appreciate feedback and new ideas. Shell will be the first feature that we will improve. Supporting connection through SOCKS proxy is also planned. We put aside the UDT library to focus on SSF but we think this lib really has some potential so we may resume its development. Feel free to join the adventure :-)