In order to use public and private key based authentication to SFTP to your server, you need to have SSH enabled on your hosting account. Most hosts do not enable SSH by default, so you might want to check with your host and get it enabled if it isn't already. Once SSH is enabled, connecting to your server is simple. Here are three main steps involved:
Feb 07, 2017 If you use the Search capability at the Home Page of RSA Link, and search for something like 'unsupported protocol or cipher suite', you will find a knowledge base, KB article that will help you configure around a problem like this.
So let's look at these steps in details:
In order to use SFTP, we first need to generate public and private key pairs. This can easily be done using Cpanel as detailed in the steps below:
Step 1:Login to Your Cpanel and click on SSH Shell Access under the security section.
Step 2: Click on the Manage SSH Keys button and then Click on the Generate a New Key link.
Step 3: On this page, enter the following details:
Once all details are entered, click on Generate Key (refer image above). This will generate a public and private key pair. You should now be able to see these files in your Manage SSH Keys page.
Step 4: On the Manage SSH Keys page, click on Manage Authorization and then click the Authorize button. This will authorize the key for usage as shown in the image below.
Step 5: Click on the View or Download link in the Private Keys section to covert and download your private key.
We now need to convert the private key to PPK format. You can do this using the covert key option on Cpanel, or you can download the raw file and covert it to PPK format using PuttyGen. In most cases, the Cpanel convert option works pretty good, so you can stick with it. But in-case, you don't have that option in your Cpanel account, you can use the Puttygen method. Let's look at both these methods:
Option 1: Converting the key to PPK format using Cpanel Covert key option:
To use this option, enter your passphrase in the space provided and click Convert as shown in the image below. You can then download the converted key to your computer and save it in an accessible location.
Note: The passpharse is the key password that you used while generating the keys in Cpanel.
Option 2: Converting the Key to PPK format Using PuttyGen:
This option involves using PuttyGen to convert the key. If you don't have PuttyGen installed, you can download it free from here. Once downloaded and installed, follow these steps:
Step 1: As shown in the image above (marked Option 2), click on the 'Download Key' button on the View or Download SSH Keys page. This will download the private key (id_rsa) to your computer. Copy and save this file in an accessible location.
Step 2: Open the PuttyGen application and click Run.
Step 3: Go to Conversions > Import Key, browse to the location of your downloaded private key file (id_rsa) and select the file.
Once you load the file you will be prompted to enter the passpharse. Enter the passpharse and click ok.
Step 4: Make sure that the SSH2 RSA option is selected and the number of bits is set to 2048.
Step 5: Click on Save private key and save the file with your preferred name. (Refer image above).
Now that we have our public and private keys setup, we can SFTP to the server. You can do this using any FTP client like Filezilla or WinSCP. I am using WinSCP for this tutorial.
Step 1: Open WinSCP and create a new FTP connected by clicking on New Site and enter the following details:
Step 2: Click on the Advanced botton to open the Advanced Site Settings page as shown in point no.6 in the image above.
Step 3: On the Advanced Site Settings page click on Authentication and then browse to the location of your PPk file. Refer image below:
Step 4: Once done, click ok and then click Save to save the settings.
Step 5: Click Login to login to your server using SFTP. Once the connection is establised and the server has finished verifing the private and public keys, you will be promoted to enter the passpharse. Enter the passpharse and click Ok.
You should now be connected to your server using SFTP.
For issues that might arise using the latest FlowSsh versions, see Known issues.
Security Notification: [ 27 October 2019 ]
Authors of the Minerva attack have identified a small but significant timing information leak in the Crypto++ implementation of ECDSA over prime field curves. This attack may allow discovery of a private key through repeated observation of signature timing. If the leak can be utilized, an attacker could compromise a server host key or a client authentication key using a practical number of connections across a network.
The following is the impact on Bitvise SSH Server, SSH Client and FlowSsh versions before 8.36:
On all recent Windows versions (Vista and higher), there is no effect on users of Bitvise software versions 7.xx and 8.xx who use private keys of algorithms RSA, Ed25519, or ECDSA over the NIST curves nistp256, nistp384 or nistp521. On all recent versions of Windows, and using recent Bitvise software versions, these algorithms use Windows cryptography, which is unaffected by Minerva. In the case of Ed25519, we similarly use a non-Crypto++ implementation, which is unaffected.
On all versions of Windows, using all versions of Bitvise software, the Minerva issue may apply to users who generated, and are using, host keys or client keys of type ECDSA/secp256k1. Bitvise software versions 8.35 and earlier use Crypto++ to implement this algorithm on all platforms. We encourage such users to update to our latest software versions.
On Windows XP and Windows Server 2003, regardless of Bitvise software version; and for Bitvise software versions 5.xx and 6.xx, regardless of Windows version; the Minerva issue may apply to users of ECDSA private keys of any type. We encourage such users to update to our latest software versions, and/or to update to newer versions of Windows.
With Bitvise SSH Server, SSH Client and FlowSsh 8.36, we are releasing the following mitigations:
On all recent Windows versions (Vista and higher), where we previously used Crypto++ to support ECDSA/secp256k1, we are switching to alternatives. If the version of Windows is recent enough (for example, Windows 10, Windows Server 2016 and 2019), our default cryptographic provider (CiWinCng) now uses Windows cryptography to support ECDSA/secp256k1 as well as ECDH/secp256k1. Where Windows does not support secp256k1 (for example, Windows Vista to 8.1 and Windows Server 2008 to 2012 R2), we now support it using OpenSSL.
On Windows XP and Windows Server 2003, we face the issue that maintained cryptographic libraries that continue to support these platforms are hard to switch to and harder to find, while the number of users is small and diminishing. In current versions, we continue to rely on Crypto++ on these platforms, but implement mitigations to make it harder or impossible to observe signature timing across the network.
On all versions of Windows, we continue to use Crypto++ to support non-standard DSA keys. These are DSA keys as used in SSH of size other than 1024 bits. Since versions 7.xx, we have discouraged the use of DSA keys of any size. Also, DSA is not within scope of the Minerva research, so the current attack does not apply directly. Nevertheless, because we use Crypto++ to support non-standard DSA keys on all platforms, we now activate mitigations for these keys to make it harder or impossible to observe signature timing remotely.
Changes in FlowSsh 8.36: [ 27 October 2019 ]
Implemented mitigations for the Minerva attack as discussed in the security notification:
On Windows 10, Windows Server 2016 and 2019, the algorithms ECDSA/secp256k1 and ECDH/secp256k1 now use Windows cryptography. As a result, these algorithms are now also available when FIPS mode is enabled in Windows.
On Windows Vista to 8.1, and Windows Server 2008 to 2012 R2, the algorithms ECDSA/secp256k1 and ECDH/secp256k1 now use OpenSSL instead of Crypto++. As a side effect, use of these algorithms on Windows Vista now requires at least Service Pack 1 (OpenSSL will fail to initialize on Vista without service packs).
On Windows XP and Windows Server 2003, our software continues to use Crypto++ for all algorithms, but implements mitigations to make it harder or impossible to observe signature timing remotely. Continuing support for these Windows versions is increasingly impractical for multiple reasons including cryptography. Like Microsoft and other software vendors have done, we will need to stop supporting these platforms eventually, but we still support them right now.
Changes in FlowSsh 8.35: [ 20 August 2019 ]
Fixed a deadlock which could occur in FlowSshC/Cpp/Net if a directory listing or file transfer was aborted by closing the SFTP channel after SSH_FXP_OPEN or SSH_FXP_OPENDIR was sent, but before SSH_FXP_HANDLE was received.
There exist interim, but deployed versions of SSH implementations including SmartFTP which implement the no-flow-control extension based on a previous, non-final draft where the extension value was empty. FlowSsh will now no longer disconnect when receiving an unrecognized no-flow-control extension value, but will attempt to continue; and will now treat an empty value as if the remote party sent 'p' (for 'preferred').
Very old PuTTY versions before 0.58 are now treated as not global-request capable. When these versions are waiting for a channel open confirmation, they will treat any packet other than a channel open confirmation as a failure (including if the packet is a global request).
Changes in FlowSsh 8.31: [ 15 April 2019 ]
Fixed a memory safety issue which seems to be hard to trigger, but could have security ramifications.
Via a user report, we identified a type of Dropbear server which does not respond to SSH_MSG_GLOBAL_REQUEST. This may work properly in other Dropbear servers, but since the affected server cannot be distinguished from others by its SSH version string, FlowSsh will no longer send global requests to Dropbear servers.
Changes in FlowSsh 8.23: [ 27 December 2018 ]
Fixed an issue in previous 8.xx versions which would prevent Bitvise SSH Client and FlowSsh from connecting to a server that supports host key synchronization and employs a key type the client does not support. This affected connections from Windows XP and Windows Server 2003, where our cryptographic provider does not support Ed25519; and use under FIPS mode, where Ed25519 and ECDSA/secp256k1 are not supported.
Changes in FlowSsh 8.21: [ 17 December 2018 ]
In version 8.15, FlowSsh would not use RSA private or public keys larger than 8192 bits. This limit is once again 16384 bits.
If the server implements RFC 8308, FlowSsh now includes the extension 'global-requests-ok' in its SSH_MSG_EXT_INFO.
Remote version string parsing for compatibility decisions is now consolidated and unified.
Changes in FlowSsh 8.15: [ 28 October 2018 ]
FlowSsh now supports automatic host key rotation. The application can implement a handler to synchronize keys from Bitvise SSH Server and any other servers that support the OpenSSH mechanism 'hostkey update and rotation'. Bitvise SSH Server will announce to clients all configured host keys, including those not employed, to facilitate host key rotation. A FlowSsh application can automatically trust new host keys announced by a trusted server and remove any keys the server has removed.
FlowSsh now relays to the application any descriptions configured on the server for server-configured port forwarding rules.
A new file transfer mode, TextLf, is now supported. This works the same as AutoLf, but forces newline conversions without relying on file type detection.
Bitvise SSH Server, SSH Client and FlowSsh once again support non-standard DSA keys larger than 1024 bits. We do not recommend using these keys, and new keys of this type cannot be generated. Also, these keys cannot be used when FIPS mode cryptography is enabled in Windows. Re-adding support for these keys is intended to resolve an obstacle that may still be preventing some users of 6.xx versions from upgrading.
When using Windows cryptography, Bitvise SSH Server, SSH Client and FlowSsh now implement a backup strategy for DH and ECDH key exchange. Windows implements key exchange, but it does not expose the agreed value in a form suitable for SSH. Bitvise software must retrieve the value by carefully traversing undocumented Windows structures. In versions 7.xx, this required our software to be upgraded to continue working after the Windows 10 1803 update. FlowSsh will now fall back to Crypto++ if it cannot perform key exchange because Windows internal structures have changed. However: if FIPS mode is enabled in Windows, this backup strategy is not used, and FlowSsh must be updated.
When importing keys, such as from files, the stage at which an import failed is now described in more detail.
FlowSsh now supports the delay-compression extension. Delayed compression reduces a server's attack surface for unauthenticated clients by delaying availability of compression until after a user is authenticated. The delay-compression extension is an improvement over previously supported alternatives: the zlib@openssh.com method contains a by-design race condition, while the approach of invoking a second key exchange doubles the overhead of establishing an SSH session.
Security Clarification:
We are receiving occasional inquiries about whether our software is affected by the libssh vulnerability CVE-2018-10933, where a client can bypass authentication by sending an SSH_MSG_USERAUTH_SUCCESS message to the server.
Bitvise software does not share common code with libssh. Our understanding is that the libssh issue arises due to commingling of authentication state for server-side and client-side purposes. In Bitvise software, authentication state is managed in separate client-side and server-side components. The server-side authentication component is not affected by this issue and will ignore any SSH_MSG_USERAUTH_SUCCESS message sent by the client.
Changes in FlowSsh 7.46: [ 14 October 2018 ]
After the SSH session has been terminated by receiving EOF or sending SSH_MSG_DISCONNECT, FlowSsh will now discard any further outgoing SSH packets. This helps avoid a stall in processing and further improves the odds that all previously received data will be processed.
File transfer: Fixed an issue where, if the connection was lost during a download while synchronization was being performed, the local file size would be reset to zero.
As a maintenance release, this version continues an upgrade amnesty. For users with FlowSsh licenses for use in applications independent of Bitvise SSH Client, any FlowSsh activation code that could activate a previous 7.xx version will also activate this version. Medieval ii total war cd key generator.
Changes in FlowSsh 7.45: [ 11 August 2018 ]
Bitvise SSH Server, SSH Client, and FlowSsh previously did not implement strict size limits or sanitization of content before displaying or logging strings received from a remote party. Much stricter size limits and sanitization are now implemented.
Bitvise SSH Server, SSH Client, and FlowSsh now report the size of the Diffie Hellman group actually used in DH key exchange. This is useful with key exchange methods that use DH group exchange, where there was previously no straightforward way to know what size group was used.
Changes in FlowSsh 7.44: [ 1 July 2018 ]
Cryptography: Implemented support for changes in Windows internal cryptographic structures in Windows Insider Preview Build 17704. This build was released to Windows Insiders in the Fast ring on June 27, 2018.
Users who need to use earlier versions of our software on new Windows builds that change internal structures can work around compatibility issues by using the following key exchange algorithms: Curve25519, ECDH over nistp256k1. These key exchange methods do not rely on Windows cryptography; however, our software does not provide them if FIPS mode is enabled in Windows. Other key exchange methods require upgrading our software to a version that supports the new Windows build.
Changes in FlowSsh 7.43: [ 19 June 2018 ]
File transfer: Fixed issues in past Bitvise software versions that resulted in incorrect file times when using subsecond times with SFTP protocol versions 4 and 6. This would result in incorrect last modified times after a file transfer which affected, on average, about one in several hundred files. Affected files would receive a last modified timestamp incorrect by up to 7+ minutes.
C compatibility: Made necessary changes so that FlowSshC.h can again be used without change using the Microsoft Visual Studio compiler in C mode (not C++ mode).
Security Notification: [ 18 May 2018 ]
We have been informed of, and have taken steps to address:
Issue 1:
This issue consists of an invalid memory access. At this time, we believe this memory access is always invalid and cannot be used for remote code execution.
This issue has the following impact on Bitvise SSH Server and Client:
High severity: When an affected Bitvise SSH Server version is installed on a 32-bit version of Windows, a remote unauthenticated attacker can cause the SSH Server's main service to stop abruptly.
This high severity impact is not present on 64-bit versions of Windows. The following other impacts are present on all versions of Windows.
Lower severity: An authenticated user connected to Bitvise SSH Server who is permitted to use the SFTP subsystem can cause the SFTP subsystem to stop abruptly. This can have an effect on what actions are logged. For example, an error might be logged instead of the last actions taken by the user.
Lower severity: A server to which a user connects using Bitvise SSH Client can cause the SSH Client to stop abruptly. Due to the limited effects, this would not be an interesting attack in most usage scenarios.
Low severity: If a user or administrator imports a specially crafted file when using either the local Bitvise SSH Server Control Panel; the remote Bitvise SSH Server Control Panel; or Bitvise SSH Client; then the process being used to import the file can stop abruptly. Due to the limited effects, this would not be an interesting attack in most usage scenarios.
In addition, this issue has the following impact on applications using FlowSsh:
If an application using the 32-bit version of FlowSsh connects to a server which sends a specially crafted packet that should cause FlowSsh to disconnect, the application will instead stop abruptly. The severity of this impact depends on the characteristics of the application.
At this time, we believe applications using the 64-bit version of FlowSsh are unaffected.
The following versions of our software are affected by issue 1:
We have addressed issue 1 in Bitvise SSH Server, Client, and FlowSsh versions 7.41 and higher. In addition, we have addressed issue 1 for Bitvise SSH Server 6.xx versions due to the high severity impact on 32-bit versions of Windows.
At this time, the limited impact does not seem to warrant applying this change to 6.xx versions of Bitvise SSH Client and FlowSsh. We encourage users of Bitvise SSH Client to upgrade to the latest versions free of charge. Users of FlowSsh 5.xx will need to have upgrade access to a 7.xx version to upgrade.
Issue 2:
Issue 2 consists of incorrect delayed initialization in a compression library used by Bitvise software. We believe this could be used by one SSH session that uses compression to corrupt decompressed data in another simultaneous session that uses compression. However, for this to be likely, there must not have been another session that used compression since application startup. Therefore, the attack would have to occur at the same time as when the first legitimate session that uses compression begins after Bitvise SSH Server or an application using FlowSsh has started.
The following versions of our software are affected by issue 2:
Bitvise SSH Client only ever establishes one SSH session per process instance, so the issue cannot be exploited. A FlowSsh application could be affected if it simultaneously starts multiple concurrent SSH sessions after launching.
Mitigation:
We recommend that all users of affected Bitvise SSH Server, Client, and FlowSsh versions upgrade to the newest current versions, which can be downloaded from our website:
In addition, users of Bitvise SSH Server versions 6.xx who do not wish to upgrade can download version 6.51, which also fixes issue 1, but not issue 2.
Changes in FlowSsh 7.41: [ 29 April 2018 ]
This is not a new feature release, but a successor to 7.39 with continued maintenance updates. (We skip over versions containing zeros to avoid ambiguities. For example, 7.04 and 7.40 might both be referred to as '7.4'.)
Fixed an issue in zlib compression provided by the Crypto++ library. There existed a race condition which could cause data to be decompressed incorrectly in specific circumstances. For this to happen, the first SSH session to use compression, and the second SSH session to use compression, would have to be initiated at the same time after the application using FlowSsh is started.
Fixed a denial of service attack vector described in the associated security notification.
FlowSsh will no longer send fire-and-forget SSH_FXP_CLOSE messages by default. Depending on circumstances such as network latency, Bitvise SSH Server versions up to and including 7.39 could fail to process the SSH_FXP_CLOSE request and incorrectly log that the final transfer may not have completed as intended. This has been fixed in the SSH Server with version 7.41.
Changes in FlowSsh 7.39: [ 20 January 2018 ]
SFTP: In past 7.xx versions, Bitvise SSH Client and FlowSsh would perform a Resume check regardless of the type of server if Overwrite was enabled for upload. We suspect this could cause creation of an empty file with the same name on servers that support creation of multiple files with the same name.
The Resume check will no longer be performed when connected to a server that does not support SFTP v6 check-file and check-file-blocks extensions. With a server that supports these extensions, the Resume check will continue to be performed for Overwrite, since in this case Resume and Overwrite are the same operation.
Security Clarification: [ 5 January 2018 ]
We have received inquiries about whether our software is affected by the Meltdown and Spectre vulnerabilities.
Meltdown and Spectre are fundamentally CPU vulnerabilities which require the attacker to be able to execute carefully selected code, in many cases with high-resolution timers. These vulnerabilities are generally not exploitable in situations where the attacker cannot run such code. If you are using Bitvise software for SFTP or SCP file transfer, port forwarding, Git access, or limited terminal access using the BvShell terminal shell, these types of access do not present an opportunity to exploit these vulnerabilities.
If you are using Bitvise SSH Server to provide terminal shell access to non-administrator users, then if these non-administrator users can run arbitrary programs, they can also run programs that could take advantage of Meltdown to gain administrative access. In this case, we recommend that you apply a Windows patch that attempts to mitigate the CPU vulnerabilities that enable Meltdown.
Changes in FlowSsh 7.36: [ 27 November 2017 ]
This is the first version of Bitvise SSH Server, SSH Client, and FlowSsh published from the United States.
All assets, operations, relationships, and agreements related to Bitvise software development and licensing; including license agreements for use of Bitvise software by users; have been transferred from Bitvise Limited incorporated in Gibraltar, to Bitvise Limited now incorporated in Texas.
Final builds are now performed in Texas. Our software development continues in Slovenia, Germany, and Hungary, and may include developers elsewhere in the future.
This move is an administrative change. Our development, ownership, pricing, support, terms and policies and relationship to customers generally remain the same.
For the purpose of export from the United States, our SSH Server, SSH Client and FlowSsh are self-classified as Mass-Market products using the ECCN 5D992, with the encryption authorization type identifier MMKT. These denote eligibility under License Exception ENC § 740.17(b)(1) of the Export Administration Regulations (EAR).
Bitvise SSH Server, SSH Client, and FlowSsh now come with new license agreements. Users must review the new EULAs, even though the terms remain substantially the same. We apologize for this inconvenience, and have attempted to draft the agreements in a way that this might not be necessary very often.
Windows 10 version 1709, OS build 17046.1000, changed internal Windows structures in a way that prevented Bitvise SSH Server, SSH Client, and FlowSsh from obtaining the agreed value in DH or ECDH key exchange. This prevented successful SSH connections using this new Windows build. Fixed.
There exist SSH implementations based on WeOnlyDo, e.g. freeSSHd, which might not send failure description and language tag fields when sending an SSH_MSG_CHANNEL_OPEN_FAILURE message. Bitvise SSH Server, SSH Client and FlowSsh will now behave as though these fields were sent as empty strings, instead of disconnecting due to an unexpected packet format.
Changes in FlowSsh 7.35: [ 16 September 2017 ]
We have identified two compatibility issues in current and past versions of mod_sftp for ProFTPD:
We expect these issues will be resolved in future mod_sftp versions. However, mod_sftp now comes configured by default to not send its version in the SSH version string. A client therefore cannot distinguish between a newer version that contains these fixes, and an older version which does not.
At this time, Bitvise SSH Client and FlowSsh will avoid the known compatibility issues by restricting SFTP protocol version to 3 when mod_sftp is detected. We would like to lift this restriction in the future if there arises a way to detect the mod_sftp version early enough.
We have identifed a compatibility issue with Van Dyke VShell:
Bitvise SSH Client and FlowSsh will now recognize the check-file extension indicator in the supported2 packet as required by the SFTP extensions draft, in addition to check-file-name and check-file-handle.
Bitvise SSH Client and FlowSsh will now recognize a check-file-blocks extension sent by servers. We suggest that future SFTP server implementations advertise support for check-file-blocks if all of the following are true:
Changes in FlowSsh 7.34: [ 1 August 2017 ]
Changes in FlowSsh 7.31: [ 3 May 2017 ]
Changes in FlowSsh 7.29: [ 31 March 2017 ]
Changes in FlowSsh 7.24: [ 14 January 2017 ]
Changes in FlowSsh 7.21: [ 31 December 2016 ]
Changes in FlowSsh 7.15: [ 4 September 2016 ]
Changes in FlowSsh 7.14: [ 3 August 2016 ]
Changes in Bitvise FlowSsh 7.12: [ 25 June 2016 ]
Changes in Bitvise FlowSsh 5.39: [ 5 April 2016 ]
Changes in Bitvise FlowSsh 5.38: [ 26 January 2016 ]
Security Notification: [ 30 November 2015 ]
We have recently discovered a security issue in a common library used by Bitvise software. Given specific, but common conditions, this issue can be exploited by an unauthenticated remote attacker to cause instability and denial of service in affected software. We cannot exclude that this issue could be exploited to run arbitrary code.
The following versions of our software are affected:
To help mitigate this issue, Bitvise SSH Server versions 6.44 and 6.45, and Bitvise SSH Client versions 6.44 and 6.45; and FlowSsh version 5.37; contain an upgrade amnesty, so that any existing license that is valid for any of the software versions affected by this issue can be used with the respective latest unaffected software version. This means that all users of Bitvise SSH Server and Client 5.xx and 6.xx can upgrade to version 6.45, and can activate it using their existing activation code. This also applies to FlowSsh users upgrading to version 5.37.
Users of Bitvise SSH Server and Client per-installation licenses can log in to access their existing activation codes.
Users of FlowSsh, and users of large-scale licenses, can upgrade using activation codes received in order delivery.
Changes in Bitvise FlowSsh 5.37: [ 10 November 2015 ]
Changes in Bitvise FlowSsh 5.36: [ 29 October 2015 ]
Changes in Bitvise FlowSsh 5.35: [ 30 August 2015 ]
Changes in Bitvise FlowSsh 5.34: [ 2 May 2015 ]
Changes in Bitvise FlowSsh 5.33: [ 26 April 2015 ]
Changes in Bitvise FlowSsh 5.27: [ 4 November 2014 ]
.NET Application Domains: In our current design, FlowSsh is incompatible with applications that use .NET Application Domains. The FlowSsh implementation makes heavy use of fibers, which .NET Application Domains do not support. This means FlowSsh is currently not a suitable choice for use in ASP.NET (within an IIS process).