Welcome to the VanDyke Software Forums

Join the discussion today!


Go Back   VanDyke Software Forums > General

Reply
 
Thread Tools Display Modes
  #1  
Old 02-22-2019, 06:49 AM
it@aperia.com it@aperia.com is offline
Registered User
 
Join Date: Feb 2019
Posts: 2
Upgrading from v4.1.1 build 862 to v4.3

I am looking to upgrade from version 4.1.1 to 4.3 and have a couple questions.

First, are there any incompatibilities from 4.1.1 to 4.3 post upgrade and will our current DSS 1024 bit host key continue to work afterward?

Then, since our host key is not up to par, how do I set a second host key to begin migrating users to? I have created a second host key, but I can't get SecureFX or WinSCP to see it. Clients only see the old host key, the first one in the list. We have many customers with automated processes which will need special attention, so we cannot replace the host key abruptly. Thanks.
Reply With Quote
  #2  
Old 02-22-2019, 09:03 AM
bgagnon bgagnon is offline
VanDyke Technical Support
 
Join Date: Oct 2008
Posts: 3,736
Hello it@aperia.com,

A VShell upgrade is a significant undertaking and often involves discussion of sensitive topics. You might want to send an email to support@vandyke.com and reference "Attn Brenda - Forum Thread #13416" if additional clarifying info is needed.

Please see this tip on our website regarding backing up VShell's configuration. Note that if you use the complete export option that includes all data (including sensitive data such as host keys), you should be sure to take all necessary steps to safeguard that data accordingly.

More information on the importance of Host Keys within the Secure Shell protocol can be found in this whitepaper.


Quote:
First, are there any incompatibilities from 4.1.1 to 4.3 post upgrade and will our current DSS 1024 bit host key continue to work afterward?
What do you mean by incompatibilities?

I've attached a complete list of bug fixes, new features and changes to VShell from v4.1.2 to the current release, v4.4.1.

Yes, 1024-bit DSA/DSS host keys are still supported but they are not recommended and as of v4.2.5 RSA is the default host key algorithm generated on new installations of VShell:

Changes in VShell 4.2.5 (Official) -- March 2, 2017
---------------------------------------------------
  • The default host key generated for new installations is now an RSA 2048 bit key.

Quote:
Then, since our host key is not up to par, how do I set a second host key to begin migrating users to? I have created a second host key, but I can't get SecureFX or WinSCP to see it. Clients only see the old host key, the first one in the list. We have many customers with automated processes which will need special attention, so we cannot replace the host key abruptly.
I'm including additional info below just for the benefit of the community, but in your case, there is likely a cached or saved host key of the old type (DSA) that will need to be removed/cleared if you want SecureFX/WinSCP to prompt you to accept the new type. In SecureFX, you can manage host keys in the SSH Host Keys category of Global Options.

For the automated processes, it just depends on what is possible with their SFTP client.



Host keys are the cornerstone of security with SSH/SFTP, so it is important to keep a few caveats in mind when considering making changes to your host key.

More information on the importance of Host Keys within the Secure Shell protocol can be found in this whitepaper.

Changing an existing host key or adding a new host key may impact users that are currently able to connect to the server. When a user first connects to a server they are usually prompted to review, confirm, and save a copy of the server's host key. Every time the client connects thereafter to that same host, the host key presented by the server is compared against the client's saved copy. If the keys match, the client allows the connection; if the keys do not match, the client will typically warn the user of the discrepancy.

If you replace an existing host key in VShell's configuration, every client that has a saved copy of the prior host key will see a warning the next time they connect to VShell. Clients will then need to review, confirm, and save the new host key. This can cause the most trouble when automated tasks have been configured; the automated systems may not be able to review, confirm, and save the new host key, thus interfering with the automation.

This same host key discrepancy may also occur when adding a secondary key to VShell's configuration. Even when VShell continues to offer the prior host key, some of the client implementations may prefer the newer, more secure, host key rather than continuing to accept the older host key. This can lead to the same concerns as replacing the host key outright.

If you decide to move forward with adding or changing a host key in VShell, consider adopting the best practice of notifying all of your clients in advance of the change. Such a notification would ideally include the fingerprints of the new VShell host key so that clients can easily validate the new key when their software notifies them of the detected discrepancy. If an additional key type is added to VShell, it would be a good idea for the notice to include the fingerprints of all configured host keys VShell offers; this would allow individuals to compare the client-side calculated fingerprint against all the fingerprints you've published in your notification.

