using Rebex.Net;

SFTP test server options for .NET developers

Martin Vobr — Tue, 11 Aug 2026 12:00:00 GMT

Where do I point my SFTP client while testing?

You've added Rebex SFTP to your project, written the first Sftp.Connect() / Login / Upload() / Download() sequence, and now you need something on the other end of the wire. Preferably something you can break, restart, and fill with junk files without anybody noticing.

This post walks through some options, from "you already have one" to "spin up a fresh server per test run", with the trade-offs of each.

Option 1: The SFTP server you already have

If your organization already runs an SFTP server - OpenSSH on a Linux box, a vendor appliance, whatever - the fastest path is to get a test account on it and move on. Nothing to install, nothing to explain to anyone.

It works, but be aware of what you're signing up for:

Shared state. Someone else's test run deletes the directory yours depends on. Test ordering suddenly matters.
You don't control the config. Want to check how your code behaves with a different key exchange algorithm, an expired host key, or a server that rejects SSH_FXP_RENAME? You'll be filing a ticket with whoever owns the box.
It's not there when you are. Working on the train, on a plane, or from a coffee shop with a captive-portal Wi-Fi means no tests.
Reset is manual. No easy way to say "put the filesystem back the way it was" between test runs.
CI is awkward. Your build agents now need network access and credentials to a real server.

Fine for a smoke test. Might be painful as the backbone of an automated test suite.

Option 2: test.rebex.net - zero setup, read-only

We run a public test server at test.rebex.net. Credentials, ports and the list of supported protocols are on that page - SFTP is on port 22, and the login is the usual demo / password combination.

var client = new Sftp();
client.Connect("test.rebex.net", 22);
client.Login("demo", "password");

foreach (var item in client.GetList("/"))
    Console.WriteLine(item.Name);

client.Disconnect();

That's a working SFTP session in under a minute, which is exactly what it's for: confirming your connection code, your credentials handling, and your fingerprint verification logic actually do something before you go hunting for bugs elsewhere.

Limitations you need to know about:

It's read-only. You cannot upload, delete or rename anything. Half of what you probably want to test is off the table.
It's shared and rate-limited. Please don't point a CI pipeline at it. It's a courtesy service, not infrastructure.
It's remote. Same offline problem as option 1.

Use it to answer "does my code speak SFTP at all?" Then move to something local.

Option 3: Rebex Tiny SFTP Server - unzip, click Start

Rebex Tiny SFTP Server is a minimalist single-user SFTP server for Windows. It started life as a sample application for the Rebex File Server library and turned out to be useful enough on its own that we ship it as a standalone download.

The workflow is about as simple as it gets: download the ZIP, unpack it, run RebexTinySftpServer.exe, press Start. You now have an SFTP server on localhost serving a directory of your choice, with full read/write access.

Configuration lives in RebexTinySftpServer.exe.config - plain XML, where you set the port, the user name and password, and the root directory.

Licensing: running the pre-built binary is free, for commercial and non-commercial use alike. No strings.

Where it falls short:

It's a GUI application. You start and stop it by hand. There's no service mode and no command-line control, so wiring it into an automated pipeline means either leaving it running permanently or scripting a window.
Single user. Testing permission boundaries between accounts isn't possible.
Changing the configuration means editing XML and restarting the app.

Perfect for interactive development: leave it running in the background on your dev box and hammer it from the debugger.

Option 4: Rebex File Server .NET library - run the server in-process

Tiny SFTP Server is not magic. Under the hood it's a thin GUI wrapped around the Rebex File Server library - and if you already own the library, you can skip the wrapper entirely and start the server from inside your own test process.

Setup is a handful of lines: create a FileServer, give it a host key and a user, and start it.

// nuget Microsoft.NET.Test.Sdk
// nuget NUnit
// nuget NUnit3TestAdapter
// nuget Rebex.FileServer
// nuget Rebex.Sftp

using System.Net;
using NUnit.Framework;
using Rebex.Net;
using Rebex.Net.Servers;

[TestFixture]
public class SftpTests
{
    private static readonly Lazy<SshPrivateKey> ServerKeyLazy = new(SshPrivateKey.Generate);
    private const string Username = "user01";
    private const string Password = "password";

    [Test]
    public async Task Test()
    {
        // prepare
        await using FileServer server = await CreateServer();

        // contains the actual port used by the server
        IPEndPoint serverEndpoint = (IPEndPoint)server.Bindings.First().EndPoint;
        TestContext.WriteLine("Server endpoint: {0}", serverEndpoint);

        using Sftp client = new();

        await client.ConnectAsync(serverEndpoint.Address.ToString(), serverEndpoint.Port);
        await client.LoginAsync(Username, Password);

        // test
        Assert.That(client.IsAuthenticated, Is.True);

        await client.DisconnectAsync();
    }

    // CreateServer can be parameterized to customize the testing environment
    private static async Task<FileServer> CreateServer()
    {
        FileServer fs = new();

        try
        {
            // port 0 will instruct the server to use a random, unused port, so the test can be parallelized
            await fs.BindAsync(new IPEndPoint(IPAddress.Loopback, 0), FileServerProtocol.Sftp);
            fs.Keys.Add(ServerKeyLazy.Value);
            fs.Users.Add(Username, Password, Path.GetTempPath());

            await fs.StartAsync();
            return fs;
        }
        catch
        {
            await fs.DisposeAsync();
            throw;
        }
    }
}

Why this is attractive for testing:

No external process, no orchestration. No ZIP to unpack on the build agent, no process to launch and reap, no port conflict with something a previous run left behind. dotnet test is the whole story.
Each test can get its own server. Pick a free port, point a temp directory at it, tear it down afterwards. Tests can run in parallel without stepping on each other.
You can make the server misbehave on purpose. This is the real payoff. The library exposes a virtual file system you can implement yourself, plus events for uploads and downloads. That makes it possible to simulate the failures you'd otherwise never reproduce: a read that throws halfway through a large file, a directory with 50,000 entries, filenames with awkward Unicode, a server that drops the connection mid-transfer, permissions that change between two calls. Testing your retry and resume logic against a server that actually fails beats hoping it works.
Restrict the algorithms. Narrow down the supported key exchange and encryption algorithms to check how your client behaves against an old or hardened server.

Where to look for a working example: Tiny SFTP Server itself. The source is on GitHub at github.com/rebexnet/RebexTinySftpServer - a few hundred readable lines around the FileServer class, showing key loading, user setup and lifecycle handling. Fork it, strip out the WinForms parts, and you have the skeleton of a test fixture.

Licensing: Rebex File Server is a commercial component, sold separately or as part of the File Transfer Pack and Total Pack. A trial key is enough to find out whether the approach suits you.

The trade-off: this is the only option here that costs money if you're building commercially, and it's the one that requires you to write code rather than run an executable. In return you get complete control over the server's behaviour from within your test suite.

Option 5: Buru SFTP Server - the one you can script

When you want the same convenience as Tiny SFTP Server but with automation, use Buru SFTP Server. It's a full SFTP/FTP/SSH server for Windows, and it happens to be the same core that powers test.rebex.net - so behaviour you see locally matches what you saw online.

Two things make it a good fit for testing.

First, it runs portable. There's a portable mode - download the Portable ZIP, unpack, and run it as a normal console application from any folder, USB stick, or network drive. No installer, no admin rights, no leftover Windows service. (It can run as a service when you want it to; you're just not forced into it.)

Second, everything can be driven from the command line. Creating an instance, adding users, starting the server:

# initialize an instance in the current directory
burusftp init

# add a user
burusftp user add john --password mypassword --root-dir "C:\temp\sftp-test-root"

# run the server
burusftp run

Which means your test fixture can do this:

Copy a clean instance directory into a temp folder (or run burusftp init fresh).
Add exactly the users your test needs, with exactly the root directories and permissions it needs.
Start the server on a free port.
Run the tests.
Kill the process and delete the folder.

Every run starts from a known state. No shared server, no leftover files from yesterday, no "works on my machine".

The configuration is a text file in YAML format, so you can keep a set of purpose-built configs in your repository next to the tests that use them - one that only allows a weak set of algorithms, one with a tiny transfer limit, one with a specific host key. Diffable, reviewable, versioned.

It also serves FTP, FTP/S and SSH shell, which is handy if your application talks more than one protocol and you'd rather not run three different test servers.

