This page is about the OpenSSH version of `ssh-keygen`. For Tectia SSH, see here. If you wish to generate keys for PuTTY, see PuTTYgen on Windows or PuTTYgen on Linux.

1. 32 Lives Keygen Not Working

• Creating an SSH Key Pair for User Authentication
• Make Sure There Is Enough Randomness

May 6, 2017 - 54 sec - Uploaded by Yousif Garabetthis video show you how to fix keygen not opening in MacOS Sierra or El Capitcan. Support for it in clients is not yet universal. Thus its use in general purpose applications may not yet be advisable. The algorithm is selected using the -t option and key size using the -b option. The following commands illustrate: ssh-keygen -t rsa -b 4096 ssh-keygen -t dsa ssh-keygen -t ecdsa -b 521 ssh-keygen -t ed25519 Specifying the File.

What Is ssh-keygen?

Ssh-keygen is a tool for creating new authentication key pairs for SSH. Such key pairs are used for automating logins, single sign-on, and for authenticating hosts.

SSH Keys and Public Key Authentication

The SSH protocol uses public key cryptography for authenticating hosts and users. The authentication keys, called SSH keys, are created using the keygen program.

SSH introduced public key authentication as a more secure alternative to the older .rhosts authentication. It improved security by avoiding the need to have password stored in files, and eliminated the possibility of a compromised server stealing the user's password.

However, SSH keys are authentication credentials just like passwords. Thus, they must be managed somewhat analogously to user names and passwords. They should have a proper termination process so that keys are removed when no longer needed.

Creating an SSH Key Pair for User Authentication

The simplest way to generate a key pair is to run ssh-keygen without arguments. In this case, it will prompt for the file in which to store keys. Here's an example:

First, the tool asked where to save the file. SSH keys for user authentication are usually stored in the user's .ssh directory under the home directory. However, in enterprise environments, the location is often different. The default key file name depends on the algorithm, in this case id_rsa when using the default RSA algorithm. It could also be, for example, id_dsa or id_ecdsa.

Then it asks to enter a passphrase. The passphrase is used for encrypting the key, so that it cannot be used even if someone obtains the private key file. The passphrase should be cryptographically strong. Our online random password generator is one possible tool for generating strong passphrases.

Choosing an Algorithm and Key Size

SSH supports several public key algorithms for authentication keys. These include:

• rsa - an old algorithm based on the difficulty of factoring large numbers. A key size of at least 2048 bits is recommended for RSA; 4096 bits is better. RSA is getting old and significant advances are being made in factoring. Choosing a different algorithm may be advisable. It is quite possible the RSA algorithm will become practically breakable in the foreseeable future. All SSH clients support this algorithm.
• dsa - an old US government Digital Signature Algorithm. It is based on the difficulty of computing discrete logarithms. A key size of 1024 would normally be used with it. DSA in its original form is no longer recommended.
• ecdsa - a new Digital Signature Algorithm standarized by the US government, using elliptic curves. This is probably a good algorithm for current applications. Only three key sizes are supported: 256, 384, and 521 (sic!) bits. We would recommend always using it with 521 bits, since the keys are still small and probably more secure than the smaller keys (even though they should be safe as well). Most SSH clients now support this algorithm.
• ed25519 - this is a new algorithm added in OpenSSH. Support for it in clients is not yet universal. Thus its use in general purpose applications may not yet be advisable.

The algorithm is selected using the -t option and key size using the -b option. The following commands illustrate:

Specifying the File Name

Normally, the tool prompts for the file in which to store the key. However, it can also be specified on the command line using the -f <filename> option.

Copying the Public Key to the Server

To use public key authentication, the public key must be copied to a server and installed in an authorized_keys file. This can be conveniently done using the ssh-copy-id tool. Like this:

Once the public key has been configured on the server, the server will allow any connecting user that has the private key to log in. During the login process, the client proves possession of the private key by digitally signing the key exchange.

Adding the Key to SSH Agent