For fingerprint info of VShell's host keys, go to the SSH2 / Host Keys category, select the applicable line in the Host keys window and the fingerprints are shown below in several formats (MD-5, SHA-1, SHA-2 and SHA-2 base64).

VShell allows having one host key of each algorithm it supports. As of v4.4.1 that is: DSA, RSA, ECDSA and Ed25519.

Attached Images
File Type: png vshell_host_keys_category.png (41.6 KB, 71 views)
Attached Files
File Type: txt History - VShell 4.1.2 - 4.4.1 Official.txt (30.5 KB, 25 views)
__________________
Thanks,
--Brenda

VanDyke Software
Technical Support
support@vandyke.com
(505) 332-5730
Reply With Quote
  #3  
Old 02-22-2019, 09:51 AM
it@aperia.com it@aperia.com is offline
Registered User
 
Join Date: Feb 2019
Posts: 2
Thanks for your detailed response.

When I referenced incompatibilities I meant in regard to feature changes between them, e.g., you have a special consideration tip for upgrading from version 3.5 to 4.1 which broke older clients that didn't support newer, stronger key algorithms.

As to the host key, I appreciate and understand your comments. However, I was asking more about if there is a method to control who gets which host key. For instance, I currently have the original 1024-bit DSA key listed first as well as a second, new ED25519 key listed below it.

When I connect with my WinSCP client after removing all saved host keys, I am presented with only the DSA key to accept. When I connect with SecureFX I am only presented with the ED25519 key. Neither client has the option to accept one or the other key. Nor does a client which already has saved the DSA key have the ability to choose the new key instead.

What I was wondering was is there a way to present both keys for clients to choose from, but not interrupt existing clients who have already accepted the old key. I am trying to avoid having to bring up a new host for clients to move to while our current one continues to run until it can be decommissioned.
Reply With Quote
  #4  
Old 02-22-2019, 11:12 AM
bgagnon bgagnon is offline
VanDyke Technical Support
 
Join Date: Oct 2008
Posts: 3,736
Hi it@aperia.com,
Quote:
What I was wondering was is there a way to present both keys for clients to choose from ...
Both (all) *are* presented to clients, it's just that they usually have a say in the negotiation too.

This can be verified in SecureFX's log:
Code:
i Available Remote Host Key Algos = ecdsa-sha2-nistp256,ssh-rsa
i Selected Host Key Algo = ssh-rsa
In the above instance I was connecting to VShell, which had both ECDSA and RSA host keys. The client was configured to prefer RSA at the time of the above connection.

But after making the changes noted below, I was prompted to accept the new host key and you can see in the log ECDSA was now used.
Code:
i Available Remote Host Key Algos = ecdsa-sha2-nistp256,ssh-rsa
i Selected Host Key Algo = ecdsa-sha2-nistp256


I can't speak to how WinSCP handles it, but for SecureFX you can configure an order of precedence for the host key algorithms.

You will need to modify two session .ini file options.

Session .ini files are stored in the Sessions subfolder of the configuration folder. The location of your installation's Configuration folder is found in the General / Configuration Paths category of SecureFX's Global Options.

Note: If you have use the /F option in the target of a shortcut used to launch SecureFX, then the path to the Config folder will be different than the path above.


To edit a session's .ini file:
  1. Close all instances of SecureFX (and SecureCRT if installed). If changes are made to the session's .ini file while SecureFX is running, the changes made will be undone when SecureFX is restarted.

  2. Edit the session's .ini file:

    D:"Use Global Host Key Algorithms"=00000001
    To:
    D:"Use Global Host Key Algorithms"=00000000

    S:"Host Key Algorithms"=ssh-rsa,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,null,x509v3-sign-rsa,x509v3-ssh-rsa,x509v3-sign-dss,x509v3-ssh-dss,ssh-dss
    To:
    S:"Host Key Algorithms"=ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-ed25519,null,x509v3-sign-rsa,x509v3-ssh-rsa,x509v3-sign-dss,x509v3-ssh-dss,ssh-dss

    [Set it to whatever order you desire. Must be comma-separated, no space between.]

  3. Save changes made to the session's .ini file and start SecureFX.
__________________
Thanks,
--Brenda

VanDyke Software
Technical Support
support@vandyke.com
(505) 332-5730
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -6. The time now is 08:30 PM.