Licensing: free for non-commercial use; see pricing for the details of what each tier includes.

This is the option we'd recommend for anything resembling a real test suite.

Option 6: Third-party servers, when you need the weird ones

Sooner or later you'll integrate with a server that does something surprising - an unusual path format, a non-standard permission string in directory listings, an SFTP v3 implementation with opinions, a SSH_FXP_STAT response that omits fields everyone else sends.

If you want to test against a specific implementation, sftp.net/servers maintains a list of SFTP server software with notes on each. Pick the one your customer uses, install it locally, and reproduce the problem.

That said - you probably don't need to do this as often as you think. We run regular regression tests of Rebex SFTP against a large set of third-party server implementations precisely so that this class of incompatibility gets caught on our side rather than yours. If you do hit a server that Rebex SFTP misbehaves against, that's a bug report we want: send us a communication log and we'll look at it.

Quick summary

	Setup	Write access	Automatable	Offline	Cost
Your own server	already done	yes	varies	no	–
test.rebex.net	none	no	no (please don't)	no	free
Tiny SFTP Server	unzip + click	yes	not really	yes	free, incl. commercial use
File Server (in-process)	write a fixture	yes	yes, fully	yes	commercial license
Buru SFTP Server	unzip + 3 commands	yes	yes, fully	yes	free for non-commercial use
Third-party servers	varies	yes	varies	varies	varies

A reasonable progression for most projects:

Start with test.rebex.net to prove your connection code works.
Move to Tiny SFTP Server for day-to-day development against a local, writable server.
Adopt Buru SFTP Server once you want tests that run unattended from a clean state.
Host Rebex File Server in-process when you need the server to fail in specific, repeatable ways - or simply want zero moving parts in CI.
Reach for specific third-party servers only when you're chasing a compatibility issue with a particular implementation.

Questions? Rebex support and the forum are both open.

How to use ML-DSA with Rebex SSH libraries

Lukas Pokorny — Fri, 31 Jul 2026 00:00:00 GMT

ML-DSA (Module-Lattice-Based Digital Signature Algorithm) is a post-quantum cryptographic signature algorithm standardized in NIST FIPS 204 that is currently being integrated into the SSH protocol. ML-DSA is designed to replace traditional digital signature algorithms like RSA and ECDSA for identity verification. And along with ML-KEM, it protects SSH communication against future decryption threats from cryptographically relevant quantum computers.

However, as of summer 2026, while SSH key exchange ciphers based on ML-KEM are already widely implemented and deployed, the exact details of ML-DSA support in SSH are still work in progress. Lately, there has been an increasingly heated debate about whether to use ML-DSA in stand-alone (pure) mode, or whether to go for composite (hybrid) mode instead. In hybrid mode, ML-DSA is used together with a well-known and battle-tested classic algorithm such RSA, ECDSA or Ed25519. This ensures that when a vulnerability is discovered in the post-quantum algorithm or its implementation, the SSH session at least remains protected by the classical algorithm. Others argue this would be overly-complicated, and would not provide any extra security in the longer term, when ML-DSA implementations mature or cryptographically relevant quantum computers actually arrive.

As for Rebex libraries, in order to make it possible to perform some real-world testing, we added experimental support for stand-alone SSH ML-DSA algorithm to version 8.0 of our SSH-enabled libraries. We choose to add support pure mode ML-DSA ciphers first because these have already been available during development of version 8, and they do seem likely to stay, even if hybrid variants initially become a preferred choice.

Of course, we plan to add hybrid variants as well, as soon as it becomes clear which of the composites actually gain traction. Expect more updates soon!

For now, if you decide to enable experimental ML-DSA support in Rebex SSH libraries and give it a try, make sure you are aware of the controversies surrounding pure mode ML-DSA and understand the implications.

Currently, two competing (but almost compatible) draft specifications of pure SSH ML-DSA exist:

sfluhrer-ssh-mldsa, defines ssh-mldsa-44, ssh-mldsa-65, and ssh-mldsa-87 public key and signature formats.
rpe-ssh-mldsa defines mldsa-44, mldsa-65, and mldsa-87 instead.
Confusingly, an earlier version of sfluhrer-ssh-mldsa defined cipher IDs as ssh-mldsaNN instead, while an earlier version of rpe-ssh-mldsa used ssh-mldsa-NN form (which is currently used by sfluhrer-ssh-mldsa).

Because it is still not clear whether and when any of these are going to become official, Rebex libraries currently support all these forms. You just have to explicitly enable the variant you intend to use. Our test server at test.rebex.net supports all of them, but in practice, we really recommend choosing just a single one.

For example, to try ssh-mldsa-44 host key algorithm with Rebex SFTP (which runs over SSH), get Rebex.Sftp NuGet package and use the following code:

var sftp = new Rebex.Net.Sftp();
sftp.LogWriter = new ConsoleLogWriter(LogLevel.Debug);

// only allow 'ML-DSA-44' group of host key algorithms
sftp.Settings.SshParameters.HostKeyAlgorithms = SshHostKeyAlgorithm.MLDsa44;

// explicitly enable 'mldsa-44' host key algorithm only
sftp.Settings.SshParameters.SetHostKeyAlgorithms("ssh-mldsa-44");

// connect to an SSH server
sftp.Connect("test.rebex.net", 22);

// check server key fingerprint
if (sftp.Fingerprint.ToString() != "D5wjygbqhOAQ8O1chM7Vo1geEuQHuLT9WOgZO0z5cYE")
{
    throw new Exception("Warning: Unexpected server key.");
}

// authenticate and list remote root directory
sftp.Login("demo", "password");
Console.WriteLine(string.Join("\n", sftp.GetRawList("/")));
...

Rebex libraries have been tested with these third-party implementations of pure SSH ML-DSA:

PKIX-SSH secure shell, a fork of OpenSSH that adds X.509 v3 certificate support and other features; implements mldsa-NN algorithms
OQS-OpenSSH, a fork of OpenSSH that adds PQC algorithm support using liboqs for prototyping and evaluation purposes; implements ssh-mldsaNN algorithms

Last month, developers taking part in the IETF 126 Hackathon produced new sfluhrer-ssh-mldsa implementations:

We have not tested these new forks yet, but we should be compatible with their ssh-mldsa-44, ssh-mldsa-65 and ssh-mldsa-87. If you encounter any issues, let us know!

For more information about the 8.0 release and its enhancements, see release highlights.

Rebex .NET libraries 8.0: Quantum-safe security with ML-KEM and ML-DSA, improved TLS and SSH, FIPS 140-3 mode

Lukas Pokorny — Thu, 16 Jul 2026 14:00:00 GMT

First 8.0 release!

The 8.0.9673 release of Rebex components marks the official launch of the 8.0 series. The 7.0 series remain supported until June 2027, allowing enough time to upgrade your production workloads.

Quantum-safe security: ML-KEM and ML-DSA

The threat of "harvest now, decrypt later" makes early adoption of post-quantum cryptography (PQC) essential. Rebex 8.0 adds support for NIST-standardized PQC algorithms, ML-KEM and ML-DSA to TLS and SSH.

The SSH library now supports hybrid key exchange ciphers, combining standard algorithms with quantum-resistant keys: mlkem768nistp256-sha256, mlkem1024nistp384-sha384, and mlkem768x25519-sha256. The TLS library features X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.

SSH and TLS also have experimental support for ML-DSA to secure digital signatures against future quantum attacks. S/MIME got ML-DSA support as well.

PQC algorithms are supported out-of-box on up-to-date PQC-enabled Windows with .NET Framework 3.5/4.x or .NET 5 to 10. On other platforms, a PQC plugin is needed.

New SSH/SFTP server core

Thread consumption can stall high-throughput servers. Version 8.0 of Rebex File Server library addresses this bottleneck with an architectural overhaul, and introduces a new fully asynchronous SSH and SFTP core. This reduces overall thread allocation and maximizes scalability under parallel loads. The asynchronous transition extends to authentication and other events as well.

The new SFTP core also supports the copy-data extension that facilitates server-side file copying.

FTP server support

Need FTP protocol support for communication with legacy systems? There is no need to run detached server software any more because Rebex File Server adds server-side FTP and FTPS to its capabilities. It can secure FTP traffic with TLS 1.3 or 1.2, but can still be configured for legacy plain FTP as well to maintain integration with aging internal systems and legacy devices.

Updated S/MIME security

Rebex S/MIME API got support for additional signature algorithms: post-quantum ML-DSA, ECDSA, and Ed25519. It also got support for AEAD symmetric encryption ciphers: AES/GCM and ChaCha20/Poly1305.

More TLS features

Brainpool curves are now supported in TLS 1.3 as well. Client-side OCSP stapling support is another improvement, which improves the performance and privacy of certificate revocation checking by allowing the server to send a signed OCSP response during the TLS handshake, eliminating the need for the client to contact the certificate authority directly.

FIPS 140-3 mode and cryptography updates

Instead of FIPS 140-2, the UseFipsAlgorithmsOnly setting now enables FIPS 140-3 mode, which limits usage of cryptographic algorithms, and forces usage of cryptographic modules to those provided by .NET or the operating system. We also migrated from the legacy CryptoAPI to the new Windows CNG API. Additionally, HKDF key derivation in XtsStream and FileEncryption classes has been updated to support SHA-2 family of hashes.

New HTTP client core

Rebex HTTPS, Graph, EWS and WebSocket libraries feature a new HTTP client core that has been upgraded to fully asynchronous mode, making it less thread-hungry and more scalable.

Terminal control improvements

The new version of SSH Shell library and TerminalControl supports East Asian full-width characters alongside Unicode surrogate pairs. Prompt detection has been improved, and multi-line text matching is supported.

Major Graph API updates

Rebex Graph got new methods for working with attachments, and for updating a message. Many existing methods have been enhanced: messages can be deleted permanently, and subfolders can be created. The library features a new throttling support, making it easier not to overload the cloud.

API updates, changes and deprecations

In most scenarios, upgrading to version 8.0 is simple and straightforward. However, the new version of Rebex libraries does introduce some breaking changes, either due to abandoning long-deprecating APIs, for security reasons, or to fix compatibility with third-party tools. Before upgrading from 7.0, check out Version 8.0 Upgrade Guide for details.

And more...

For more information about the new release and all its enhancements, see the release history.

Rebex .NET libraries 8.0: Legacy Edition gets TLS 1.3

Lukas Pokorny — Thu, 16 Jul 2026 13:00:00 GMT

Due to enduring demand, we decided to keep Legacy Edition of Rebex libraries up-to-date once more.

The new Legacy Edition v8.0 targets .NET Framework 2.0, .NET Compact Framework 3.5, and .NET Compact Framework 3.9, making it possible to target systems as old as Windows 2000 or Windows Mobile 5, provided they have sufficient operating memory.

The new version adds lot of major new features from versions 6, 7, and 8, such as TLS 1.3 support (might require a plugin on very old platforms).

The 8.0 series will almost certainly be the last to target .NET Framework 2.0 and .NET Compact Framework. If you plan to use Rebex libraries on these platforms in 2028 and beyond, get in touch with us to discuss long-term support and maintenance options.

For more information about the 8.0 release and its enhancements, see the release history for mainstream edition. However, please note that Legacy Edition lacks some of the more recent additions, such as ML-KEM, ML-DSA, or server-side FTP support.

Rebex Buru SFTP Server 2.19.0: Argon2 password hashing

Lukas Paluzga — Tue, 26 May 2026 00:00:00 GMT

We have released Rebex Buru SFTP Server v2.19.0. Here is an overview of changes, fixes and improvements.

A big thank you to everyone who took the time to fill out our user survey! Most of the improvements in this release were directly shaped by your feedback. It really makes a difference, and we genuinely appreciate it. If you haven't had a chance to share your thoughts yet, we'd love to hear from you: fill out the survey here. It only takes a few minutes and helps us prioritize what matters most to you.

Argon2 password hashing (2.19.0)

Passwords stored in Buru SFTP Server's user database can now be hashed using Argon2, a memory-hard algorithm that is significantly more resistant to brute-force and GPU-accelerated cracking attacks than SHA-2. Argon2 comes in three variants: argon2d (optimized against GPU attacks), argon2i (optimized against side-channel attacks), and argon2id (a hybrid recommended for most use cases).

Unlike SHA-2, which is designed to be fast, Argon2 is intentionally expensive to compute. It requires much larger amount of RAM and CPU time, making cracking attacks far more costly. All parameters (parallelism, memory cost, time cost) are configurable.

Note that password hashing does not affect the security of the login process itself. Its purpose is to protect users' passwords in the event of a user database leak. When using Argon2 with recommended values, recovering the original passwords from a stolen database is extremely costly.

To enable Argon2, set users.passwordHashAlgorithm in your configuration:

users:
  passwordHashAlgorithm: { type: argon2id }

The passwordHashAlgorithm setting also continues to accept a plain string value (e.g. SHA512) for simpler configurations.

Setting pre-hashed passwords for existing users

The --password-hash option, previously available only in burusftp user add, has been added to burusftp user update as well. This makes it possible to assign a pre-hashed password to an existing user from the command line, which is useful when migrating password hashes from another system.

Minor changes and fixes

SSH
- Fixed diffie-hellman-group17-sha512 and diffie-hellman-group18-sha512 being advertised but not usable as key exchange algorithms. (2.18.4)
- Fixed terminal shell execution when running as a different user incorrectly requiring SeTcbPrivilege instead of SeAssignPrimaryTokenPrivilege and SeIncreaseQuotaPrivilege. (2.18.4)
Web Admin
- Added "Add new user" button to the users toolbar. (2.19.0)
- Added Save button to breadcrumb navigation on select pages. (2.19.0)
- Fixed breadcrumb display on Protection and FTP settings pages. (2.19.0)
- Fixed placeholder text showing incorrect hour values for idle duration and session duration fields. (2.18.4)

For a complete list of fixes and improvements, see the Release notes.

You can report issues and submit feature requests on our Github issue tracker.

For discussions and specific problems, please continue using our support forum.

Rebex Drive: Connect SFTP, FTP, and WebDAV storage as a Windows drive

Martin Vobr — Tue, 19 May 2026 00:00:00 GMT

Rebex Drive public preview is here

We have just released Rebex Drive - a free app that allows you to mount SFTP, FTP and WebDAV storage as a network drive.

Connect remote SFTP, FTP, or WebDAV storage and use it like a normal Windows drive

Working with files on a remote server is often more cumbersome than it should be.

You have data on an SFTP, FTP, FTP/SSL, or WebDAV server. You need to edit it, copy it, organize it, or open it in your usual tools. One option is to use a dedicated file transfer client, such as WinSCP, download the files locally, work with them, and upload them back when you are done.

That works. But it is not always convenient.

Rebex Drive takes a different approach. It lets you mount remote storage as a Windows drive, so you can work with remote files almost as if they were on a normal network disk.

Once mounted, the remote storage is available to regular Windows applications:

Windows Explorer
Microsoft Office
Photo managers
Development tools
- Anything else that works with files on a Windows drive

No special integration is needed in those applications. They just see a drive.

What's included in the first preview

We have released the first public preview of Rebex Drive.

This preview version is completely free.

It currently supports:

SFTP
FTP and FTP/SSL
WebDAV
mapping any number of remote drives
(well, at least until you run out of free drive letters)

The goal is simple: connect remote storage and use it from Windows like a normal drive.

Try it and tell us what you think

Rebex Drive is still in preview, so feedback matters. Want to add another protocol? A specific feature? Let us know.

If you try it, we would like to hear what worked, what did not, and what would make it more useful for your workflow.

Comments, bug reports, and feature suggestions are welcome at: support@rebex.net.

Rebex Buru SFTP Server 2.18.0: Post-quantum cryptography and SSH/SFTP core improvements

Lukas Paluzga — Tue, 03 Mar 2026 00:00:00 GMT

We have released Rebex Buru SFTP Server v2.18.0. Here is an overview of changes, fixes and improvements.

Post-quantum key exchange ciphers (2.18.0)

Quantum computers, once sufficiently powerful, might be able to break classical public-key cryptography such as RSA and elliptic-curve Diffie-Hellman. While large-scale quantum computers don't exist yet, encrypted data captured today could be decrypted in the future — a threat known as "harvest now, decrypt later".

To address this, Buru SFTP Server 2.18.0 adds support for NIST-standardized post-quantum key exchange based on ML-KEM (CRYSTALS-Kyber), used in a hybrid construction alongside classical algorithms. This means the key exchange is secure against both classical and quantum attacks:

mlkem768x25519-sha256 — ML-KEM-768 combined with X25519
mlkem768nistp256-sha256 — ML-KEM-768 combined with NIST P-256
mlkem1024nistp384-sha384 — ML-KEM-1024 combined with NIST P-384

These algorithms are already supported by OpenSSH 9.0+ and other modern SSH clients. See the full list of supported SSH algorithms.

SSH/SFTP core overhaul (2.18.0)

The SSH and SFTP processing core has been significantly redesigned to improve performance and reduce memory and thread usage. These improvements are most noticeable when serving many simultaneous connections.

Elliptic curve algorithm performance has also been improved on modern platforms.

Additional key exchange algorithms (2.18.0)

Two additional Diffie-Hellman key exchange algorithms are now supported, offering stronger security:

diffie-hellman-group17-sha512
diffie-hellman-group18-sha512

See the full list of supported SSH algorithms.

`copy-data` SFTP extension (2.18.0)

Buru SFTP Server now supports the copy-data SFTP extension, which allows clients to request server-side file copies without transferring data over the network. This results in significantly faster copy operations, especially for large files.

Minor changes and fixes

SSH
- Improved compatibility with some SSH clients that are sensitive to the order of SSH shell channel messages. (2.18.1)
FTP
- Fixed behavior of ftp.bindings[].externalAddress and ftp.bindings[].dataPortRange in FTPS implicit mode. (2.18.2)
Installer
- Now checks for a valid license before overwriting the existing installation when upgrading. (2.18.0)
- Silent uninstallation (/SILENT) no longer prompts for confirmation and deletes all configuration files. (2.17.3)
Web Admin
- Log viewer now shows the last 50 kB of the log file, with an option to view or download the full file. (2.18.3)
- Fixed 2FA status not being indicated correctly for some users. (2.18.0)
- Fixed an error when saving a user with an SSH public key. (2.17.2)
- Fixed an incorrect warning message "The WebRootPath was not found". (2.17.3)
- Log viewer is now accessible even when the configuration file is invalid but readable. (2.17.3)
- User's virtual path can now be specified without a leading slash. (2.17.3)
- Improved readability of users' public keys. (2.17.3)
Other
- Fixed LiteDB database locking error. (2.18.3)
- Fixed startup error when sshTunneling is present but disabled in the configuration file. (2.17.1)
- User authentication method is now logged at information level (previously debug). (2.17.3)
- Added an error log message when the service starts under the SYSTEM account with defaultShellType: terminal and allowSystemAccount not enabled. (2.17.3)

For a complete list of fixes and improvements, see the Release notes.

You can report issues and submit feature requests on our Github issue tracker.

For discussions and specific problems, please continue using our support forum.

Rebex .NET components 7.0.9448: Support for .NET 10

Lukas Pokorny — Tue, 18 Nov 2025 00:00:00 GMT

Support for .NET 10

This release adds a new set of binaries targeting .NET 10. The following platforms are supported:

Windows (x64, x86, ARM64)
Linux (x64, ARM32, ARM64)
Android (x64, ARM32, ARM64)
macOS (ARM64, x64)
iOS/iPadOS/tvOS (ARM64)

Of course, we still support earlier versions of .NET as well, including .NET Framework 3.5-4.8.1 and .NET 8-9. Additionally, support for .NET Compact Framework 3.5/3.9 and .NET Framework 2.0 is still available with Legacy Edition. For more information about supported platforms, see our framework support chart.

Support for Visual Studio 2026

In addition to Visual Studio 2022 and 2019, Rebex libraries and samples support the latest Visual Studio 2026.

And more...

For a detailed list of changes, see the release history.

Migrating from EWS to Microsoft Graph

Lukas Matyska — Tue, 23 Sep 2025 00:00:00 GMT

Note: Sample code in this article uses Rebex Graph .NET library. Download it here:

Microsoft will retire Exchange Web Services (EWS) in Exchange Online on October 1, 2026. The recommended way to access Exchange Online (Microsoft 365) going forward is via the Microsoft Graph API. This guide describes how to migrate from EWS to Microsoft Graph in order to access Exchange Online, and demonstrates how the same mailbox operations can be performed using Rebex EWS and Rebex Graph libraries for .NET.

Working directly with Microsoft Graph API means dealing with raw HTTP requests and handling many low-level details of the REST protocol. Rebex Graph provides a high-level API for accessing Exchange Online via Graph - without requiring deep knowledge of the protocol itself.

Key advantages of using Rebex Graph library:

A developer-friendly easy-to-use API that abstracts away the complexity of raw Graph requests.
Built-in S/MIME support, including parsing and working with signed or encrypted messages.
Automatic handling of throttling responses (HTTP 429/503/504 error codes) with retries logic.
Wide platform support, including .NET 5-10, .NET Framework 3.5-4.8 on Windows 7/8/10/11
(even .NET Compact Framework 3.5-3.9 is still supported).

Note: Microsoft Graph does not offer full feature parity with EWS. Some advanced or specialized operations may not yet be available or may require workarounds.

Configuring Graph access to Exchange Online
Migrating to Graph

Configuring Graph access to Exchange Online

Migrating from EWS to Microsoft Graph is not just a matter of switching API calls — it also requires updates to your authentication and permission setup. In this section, we'll highlight two essential changes you need to make before your application can access Exchange Online via Graph.

Changing application permissions

To access Exchange Online, your application needs to obtain an OAuth 2.0 token. Since Microsoft started disabling Basic Authentication for Exchange Online in October 2022, your app should already be registered in Azure Portal using an App Registration.

To switch to Microsoft Graph, you must configure new Graph-specific permissions in the Azure Portal based on your application's functionality. Here are some commonly used permissions when working with emails:

Mail.Read - read mailbox contents
Mail.ReadWrite - full read/write access to mailbox
Mail.Send - send mail as a user

Depending on you application type choose either Delegated or Application permission type.

Example of permission changes for an application operating in delegated (signed-in user) mode:

Previous EWS permissions:

New Graph permissions:

Example of permission changes for an application operating in unattended (application) mode:

Previous EWS permissions:

New Graph permissions:

If you prefer to configure new Azure App Registration from start, you can follow our blog posts to configure Graph access in delegated (signed-in user) mode or unattended (application) mode.

Changing OAuth scopes

When moving from EWS to Microsoft Graph, you also need to update the OAuth scope used for token requests.

Previous EWS scopes: commonly include either https://outlook.office365.com/.default or https://outlook.office365.com/EWS.AccessAsUser.All

New Graph scopes: the simplest option is to use https://graph.microsoft.com/.default - this instructs the Microsoft identity platform to issue a token based on the permissions configured in the App Registration. Alternatively, you can explicitly request only a subset of those permissions using scopes such as:

https://graph.microsoft.com/Mail.Read
https://graph.microsoft.com/Mail.ReadWrite
https://graph.microsoft.com/Mail.Send

Find more about scopes and permissions in the Microsoft identity platform.

Sample applications

To verify that your configuration works, you can use our sample applications available on GitHub.

To test access in delegated (signed-in user) mode, use the GraphOAuthWpfApp sample.
To test access in unattended (application) mode, use the GraphOAuthAppOnlyConsole sample.

Migrating to Graph

In this section, we’ll demonstrate how common mailbox operations were implemented using Rebex EWS and how they can be implemented using Rebex Graph.

Connecting and authenticating to Exchange Online

With Rebex EWS, connecting and authenticating looks like this:

// create EWS client instance
var client = new Rebex.Net.Ews();

// connect and authenticate to Exchange Online server
client.Connect("outlook.office365.com");
client.Login(token, EwsAuthentication.OAuth20);

With Rebex Graph, the code for connecting and authenticating looks similar:

// create Graph client instance
var client = new Rebex.Net.GraphClient();

// connect and authenticate to Exchange Online server
client.Connect();
client.Login(token);

In EWS SOAP API, client connects to https://outlook.office365.com/EWS/Exchange.asmx.
In Graph REST API, all requests go to https://graph.microsoft.com/.

In both cases, client authenticates using the Authorization header with a Bearer token.

Note: EWS supports both on-premises Exchange servers and Exchange Online, whereas Microsoft Graph is available exclusively for Exchange Online.
Note: EWS supports various authentication methods, including Basic Auth, NTLM, and Kerberos, whereas Microsoft Graph relies exclusively on OAuth 2.0.

Listing Inbox messages

With Rebex EWS, listing messages looks like this:

// create, connect and authenticate EWS client instance
var client = new Rebex.Net.Ews();
client.Connect("outlook.office365.com");
client.Login(token, EwsAuthentication.OAuth20);

var messages = client.GetMessageList(EwsFolderId.Inbox);

With Rebex Graph, the code for listing messages looks similar:

// create, connect and authenticate Graph client instance
var client = new Rebex.Net.GraphClient();
client.Connect();
client.Login(token);

var messages = client.GetMessageList(GraphFolderId.Inbox);

In EWS SOAP API, messages were listed using the FindItems operation.
In Graph REST API, messages from the Inbox are retrieved by requesting:

GET https://graph.microsoft.com/v1.0/me/mailFolders/inbox/messages

For details, see List messages in the Microsoft documentation.

Searching for messages

Microsoft Graph API provides two kinds of searching: $filter and full-text $search.

With Rebex EWS, the equivalent code for a $filter search and full-text $search (uses AQS search) looks like this:

// create, connect and authenticate EWS client instance
var client = new Rebex.Net.Ews();
client.Connect("outlook.office365.com");
client.Login(token, EwsAuthentication.OAuth20);

// perform EWS message search
var messages = client.Search(EwsFolderId.Inbox, EwsSearchParameter.Subject("invoice"));

// perform full-text AQS search
var fullText = client.Search(EwsFolderId.Inbox, EwsItemFields.Envelope, new EwsListView(), "subject:invoice");

With Rebex Graph, searching for messages looks like this:

// create, connect and authenticate Graph client instance
var client = new Rebex.Net.GraphClient();
client.Connect();
client.Login(token);

// perform the `$filter` search
var messages = client.Search("inbox", GraphMessageSearchParameter.Subject("invoice"));

// perform full-text `$search`
var query = new GraphMessageSearchQuery()
{
    RawSearch = "subject:invoice"
};
var fullText = client.Search("inbox", query);

In EWS SOAP API, messages were searched using the FindItems operation with search filters.
In Graph REST API, search can be performed using the $filter query parameter:

GET https://graph.microsoft.com/v1.0/me/messages?$filter=contains(subject,'invoice')

or the $search query parameter for full-text search:

GET https://graph.microsoft.com/v1.0/me/messages?$search="subject:invoice"

Note: Microsoft Graph $search works only for a limited set of message properties (approximately 15).
Note: Microsoft Graph cannot apply $filter to properties that are collections of complex objects (such as toRecipients, ccRecipients or bccRecipients). Use $search for filtering based on recipients instead.
Note: Microsoft Graph does not support combining $filter and $search in a single query, which makes it difficult to filter messages effectively - especially when filtering by recipients.
Note: Microsoft Graph imposes limitations on the use of the $orderby parameter. In some cases, this may result in the The restriction or sort order is too complex for this operation error. For details, see Using filter and orderby in the same query in the Microsoft documentation.

For details, see Filter and Search in the Microsoft documentation.

Downloading e-mail messages

With Rebex EWS, downloading messages looks like this:

// create, connect and authenticate EWS client instance
var client = new Rebex.Net.Ews();
client.Connect("outlook.office365.com");
client.Login(token, EwsAuthentication.OAuth20);

// get the message ID
EwsItemId messageId = ...

// download the message directly to a file on disk
client.GetMessage(messageId, "mail.eml");

// download the message and parse it for further processing
MailMessage message = client.GetMailMessage(messageId);

With Rebex Graph, the code for downloading messages looks similar:

// create, connect and authenticate Graph client instance
var client = new Rebex.Net.GraphClient();
client.Connect();
client.Login(token);

// get the message ID
GraphMessageId messageId = ...

// download the message directly to a file on disk
client.GetMessage(messageId, "mail.eml");

// download the message and parse it for further processing
MailMessage message = client.GetMailMessage(messageId);

In EWS SOAP API, a message was retrieved using the GetItem operation.
In Graph REST API, a message is retrieved by requesting its $value:

GET https://graph.microsoft.com/v1.0/me/messages/{messageId}/$value

For details, see Get message in the Microsoft documentation.

Sending messages

With Rebex EWS, sending messages looks like this:

// create, connect and authenticate EWS client instance
var client = new Rebex.Net.Ews();
client.Connect("outlook.office365.com");
client.Login(token, EwsAuthentication.OAuth20);

// compose message
MailMessage message = ...

// send the message
client.SendMessage(message);

With Rebex Graph, the code for sending messages looks similar:

// create, connect and authenticate Graph client instance
var client = new Rebex.Net.GraphClient();
client.Connect();
client.Login(token);

// compose message
var message = new MailMessage();
message.To = "to@example.com";
message.Subject = "Hello from Rebex Graph";
message.BodyHtml = "This message was sent using <b>Rebex Graph</b>";

// send the message
client.SendMessage(message);

In EWS SOAP API, the CreateItem operation with SendAndSaveCopy was used.
In Graph REST API, sending a message requires a POST request:

POST https://graph.microsoft.com/v1.0/me/sendMail

and setting desired Content-Type header and request body content.

Note: This operation requires Mail.Send permission to be configured in Azure App Registration.
Note: Microsoft occasionally changes the limits of Microsoft Graph API. In 2024, the size limit for a MIME message sent via sendMail was 3 MB. However, as of September 2025, we were able to successfully send a 45 MB message using sendMail (with default mailbox settings). The message size limits can be configured in the Microsoft 365 Exchange admin center (up to 150 MB).

For details, see Send mail in the Microsoft documentation.

Updating messages

With Rebex EWS, updating messages looks like this:

// create, connect and authenticate EWS client instance
var client = new Rebex.Net.Ews();
client.Connect("outlook.office365.com");
client.Login(token, EwsAuthentication.OAuth20);

// prepare message updates
var updates = new EwsMessageMetadata()
{
    Flag = new EwsFlag(EwsFlagStatus.Completed) { CompleteDate = DateTime.Today },
    Categories = new EwsCategoryCollection("Invoice", "Processed"),
    Importance = MailPriority.Low,
    IsRead = true,
};

// apply updates
client.UpdateItem(messageId, updates);

With Rebex Graph, the code for updating messages looks similar:

// create, connect and authenticate Graph client instance
var client = new Rebex.Net.GraphClient();
client.Connect();
client.Login(token);

// prepare message updates
var updates = new GraphMessageData()
{
    Flag = GraphFlag.CreateCompleted(DateTime.Today),
    Categories = new GraphCategoryCollection("Invoice", "Processed"),
    Importance = GraphImportance.Low,
    IsRead = true,
};

// apply updates
client.UpdateMessage(messageId, updates);

In EWS SOAP API, message updates were made using the UpdateItem operation.
In Graph REST API, messages are updated using a PATCH request:

PATCH https://graph.microsoft.com/v1.0/me/messages/{messageId}

and setting desired Content-Type header and request body content.

Note: This operation requires Mail.ReadWrite permission to be configured in Azure App Registration.
Note: The GraphClient.UpdateMessage() API will be available in upcoming 8.0 release (check-it out at NuGet.org as RC1).

For details, see Update message in the Microsoft documentation.

Deleting messages

With Rebex EWS, deleting messages looks like this:

// create, connect and authenticate EWS client instance
var client = new Rebex.Net.Ews();
client.Connect("outlook.office365.com");
client.Login(token, EwsAuthentication.OAuth20);

// get the message ID
EwsItemId messageId = ...

// delete message
client.DeleteItem(messageId, EwsDeleteMode.Permanent);

With Rebex Graph, the code for deleting messages looks similar:

// create, connect and authenticate Graph client instance
var client = new Rebex.Net.GraphClient();
client.Connect();
client.Login(token);

// get the message ID
GraphMessageId messageId = ...

// delete message
client.DeleteMessage(messageId, permanent: true);

In EWS SOAP API, the DeleteItem operation supported soft and hard deletes.
In Graph REST API, messages are soft-deleted using a DELETE request:

DELETE https://graph.microsoft.com/v1.0/me/messages/{messageId}

And hard-deleted using a POST request:

POST https://graph.microsoft.com/v1.0/me/messages/{messageId}/permanentDelete

Note: This operation requires Mail.ReadWrite permission to be configured in Azure App Registration.

For more details about soft-delete see Delete message and hard delete, see Permanent delete in the Microsoft documentation.

Listing folders

With Rebex EWS, listing folders looks like this:

// create, connect and authenticate EWS client instance
var client = new Rebex.Net.Ews();
client.Connect("outlook.office365.com");
client.Login(token, EwsAuthentication.OAuth20);

// list folders in the root folder
var rootFolders = client.GetFolderList();

// list folders in the 'Inbox' folder
var inboxFolders = client.GetFolderList(EwsFolderId.Inbox);

With Rebex Graph, the code for listing folders looks similar:

// create, connect and authenticate Graph client instance
var client = new Rebex.Net.GraphClient();
client.Connect();
client.Login(token);

// list folders in the root folder
var rootFolders = client.GetFolderList();

// list folders in the 'Inbox' folder
var inboxFolders = client.GetFolderList(GraphFolderId.Inbox);

In EWS SOAP API, listing folders was done using the FindFolder operation.
In Graph REST API, folders can be listed by requesting:

GET https://graph.microsoft.com/v1.0/me/mailFolders
or
GET https://graph.microsoft.com/v1.0/me/mailFolders/{folderId}/childFolders

For details, see List mail folders and List child folders in the Microsoft documentation.

Creating folders

With Rebex EWS, creating folders looks like this:

// create, connect and authenticate EWS client instance
var client = new Rebex.Net.Ews();
client.Connect("outlook.office365.com");
client.Login(token, EwsAuthentication.OAuth20);

// create new folder 'Orders' under 'Inbox'
EwsFolderId folderId = client.CreateFolder(EwsFolderId.Inbox, "Orders");

With Rebex Graph, the code for creating folders looks similar:

// create, connect and authenticate Graph client instance
var client = new Rebex.Net.GraphClient();
client.Connect();
client.Login(token);

// create new folder 'Orders' under 'Inbox'
GraphFolderInfo folder = client.CreateFolder(GraphFolderId.Inbox, "Orders");

In EWS SOAP API, folders were created using the CreateFolder operation.
In Graph REST API, folders can be created using POST request:

POST https://graph.microsoft.com/v1.0/me/mailFolders
or
POST https://graph.microsoft.com/v1.0/me/mailFolders/{folderId}/childFolders

and setting Content-Type: application/json header and request body content.

Note: This operation requires Mail.ReadWrite permission to be configured in Azure App Registration.

For details, see Create mail folder and Create child folder in the Microsoft documentation.

Deleting folders

With Rebex EWS, deleting folders looks like this:

// create, connect and authenticate EWS client instance
var client = new Rebex.Net.Ews();
client.Connect("outlook.office365.com");
client.Login(token, EwsAuthentication.OAuth20);

// get the folder ID
EwsFolderId folderId = ...

// delete folder
client.DeleteFolder(folderId);

With Rebex Graph, the code for deleting folders looks similar:

// create, connect and authenticate Graph client instance
var client = new Rebex.Net.GraphClient();
client.Connect();
client.Login(token);

// get the folder ID
GraphFolderId folderId = ...

// delete folder
client.DeleteFolder(folderId);

In EWS SOAP API, folders were deleted using the DeleteFolder operation.
In Graph REST API, folders can be deleted using DELETE request:

DELETE https://graph.microsoft.com/v1.0/me/mailFolders/{folderId}

Note: This operation requires Mail.ReadWrite permission to be configured in Azure App Registration.

For details, see Delete mail folder in the Microsoft documentation.

Rebex .NET components 7.0.9313: Maintenance release

Martin Vobr — Thu, 21 Aug 2025 00:00:00 GMT

Maintenance release

7.0.9313 is a hotfix release that resolves some minor issues and brings several improvements.

List of changes

SFTP: Added CurrentFileBytesTotal to TransferProgressChanged event arguments.
FTP: Added CurrentFileBytesTotal to TransferProgressChanged event arguments.
File System: Fixed possible ArgumentNullException when file system provider is used after an event handler is unregistered from file system notifier.
File System: Prevented internally handled NullReferenceException in implementation of VDirectory.Exists method.
Mail: Added IgnoreRedundantAsn1Data option to MailSettings/MimeOptions.
ZIP: Fixed missing logging for multi-file operations.
ZIP: Improved handling of 'version needed to extract' field to increase support for ZIP archives created on various platforms.
Networking: Prevented internal NullReferenceException when socket is closed and IO operation is in progress.
TLS Core: Fixed obfuscated type names in debug logs.
TLS Core: Fixed rare race condition between TLS 1.3 IO operations and shutdown/dispose logic.
Cryptography: Added IgnoreRedundantData option to SignedData and EnvelopedData classes.
Cryptography: Fixed NullReferenceException instead of InvalidOperationException in SignerInfo/KeyTransRecipientInfo and SignedData.

For complete version history, see the release history.

R6.18 available as well

For customers who have not yet upgraded to version 7 of Rebex libraries, we published the R6.18 update with important fixes and enhancements. Version R6.x will be supported until November 2025.

US court ruled: ComponentPro libraries stolen from Rebex

Martin Vobr — Thu, 22 May 2025 00:00:00 GMT

Using ComponentPro? We've got news that might affect your codebase. It was actually Rebex code – and we proved it in court.

ComponentPro has lost copyright infringement lawsuit because they were selling .NET components based on the code copied from our Rebex .NET libraries. Almost the same APIs, same internals – just rebranded and sold as their own. To hide the real authors, they changed the names of classes and some methods, but the vast majority of the code remains the same. We took them to court – and we won. Infringing company had to stop all business activities and Rebex acquired the ComponentPro.com domain.

What this means for you

If you bought any of the following ComponentPro products, you're using infringing software:

Ultimate Studio Suite
Network Expert Suite
FTP Expert Suite
Mail Expert Suite
FTP & FTPS
SFTP & SCP
Terminal Emulation
Mail Library
SFTP Server

A full breakdown of the case and affected libraries is available at www.componentpro.com

Here's the fix

If you bought from ComponentPro, you may not have known – but you're using code they had no right to sell. The code infringes on Rebex copyright.

We're not here to call you out – we're here to help.
We're offering a discounted upgrade to the official Rebex libraries.

Benefits of switching to the genuine version:

Latest updates, many improvements and security fixes
A real license that enables you to legally use the library
TLS 1.3 support, modern .NET compatibility
Direct support from the actual authors of the code

What to do

Just email us your original ComponentPro invoice. We'll handle the rest.
https://www.rebex.net/company/contact/

Let's get your codebase on solid ground – clean, legal, and supported.

Rebex .NET components 7.0.9209: Maintenance release

Lukas Pokorny — Wed, 23 Apr 2025 00:00:00 GMT

Support for RSA public key format from PKCS #1

SshPublicKey now supports the legacy RSA public key format specified by PKCS #1. This makes it possible to load keys that start with -----BEGIN RSA PUBLIC KEY----- header.

Improved error handling in multi-file operations

When information about a file or directory cannot be retrieved, a relevant exception with ProblemType property set to TransferProblemType.CannotRetrieveItemInfo is raised instead of an 'internal error'.

Improved IMAP folder info

HasChildren and HasNoChildren properties have been added to ImapFolder, representing \HasChildren and \HasNoChildren folder list attributes.

More fixes and improvements

For a detailed list of changes, see the release history.

Rebex Buru SFTP Server 2.17.0: SSH configuration improvements

Lukas Paluzga — Thu, 10 Apr 2025 00:00:00 GMT

We have released Rebex Buru SFTP Server v2.17.0. Here is an overview of changes, fixes and improvements.

SSH configuration improvements

SSH tunneling configuration changes (2.17.0)

SSH tunnels have been supported since early versions of Buru SFTP Server, however, without any Web Admin configuration and prone to endpoint conflicts.

We fixed the conflict issue and simplified the configuration by moving it from sshTunneling section to bindings section, on the same level as SFTP, SCP/Shell and FTP protocols:

# before
sshTunneling:
  enabled: true
  bindings:
    - { port: 22, ipAddress: 0.0.0.0 }

# after
bindings:
  - { port: 22, ipAddress: 0.0.0.0, sshTunnel: true, ... }

SSH tunneling can now be also enabled or disabled in the Web administration and is disabled by default.

Warning is shown on startup when sshTunneling section is present in the configuration file, its values are now ignored.

SSH shell configuration defaults now configurable using Web administration (2.17.0)

Default values for SSH shell home directory and SSH shell executable path are now configurable using Web administration. These values can be overridden per user.

Improved support for displaying user's public keys (2.17.0)

Based on a client's feedback, we improved the way user's public SSH keys can be displayed:

User's details in Web administration now show the user's public key with SSH algorithm prefix to make it easier to re-import to other applications, e.g. authorized_keys file.
Output of burusftp user inspect command now also contains full SSH public key, with SSH algorithm prefix.

Minor changes and fixes

Web Admin
- Fixed an issue when SSH shell settings were sometimes not editable (2.16.1)
Installer
- Fixed missing prompt to remove all configuration files when uninstalling. (2.16.1)

For a complete list of fixes and improvements, see the Release notes.

You can report issues and submit feature requests on our Github issue tracker.

For discussions and specific problems, please continue using our support forum.

Rebex Buru SFTP Server 2.16.0: Technological update

Lukas Paluzga — Fri, 31 Jan 2025 00:00:00 GMT

We have released Rebex Buru SFTP Server v2.16.0. Here is an overview of changes, fixes and improvements.

Technological Update

Buru SFTP Server is built on .NET platform, which provides the foundation for its security and reliability. With this release, we've made several key upgrades to ensure compatibility with the current .NET version and support long-term stability for our users.

In alignment with Microsoft's .NET lifecycle, we have transitioned Buru SFTP Server to .NET 8 (LTS), as .NET 6 support ended on November 12, 2024. You can read more about this change in the official .NET 6 support policy.

This transition enables us to continue delivering the latest .NET security updates to our users. However, it also means that Windows 7 and Windows 8 are no longer supported from this version on as these are not officially supported by .NET 8. For more details on .NET 8, including its support timeline, visit the official .NET 8 support page.

Library Upgrades

In addition to updating our framework, we’ve also upgraded the libraries that Buru SFTP Server relies on, including advanced logging features powered by Serilog.

Library	< 2.16.0 (previous)	>= 2.16.0 (current)
.NET	.NET 6.0	.NET 8.0
Serilog	2.12	4.1
Serilog.Extensions.Hosting	7.0	8.0
Serilog.Extensions.Logging	7.0	8.0
Serilog.Formatting.Compact	1.1	3.0
Serilog.Settings.Configuration	7.0	8.0
Serilog.Sinks.ColoredConsole	3.0.1	removed
Serilog.Sinks.Console	4.1	6.0
Serilog.Sinks.Debug	2.0	3.0
Serilog.Sinks.EventLog	3.1	4.0
Serilog.Sinks.File	5.0	6.0
Serilog.Sinks.RollingFile	3.3	removed
Serilog.Sinks.TextWriter	2.1	3.0

For more in-depth information on these features, refer to the Buru SFTP Server logging documentation.

FTP passive mode port and external address configuration (2.15.5)

In FTP passive mode, the client initiates both the command and data connections to the server. This approach is particularly beneficial when the client is behind a firewall or NAT (Network Address Translation) device, as it avoids the complications associated with incoming connections from the server.

Previously, the server would choose ports for passive mode connections from the dynamic port range assigned by the operating system. This range typically spans from 49152 to 65535.

With the latest release of Buru SFTP Server, administrators can now configure the FTP passive mode port range and specify the external IP address directly within the server settings.

The configuration can be accessed through the Web Administration interface under the FTP Settings section or configured directly in the config.yaml file.

Bug fixes

Fixed user database issue when some users couldn’t be loaded or updated (2.15.6)

We addressed an issue where user retrieval from the internal database sometimes failed due to indexing issues within the database, causing unpredictable behaviors and errors.

This manifested in various ways, including:

Inability to load specific user details
Failed attempts to delete certain users
Misleading error messages when creating a new user with an existing username

We have temporarily resolved this issue by removing the problematic index. However, a permanent solution will be implemented in the next major release when the database library is updated. The current version does not include a full fix due to the potential for breaking changes.

Added `no-cache` HTTP header to Web Admin responses to prevent displaying outdated content (2.15.6)

The Microsoft Edge browser has been observed to load content directly from its cache without checking for updates (e.g., using If-Modified-Since), unlike other browsers. This behavior can lead to users viewing outdated content.

To address this, we added the no-cache directive in the HTTP headers, instructing browsers to always verify with the server before using a cached page version.

For a complete list of fixes and improvements, see the Release notes.

You can report issues and submit feature requests on our Github issue tracker.

For discussions and specific problems, please continue using our support forum.

New Rebex prices for 2025

Martin Vobr — Wed, 29 Jan 2025 00:00:00 GMT

Why we are changing prices

For more than 22 years, we’ve been committed to delivering reliable, high-quality .NET libraries to help developers like you deliver complex projects with ease. Over the years, we’ve made significant improvements to our products, introduced new features and maintained exceptional support. After keeping our prices flat for the past 6 years, costs have increased to the point where a price adjustment is needed. Increased prices will allow us to continue improving our products and to continue supporting the software in the years to come.

Effective date

Price changes are effective as of May 1st, 2025.

New pricing

Product	New license	Renewal
.NET library packs
File Transfer Pack	$999	$499
Mail Pack	$499	$249
SSH Pack	$1,299	$649
Total Pack	$1,499	$749
Individual .NET libraries
EWS	$299	$149
File Server	$499	$249
FTP	$499	$249
Graph	$299	$149
HTTPS	$499	$249
IMAP	$299	$149
MSG	$299	$149
POP3	$299	$149
Security	$199	$99
SFTP	$499	$249
SMTP	$199	$99
SSH Shell	$999	$499
Syslog	$299	$149
Time	$199	$99
TLS	$999	$499
WebSocket	$499	$249
ZIP	$299	$149
Servers
Buru SFTP Server	$399	$199

(Prices for 1 developer / 1 server)

Current customers

We understand that price changes are never easy, and we’re committed to making this transition as smooth as possible.

90 days to get new licenses at the old price

The prices will change 90 days from the publication of this announcement. If you are considering purchasing additional licenses, you can do so in advance and pay the current price.

Buy new licenses

Lock your renewal prices for up to 3 years

You can lock in your current renewal pricing for up to 3 years if you renew your current support contract before the price changes. This applies if you choose to renew for multiple years. If you still have a few months left on your support contract, renew it before the price change on May 1st. Those additional years will be added to the end of your current contract.

Renew your support contract

Contact support

We understand that you may have questions regarding the price change. Please feel free to contact us at support@rebex.net. We're always here to help.

Rebex .NET components 7.0.9147: Maintenance release

Lukas Pokorny — Sun, 19 Jan 2025 00:00:00 GMT

Mitigated potential timing attack in XTS/AES

The tweak chunk preparation algorithm from IEEE 1619-2018 standard, used in Xts, XtsStream and FileEncryption classes, was found to be potentially susceptible to timing attacks. This release of Rebex Security / Rebex Total Packs resolves the issue.

Improved FTP compatibility

This release adds a workarounds for instances of HGFTP server that issue badly-formatted PWD response.

Tested with Windows 11 24H2, .NET 9.0.1 and .NET 8.0.12

All Rebex libraries have been tested on latest versions of Windows and .NET.

More fixes and improvements

For a detailed list of changes, see the release history.

Rebex .NET components 7.0.9083: Support for .NET 9

Lukas Pokorny — Tue, 12 Nov 2024 00:00:00 GMT

Support for .NET 9

This release adds a new set of binaries targeting .NET 9. All .NET 9 platforms are supported:

Windows (x64, x86, ARM64)
Linux (x64, ARM32, ARM64)
Android (x64, ARM32, ARM64)
macOS (ARM64, x64)
iOS/iPadOS/tvOS (ARM64)

Of course, we still support earlier versions of .NET as well, including .NET Framework 3.5-4.8.1 and .NET 5-8. For more information about supported platforms, see our framework support chart.

Rebex FTP/SSL renamed to Rebex FTP

We dropped the old 'SSL' part from the name of Rebex FTP library. In 2024, referring to TLS as 'SSL' no longer made sense. Of course, Rebex FTP still supports TLS. FTP over SSL 3.0 can be enabled as well, although it's discouraged because SSL is no longer secure and has been deprecated years ago.

And more...

For a detailed list of changes, see the release history.

R6.17 available as well

For customers who have not yet upgraded to version 7 of Rebex libraries, we published the R6.17 update with important fixes and enhancements. Version R6.x will be supported until November 2025.

New component: Rebex Graph - client API for MS Graph

Lukas Pokorny — Mon, 14 Oct 2024 00:00:00 GMT

Rebex Graph is a .NET library for accessing Microsoft 365 (Exchange Online) using Microsoft Graph API. It makes it possible to send, receive, list and search e-mail messages. It supports TLS 1.3/1.2 and S/MIME on all recent .NET platforms (including .NET Framework 3.5-4.8 and .NET 6.0-8.0).

Easy-to-use API

With Rebex Graph's simple API, working with e-mails in Microsoft's cloud is easy:

var client = new Rebex.Net.GraphClient();

// connect and authenticate to Exchange Online (Microsoft 365) server
client.Connect();
client.Login(token);

// get list of top 10 unread messages in Inbox and show their headers
var page = new GraphPageView(0, 10);
var unread = GraphMessageSearchParameter.IsRead(false);
var list = client.Search(GraphFolderId.Inbox, page, unread);

foreach (var info in list)
{
    Console.WriteLine("{0}: {1}", info.ReceivedDate, info.Subject);
}

Having troubles with setting up client access for your app in Microsoft's Azure? Check out our extensive blog posts that come with working sample code:

Rebex Graph is available as a standalone package, or as a part of Rebex Total Pack or Rebex Mail Pack. If you already have an active support contract for Rebex Total Pack or Rebex Mail Pack (formerly Rebex Secure Mail), you can download the full version including the Graph library now!

Secure Mail becomes Mail Pack. Mail libraries available separately.

Jan Sotola — Thu, 10 Oct 2024 00:00:00 GMT

We are introducing new packaging of Rebex email libraries:

Individual libs

All mail libraries

Mail Pack

Why are we making this change?

In the past, most of Rebex mail libraries were available together in Rebex Secure Mail. However, some users needed only a part of the functionality.

Now, it is possible to buy any of these libraries separately at a lower price, or all together for the same price.

We've also added the MSG library to 'Secure Mail', and renamed the bundle to 'Mail Pack'. This makes the naming consistent with our other .NET library packages.

I already have a Rebex Secure Mail license. What changes for me?

You've been upgraded to Rebex Mail Pack for free.
You can use the MSG library as well.
API and DLLs stay the same. No change is needed in your code.
When renewing your Rebex Secure Mail support contract, you will be offered a Rebex Mail Pack renewal.

Introductory pricing

For a limited time, the price of Rebex Mail Pack is the same as for Rebex Secure Mail ($299 for a new single developer license, $149 for renewal). Individual component are priced lower (starting at $199 or $99 for SMTP).

Questions?

If you have any questions or comments, please contact us at support@rebex.net.

Rebex Buru SFTP Server 2.15.4: FTP protocol support.

Lukas Paluzga — Thu, 10 Oct 2024 00:00:00 GMT

We have released Rebex Buru SFTP Server v2.15.4. Here is an overview of changes, fixes and improvements.

FTP protocol support

Buru SFTP Server now supports FTP and FTPS protocol, in addition to already supported SFTP, SCP and SSH protocols. FTP protocol is disabled by default and can be enabled either for individual users or for all users at once. Each FTP endpoint can be assigned a separate set of X.509 certificates. Both implicit and explicit FTPS modes are supported.

Buru SFTP Command Prompt now asks for administrator privileges by default

This has been source of confusion for users as running most burusftp commands without administrator privileges would fail with permission errors.

Minor fixes and improvements

2.14.5

Fixed errors when parsing some configuration IP addresses with leading or trailing whitespace.
Web Admin - added SSH port placeholder on SSH endpoints page.
Web Admin - fixed Maximum renegotiation threshold caption on Additional SSH settings page.
Web Admin - fixed minor UI issue when typing a file path containing a space character.

2.15.0

Initial FTP protocol support:
- Added support for FTP protocol (plain FTP, implicit and explicit FTPS).
- Disabled by default. Can be enabled globally in configuration or per user.
- Each FTPS endpoint can be configured with different certificate(s).
Added user field ’note’ for user comments.
Installer - Buru SFTP Command Prompt now runs with administrator privileges by default.
Removed server configuration parameters passwordPolicy and usernamePattern. These parameters have been deprecated since v1.1.0.
Web Admin - configuration pages are now accessible when configuration file is invalid but readable.
Fixed burusftp user key delete -F <fingerprint> behavior with SHA-256: prefix.
Updated Serilog logging libraries.

2.15.1

Fixed an issue where username leading/trailing whitespace was not trimmed when creating a user.
Web Admin - fixed error when loading user detail page for user with special characters in username.
Web Admin - fixed error message when adding user with existing username.

2.15.2

Web Admin - fixed browser cache issue after application upgrade.

2.15.3

Web Admin - fixed error when loading FTP settings page.

2.15.4

Added burusftp certgen command to generate self-signed X.509 (TLS) certificates. This is an alias for burusftpwa certgen.
Web Admin - FTP certificate group can now be renamed.
Web Admin - fixed FTP binding custom certificate group not being saved properly.

For complete list of fixes and improvements see Release notes

Issues and feature requests on Github

You can report issues and submit feature requests on our Github issue tracker. For discussions and specific problems please keep using our support forum.

using Rebex.Net;

SFTP test server options for .NET developers

Where do I point my SFTP client while testing?

Option 1: The SFTP server you already have

Option 2: test.rebex.net - zero setup, read-only

Option 3: Rebex Tiny SFTP Server - unzip, click Start

Option 4: Rebex File Server .NET library - run the server in-process

Option 5: Buru SFTP Server - the one you can script

Option 6: Third-party servers, when you need the weird ones

Quick summary

How to use ML-DSA with Rebex SSH libraries

Rebex .NET libraries 8.0: Quantum-safe security with ML-KEM and ML-DSA, improved TLS and SSH, FIPS 140-3 mode

First 8.0 release!

Quantum-safe security: ML-KEM and ML-DSA

New SSH/SFTP server core

FTP server support

Updated S/MIME security

More TLS features

FIPS 140-3 mode and cryptography updates

New HTTP client core

Terminal control improvements

Major Graph API updates

API updates, changes and deprecations

And more...

Rebex .NET libraries 8.0: Legacy Edition gets TLS 1.3

Rebex Buru SFTP Server 2.19.0: Argon2 password hashing

Argon2 password hashing (2.19.0)

Setting pre-hashed passwords for existing users

Minor changes and fixes

Rebex Drive: Connect SFTP, FTP, and WebDAV storage as a Windows drive

Rebex Drive public preview is here

Connect remote SFTP, FTP, or WebDAV storage and use it like a normal Windows drive

What's included in the first preview

Try it and tell us what you think

Rebex Buru SFTP Server 2.18.0: Post-quantum cryptography and SSH/SFTP core improvements

Post-quantum key exchange ciphers (2.18.0)

SSH/SFTP core overhaul (2.18.0)

Additional key exchange algorithms (2.18.0)

copy-data SFTP extension (2.18.0)

Minor changes and fixes

Rebex .NET components 7.0.9448: Support for .NET 10

Support for .NET 10

Support for Visual Studio 2026

And more...

Migrating from EWS to Microsoft Graph

Table of contents

Configuring Graph access to Exchange Online

Changing application permissions

Example of permission changes for an application operating in delegated (signed-in user) mode:

Example of permission changes for an application operating in unattended (application) mode:

Changing OAuth scopes

Sample applications

Migrating to Graph

Connecting and authenticating to Exchange Online

Listing Inbox messages

Searching for messages

Downloading e-mail messages

Sending messages

Updating messages

Deleting messages

Listing folders

Creating folders

Deleting folders

Rebex .NET components 7.0.9313: Maintenance release

Maintenance release

List of changes

R6.18 available as well

US court ruled: ComponentPro libraries stolen from Rebex

What this means for you

Here's the fix

Benefits of switching to the genuine version:

What to do

Rebex .NET components 7.0.9209: Maintenance release

Support for RSA public key format from PKCS #1

Improved error handling in multi-file operations

Improved IMAP folder info

More fixes and improvements

Rebex Buru SFTP Server 2.17.0: SSH configuration improvements

SSH configuration improvements

SSH tunneling configuration changes (2.17.0)

`copy-data` SFTP extension (2.18.0)

Added `no-cache` HTTP header to Web Admin responses to prevent displaying outdated content (2.15.6)