ssh-agent is a program that can hold a user's private key, so that the private key passphrase only needs to be supplied once. A connection to the agent can also be forwarded when logging into a server, allowing SSH commands on the server to use the agent running on the user's desktop.

For more information on using and configuring the SSH agent, see the ssh-agent page.

Creating Host Keys

The tool is also used for creating host authentication keys. Host keys are stored in the /etc/ssh/ directory.

Host keys are just ordinary SSH key pairs. Each host can have one host key for each algorithm. The host keys are almost always stored in the following files:

The host keys are usually automatically generated when an SSH server is installed. They can be regenerated at any time. However, if host keys are changed, clients may warn about changed keys. Changed keys are also reported when someone tries to perform a man-in-the-middle attack. Thus it is not advisable to train your users to blindly accept them. Changing the keys is thus either best done using an SSH key management tool that also changes them on clients, or using certificates.

Using X.509 Certificates for Host Authentication

OpenSSH does not support X.509 certificates. Tectia SSH does support them. X.509 certificates are widely used in larger organizations for making it easy to change host keys on a period basis while avoiding unnecessary warnings from clients. They also allow using strict host key checking, which means that the clients will outright refuse a connection if the host key has changed.

Using OpenSSH's Proprietary Certificates

OpenSSH has its own proprietary certificate format, which can be used for signing host certificates or user certificates. For user authentication, the lack of highly secure certificate authorities combined with the inability to audit who can access a server by inspecting the server makes us recommend against using OpenSSH certificates for user authentication.

However, OpenSSH certificates can be very useful for server authentication and can achieve similar benefits as the standard X.509 certificates. However, they need their own infrastructure for certificate issuance. See more information on certificate authentication.

Key Management Requires Attention

It is easy to create and configure new SSH keys. In the default configuration, OpenSSH allows any user to configure new keys. The keys are permanent access credentials that remain valid even after the user's account has been deleted.

In organizations with more than a few dozen users, SSH keys easily accumulate on servers and service accounts over the years. We have seen enterprises with several million keys granting access to their production servers. It only takes one leaked, stolen, or misconfigured key to gain access.

In any larger organization, use of SSH key management solutions is almost necessary. SSH keys should also be moved to root-owned locations with proper provisioning and termination processes. For more information, see how to manage SSH keys. A widely used SSH key management tool for OpenSSH is Universal SSH Key Manager.

Practically all cybersecurity regulatory frameworks require managing who can access what. SSH keys grant access, and fall under this requirement. This, organizations under compliance mandates are required to implement proper management processes for the keys. NIST IR 7966 is a good starting point.

Make Sure There Is Enough Randomness

It is important to ensure there is enough unpredictable entropy in the system when SSH keys are generated. There have been incidents when thousands of devices on the Internet have shared the same host key when they were improperly configured to generate the key without proper randomness.

General Purpose Systems

On general purpose computers, randomness for SSH key generation is usually not a problem. It may be something of an issue when initially installing the SSH server and generating host keys, and only people building new Linux distributions or SSH installation packages generally need to worry about it.

Our recommendation is to collect randomness during the whole installation of the operating system, save that randomness in a random seed file. Then boot the system, collect some more randomness during the boot, mix in the saved randomness from the seed file, and only then generate the host keys. This maximizes the use of the available randomness. And make sure the random seed file is periodically updated, in particular make sure that it is updated after generating the SSH host keys.

Many modern general-purpose CPUs also have hardware random number generators. This helps a lot with this problem. The best practice is to collect some entropy in other ways, still keep it in a random seed file, and mix in some entropy from the hardware random number generator. This way, even if one of them is compromised somehow, the other source of randomness should keep the keys secure.

Embedded Devices and Internet of Things

Available entropy can be a real problem on small IoT devices that don't have much other activity on the system. They may just not have the mechanical randomness from disk drive mechanical movement timings, user-caused interrupts, or network traffic. Furthermore, embedded devices often run on low-end processors that may not have a hardware random number generator.

