This version continues the upgrade access amnesty introduced in version 9.25, so it can be used with any license that is valid for a previous SSH Server 9.xx version. The minimum upgrade access expiry date to activate this version is January 1, 2022.
: Researchers have identified an issue where all SSH connections which use the encryption algorithm ChaCha20-Poly1305, or any integrity algorithm of type encrypt-then-MAC, are vulnerable to packet sequence manipulation by an active attacker, if the attacker can intercept the network path. This can be used to sabotage SSH extension negotiation. This affects extensions with security impact, such as server-sig-algs.
Since the attacker can only remove packets sent before user authentication, this does not seem to fatally break the security of the SSH connection. However, it is a cryptographic weakness to address.
Bitvise software versions 9.32 and newer support strict key exchange. This is a new SSH protocol feature which mitigates this attack. The SSH client and server must both implement strict key exchange for mitigation to be effective. Other SSH software authors are also releasing new versions to support this.
If you must interoperate with SSH software which does not support strict key exchange, consider disabling the encryption algorithm ChaCha20-Poly1305, as well as integrity algorithms of type encrypt-then-MAC. These are the newer data integrity protection algorithms whose names contain -etm.
Bitvise software versions 8.xx and older are not substantially affected because they do not implement algorithms where this issue is practically exploitable. Nevertheless, we suggest updating all SSH software to new versions that support strict key exchange.
The encryption algorithms aes256-gcm and aes128-gcm are substantially immune from this attack. Users who are committed to older SSH software versions should consider using AES GCM. If this is not possible, the data integrity protection algorithms which are not named -etm are not entirely immune, but are also not believed to be practically exploitable. For compatibility with SSH software which does not support strict key exchange or AES GCM, an algorithm combination such as AES CTR with non-ETM data integrity protection may continue to be acceptable.
General:
If the SSH Server was configured to accept FTPS connections, but no certificate was employed; or if the employed certificate was not usable because it expired; the SSH Server would stop running and refuse to start, even for SSH connections, until the administrator fixed the certificate issue.
The SSH Server will now start, and continue running, as long as the configuration allows connections to be handled on at least one SSH or FTPS binding.
SSH:
When a user authentication banner is entered directly in SSH Server settings, the SSH Server will no longer strip leading and trailing whitespace. If the banner does not end with a newline, the SSH Server will now append it. This avoids OpenSSH displaying the last line incorrectly.
Email notifications:
Further improved error messages when SMTP sending fails.
Settings:
When a list of address accept rules was imported from CSV using the options Import blocked IPs or Import permitted IPs, IP address ranges were imported incorrectly. Fixed.
File transfer:
When using a mount point of type Another SFTP server, the other SFTP server may support SFTP protocol version 5 or higher, but not SFTP v5+ file locking. In this case, the SSH Server now strips file open block flags sent by the client if the block flags include SSH_FXF_BLOCK_ADVISORY.
As in previous versions, it is possible to always strip block flags by configuring mount point settings:
File sharing behavior: Force File sharing for uploads: Read, Write, Delete File sharing for downloads: Read, Write, Delete
When using a mount point of type Another SFTP server, and the other server uses SFTP v3, the SSH Server now lets an SFTP v4+ client set a file modification time without having to also include the last access time.
The SSH Server now logs most SFTP flags and bits as human-readable strings instead of hexadecimal values.
FTPS:
The SSH Server would replace non-US-ASCII bytes with "." when sending reply lines on the FTP control connection. To improve compatibility with clients, the SSH Server now preserves UTF-8 (which may appear in directory names) in FTP control connection replies.
We are receiving inquiries about whether our software is affected by the recent XZ Utils backdoor described in CVE-2024-3094.
Bitvise software does not use XZ Utils and is not affected by this issue.
Changes in Bitvise SSH Client 9.34: [ 11 April 2024 ]
Installation:
When installing using command-line parameters, the -autoUpdates parameter could previously be used only to disable automatic updates. It now also supports other values (stronglyRecommended, recommended or allAvailable).
The FlowSshNet library, an optional SSH/SFTP scripting feature included with the SSH Client, now uses the Universal C Runtime. This allows the SSH Client to no longer include the outdated Visual C++ 2010 CRT. As a result, FlowSshNet is now installed only on Windows 7 SP1 or newer. (Previously, this feature was compatible with Windows Vista or newer.)
SFTP drive:
Updated the WinFsp version included with the SSH Client to 2.0.23075.
Improved the WinFsp installation process.
SSH:
When connecting through an SSH jump proxy, interactive authentication methods can now be used to authenticate against the jump proxy. Previously, only pre-configured (unattended) authentication could be used.
When the SSH Client fails to connect to a server, the error message now contains more detailed information about IP addresses to which the client attempted to connect.
stermc:
In certain versions of Windows, the Windows function ScrollConsoleScreenBufferW fails if the destination coordinate is the same as the origin. This would cause previous stermc versions to exit with an error. Fixed.
sftpc:
The sftpc command-line client now supports new get/put command parameters:
-rv: Resume verifiably. Acts like -r for Resume, but does not resume unless the server supports synchronization using block-by-block hashing. This avoids corruption which is possible if heuristic resume detects the file can be resumed, but there are subtle changes in the middle of the file.
-noSync: Disables synchronization using block-by-block hashing, even if the server supports it. This can be used with -r to achieve a faster heuristic resume, but corruption is possible if there are subtle changes in the middle of the file.
-noBuf[=y|n]: If the server supports the extended SFTP attribute no-buffering@bitvise.com, this allows the user to express a preference whether the server should open the file for unbuffered I/O.
SFTP:
The graphical SFTP interface now remembers its maximization state.
The graphical SFTP interface now offers an option to clear recent folder history.
When using cut & paste (rather than copy & paste) between Local and Remote panes, files are now moved instead of copied.
In both graphical SFTP and sftpc, the Resume and Overwrite options are now once again available separately, even if the server supports synchronization using block-by-block hashing. This allows the user to express a preference to resume a file, but only if the partial destination file is unchanged relative to the source.
When uploading, the SSH Client now includes the extended SFTP attribute intended-size@bitvise.com to communicate the final intended size of the file. This can help detect and diagnose incomplete transfers.
The mirror feature would incorrectly remove destination files after they were mirrored, if the file names were present in the destination with a different case than in the source. Fixed.
The mirror feature now supports a fast skip option which attempts to skip files which are present in both source and destination with the same size and last modification time. This can dramatically improve the speed of large mirror transfers where most files are unchanged, but at the cost of not verifying the content of skipped files.
Version 9.34 added logic to ensure SFTP responses are sent in the same order requests are received. Due to an oversight, the SSH Server's file transfer subsystem would hang, most readily if a client sent consecutive SFTP requests with the same request ID. This was observed with WS_FTP (version 12.9) and also with phpseclib. Fixed.
The SSH Server now implements the SFTP extended request fsync@openssh.com for files opened with unbuffered I/O.
Witaj gościu. Dziękujemy, że przeglądasz nasze forum ale czy wiesz, że zakładając konto możesz w pełni korzystać z dobrodziejstw jakimi są promocje i konkursy. Nie zobaczysz tu też żadnych reklam a rejestracja zajmie Ci tylko chwilę.
Ta strona wykorzystuje ciasteczka (cookies) w celu: utrzymania sesji zalogowanego Użytkownika, gromadzenia informacji związanych z korzystaniem z serwisu, ułatwienia Użytkownikom korzystania z niego, dopasowania treści wyświetlanych Użytkownikowi oraz tworzenia statystyk oglądalności czy efektywności publikowanych reklam.Użytkownik ma możliwość skonfigurowania ustawień cookies za pomocą ustawień swojej przeglądarki internetowej. Użytkownik wyraża zgodę na używanie i wykorzystywanie cookies oraz ma możliwość wyłączenia cookies za pomocą ustawień swojej przeglądarki internetowej.