The availability of entropy is also critically important when such devices generate keys for HTTPS.

Our recommendation is that such devices should have a hardware random number generator. If the CPU does not have one, it should be built onto the motherboard. The cost is rather small.

Command and Option Summary

Here's a summary of commonly used options to the keygen tool:

-b “Bits”
This option specifies the number of bits in the key. The regulations that govern the use case for SSH may require a specific key length to be used. In general, 2048 bits is considered to be sufficient for RSA keys.

-e “Export”
This option allows reformatting of existing keys between the OpenSSH key file format and the format documented in RFC 4716, “SSH Public Key File Format”.

-p “Change the passphrase” This option allows changing the passphrase of a private key file with [-P old_passphrase] and [-N new_passphrase], [-f keyfile].

-t “Type” This option specifies the type of key to be created. Commonly used values are: - rsa for RSA keys - dsa for DSA keys - ecdsa for elliptic curve DSA keys

-iInput When ssh-keygen is required to access an existing key, this option designates the file.

-fFile Specifies name of the file in which to store the created key.

-NNew Provides a new passphrase for the key.

-PPassphrase Provides the (old) passphrase when reading a key.

-cComment Changes the comment for a keyfile.

-p Change the passphrase of a private key file.

-q Silence ssh-keygen.

-v Verbose mode.

-lFingerprint Print the fingerprint of the specified public key.

-BBubble babble Shows a bubble babble (Tectia format) fingerprint of a keyfile.

-F Search for a specified hostname in a known_hosts file.

-R Remove all keys belonging to a hostname from a known_hosts file.

-y Read a private OpenSSH format file and print an OpenSSH public key to stdout.

This only listed the most commonly used options. For full usage, including the more exotic and special-purpose options, use the man ssh-keygen command.

32 Lives Keygen Not Working

We currently have a major issue using Microsoft Access Database Engine 2010. The engine comes in 64-bit and 32-bit forms, which is good. However, apparently you need to always install the 32-bit version if the host process is always 32-bit. Fine, we can do this.

Our software deals with a lot of legacy components that are 32-bit, and much of it is in VB6 code, which generates 32-bit assembly. So, we are under the assumption that the driver must also be installed as 32-bit. Indeed, when we install 32-bit drivers on a 64-bit machine, and run our 32-bit applications, it works correctly.

However, the problem begins when Office 2010 64-bit is installed on the system. Trust me, we've tried to educate users that 64-bit Office is largely unnecessary, to no avail. As computers come off the assembly line with 64-bit versions installed, we're unable to keep up with support requests when our software breaks something. Either the 64-bit Office breaks our installation, or our installation breaks their Office version, but it's not pretty either way. A further issue is that non-legacy software will sometimes install the 64-bit drivers (as they should), and the two versions simply do not coexist in any reasonable manner. Either our software breaks, or their software breaks.

So, has anybody managed to find a way to make the 32-bit drivers coexist with 64-bit installations? I have seen that installing with /passive flag allows the two to be installed, and our installer does use passive. Both are being installed, but once on the system either our software no longer works, or Office constantly repairs its installation. Is there any reasonable way to make this work?

drharrisdrharris

6 Answers

Here's a workaround for installing the 64-bit version of the Microsoft Access Database Engine 2010 redistributable on a system with a 32-bit MS Office version installed:

• Check the 64-bit registry key 'HKEY_LOCAL_MACHINESOFTWAREMicrosoftOffice14.0CommonFilesPaths' before installing the 64-bit version of the Microsoft Access Database Engine 2010 redistributable.
• If it does not contain the 'mso.dll' registry value, then you will need to rename or delete the value after installing the 64-bit version of the Microsoft Access Database Engine 2010 redistributable on a system with a 32-bit version of MS Office installed.
• Use the '/passive' command line parameter to install the redistributable, e.g. 'C:directory pathAccessDatabaseEngine_x64.exe' /passive
• Delete or rename the 'mso.dll' registry value, which contains the path to the 64-bit version of MSO.DLL (and should not be used by 32-bit MS Office versions).

Now you can start a 32-bit MS Office application without the 're-configuring' issue.Note that the 'mso.dll' registry value will already be present if a 64-bit version of MS Office is installed. In this case the value should not be deleted or renamed.

Also if you do not want to use the '/passive' command line parameter you can edit the AceRedist.msi file to remove the MS Office architecture check:

• download and install Microsoft Orca:http://msdn.microsoft.com/en-us/library/windows/desktop/aa370557(v=vs.85).aspx
• unzip the AccessDatabaseEngine.exe or AccessDatabaseEngine_x64.exe file
• open the AceRedist.msi file in Orca
• search for two table rows containing the 'CheckOfficeArchitecture' action and drop these rows
• save the updated AceRedist.msi file

You can now use this file to install the Microsoft Access Database Engine 2010 redistributable on a system where a 'conflicting' version of MS Office is installed (e.g. 64-bit version on system with 32-bit MS Office version)Make sure that you rename the 'mso.dll' registry value as explained above (if needed).

I hate to answer my own questions, but I did finally find a solution that actually works (using socket communication between services may fix the problem, but it creates even more problems). Since our database is legacy, it merely required Microsoft.ACE.OLEDB.12.0 in the connection string. It turns out that this was also included in Office 2007 (and MSDE 2007), where there is only a 32-bit version available. So, instead of installing MSDE 2010 32-bit, we install MSDE 2007, and it works just fine. Documents in world history pdf. Other applications can then install 64-bit MSDE 2010 (or 64-bit Office 2010), and it does not conflict with our application.

Thus far, it appears this is an acceptable solution for all Windows OS environments.

drharrisdrharris

I had a more specifc error message that stated to remove 'Office 16 Click-to-Run Extensibility Component'

I fixed it by following the steps in https://www.tecklyfe.com/fix-for-microsoft-office-setup-error-please-uninstall-all-32-bit-office-programs-office-15-click-to-run-extensibility-component/

• Go to Start > Run (or Winkey + R)
• Type “installer” (that opens the %windir%installer folder), make sure all files are visible in Windows (Folder Settings)
• Add the column “Subject” (and make it at least 400 pixels wide) – Right click on the column headers, click More, then find Subject
• Sort on the Subject column and scroll down until you locate the name mentioned in your error screen (“Office 16 Click-to-Run Extensibility Component”)
• Right click the MSI and choose uninstall

Install the 2007 version, it seems that if you install the version opposite to the version of Office you are using you can make it work.

Matthew DolmanMatthew Dolman

A similar approach to @Peter Coppins answer. This, I think, is a bit easier and doesn't require the use of the Orca utility:

1. Check the 'HKEY_LOCAL_MACHINESOFTWAREMicrosoftOffice14.0CommonFilesPaths' registry key and make sure the value 'mso.dll' is NOT present. If it is present, then Office 64-bit seems to be installed and you should not need this workaround.

2. Download the Microsoft Access Database Engine 2010 Redistributable.

3. From the command line, run: AccessDatabaseEngine_x64.exe /passive

(Note: this installer silently crashed or failed for me, so I unzipped the components and ran: AceRedist.msi /passive and that installed fine. Maybe a Windows 10 thing.)

4. Delete or rename the 'mso.dll' value in the 'HKEY_LOCAL_MACHINESOFTWAREMicrosoftOffice14.0CommonFilesPaths' key.

Source: How to install 64-bit Microsoft Database Drivers alongside 32-bit Microsoft Office

JahmicJahmic

If both versions of Microsoft Access Database Engine 2010 can't coexists, then your only solution is to complain to Microsoft, regarding loading 64 bits versions of this in your 32 bits app is impossible directly, what you can do is a service that runs in 64 bits that comunicates with another 32 bits service or your application via pipes or networks sockets, but it may require a significant effort.

RafaelRafael

Not the answer you're looking for? Browse other questions tagged 32bit-64bitinstallshieldlegacymsde or ask your own question.