Ssh-keygen Sha-1

[Arlyne Doepner]

It seems like this should be easy. I run "ssh-keygen -l -f " (the default seems to be SHA1). All of the examples show it printing the hex-formatted digest with a little extra, harmless information. Yet, on my Mac I'm getting a useless, opaque string.

UPDATE: this answer is about OpenSSH fingerprints. Per comment from the OP the actual problem was apparently AWS fingerprints, which at the time I didn't know are different; for that see Why does my OpenSSH key fingerprint not match the AWS EC2 console keypair fingerprint? and -key-pair-into-amazon-aws-wrong-fingerprint and probably more.

Traditionally OpenSSH displayed (public) key fingerprints using MD5 in hex, or optionally as 'ASCII art' or 'bubblebabble' (a series of nonsense but pronounceable 5-letter quasiwords); 6.8 in March 2015 added options for SHA1 and SHA256 in (PEMstyle) base64, with the latter now the default, and in all three cases the hash name prefixed so you know which it is. ssh-keygen -l has -E option only since then, and Ubuntu 14.04 dates from before March 2015.

You should not need a SHA1 digest in hex for verifying a host, since ssh client never displays that, only MD5-hex or SHA1-base64 (not by default) or SHA256-base64. If you want one anyway, you can do it fairly easily except for an 'rsa1' key and you should have stopped using SSHv1 protocol and thus rsa1 keys before Barack Obama became US President.

and convert it from base64 to binary, hash that with the desired hash and display in the desired representation. Since openssl by default displays hashes in hex, and can convert from (and to) base64, you could do something like

Note the -A; otherwise openssl (depending on version) may silently fail to decode base64 longerthan 76 characters -- and OpenSSH pubkey blobs except ed25519 are longer. (Thanx Bernhard Wagner for catching a bug -- and drawing my attention back to this old answer so I could add the scope fix above.)

Up until last week I was running Ubuntu 20.04 happily, and then over the weekend decided to back everything up and install 22.04. I've had a couple of teething issues which I've solver, however I'm having real issues with SSH. I have two first generation WD MyCloud drives which handle all my backups and files both on and away from home. I can still connect to the shares with no problems, however I need to SSH onto both drives in order to run maintenance, backup between cloud drives, etc.

However with Ubuntu 20.04 I had set up a passphrase so that various autyomated scripts that I use using rsync could copy between cloud drives and also between Ubuntu and the cloud drive shares. This was working until I upgraded, now the scripts continually ask me for my password and I can't figure out how to stop it.

I know this is going to be due to my cloud drives only supporting the now insecure SSH, but I cannot upgrade it to a more secure one (unless someone knows how - I would prefer to do this to be honest). My maintenance scripts can make up to 20 connections over a period of hours, and to have to sit and constantly enter the password is becoming a pain.

How this originally came about was that I needed to be able to rsync to and from a remote location without the need for a human intervention regarding security. The instructions I was given were to use ssh-keygen to generate public/private keys and then ssh-copy-id to copy the public key to the remote host. I've just reinstalled 20.04 on another machine and used this successfully and the rsync is working without the need for a password. However if I clear the keys on the server out, reinstall 22.04 and do the same, it still prompts me for the password. I've updated my question to show the output of the commands as they are being run on Ubuntu 22.04 with the server name obscured for obvious reasons.

The RSA SHA-1 hash algorithm is being quickly deprecated across operating systems and SSH clients because of various security vulnerabilities, with many of these technologies now outright denying the use of this algorithm.

Note: the string after -C is a comment it is customary to put your email address here. Since you may only be using this key within your home, putting the email address may not make sense. I would put something like "colin@colin-desktop" so that you know which user and computer the key belongs to within your household.

If you can't change anything on the local computer, or don't want to use a new key, and want to re-enable RSA on the local computer, edit the file /etc/ssh/sshd_config on the remote computer and add this line:

Notice I had to add KexAlgorithms and HostKeyAlgorithms keywords with relevant parameters along with suggested by user68186 PubkeyAcceptedKeyTypes which was not enough. This is with Ubuntu 22.04 OpenSSH v8.9...

Thanks, Greg. That is our standard banner for accessing any system in our organization. I will double check to see if there have been any SSH settings applied that would be interfering with the ed25519 keys. If I figure anything out, I will post back here.

@gitlab-greg I figured out what the issue is. There are several factors but the biggest one is the fact that we have to run our servers in FIPS mode. According to my searching, FIPS mode does not allow for ED25519 keys presently when using OpenSSH on a Red Hat Enterprise Linux (RHEL) system. We have the Omnibus installed on RHEL 7 and when I try to run ssh-keygen and specify ED25519 as the format, I get an error message indicating that ED25519 keys are not supported. I found this GitLab issue that backs this up:

So, bottom line is that we cannot use ED25519 keys until we update/upgrade our system to a newer version of RHEL/OpenSSH that implements a later FIPS standard. It appears that FIPS may soon include ED25519 as an approved cryptographic algorithm. While we wait that, we will use RSA keys, which are working fine.

@gitlab-greg
Hey Greg,
I hope this finds you well,
I have a probably very simple problem, but I cannot figure it out by myself, so please take a look at the logs and help me find the problem,

With my new Linux machine, I am using the web version of Duplicacy successfully to back up to remote B2 buckets. However, trying to add the same SFTP folder that previously worked gives the following error:

Thankfully I can run remote commands without ssh enabled via ACP commander, so I could get myself back in with a little bit of sed surgery. I realise that I should probably be regenerating keys, but ssh-keygen -A returns

Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

When attempting to use an SSH key generated using the ssh-rsa sha-1 hash algorithm, the SSH key isn't accepted (the user receives a 'Permission denied' message), and the following message is displayed when the verbose SSH output is reviewed:

In the event that you are using an operating system or SSH client whose version has this algorithm disabled, it's possible that any SSH keys previously generated using this algorithm will no longer be accepted by these technologies.

It is important to note that by default Bitbucket offers support for ECDSA and ED25519 algorithm. Keys generated with these algorithms are not affected by RSA deprecation.

As detailed in BSERV-13013 ticket linked below, the our dev team implemented RFC 8332 so that the use of RSA-based keys can continue with SHA-256 and SHA-512 instead of SHA-1. Please review the Workarounds section from the following report before proceeding.

For OpenSSH's ssh-keygen command in particular, the full list of algorithms for this command can be found on SSH.com: choosing an algorithm. In addition, here is an example command that creates a new SSH key using the ED25519 algorithm:

The OpenSSH server reads a configuration file when it is started. Usually, this file is /etc/ssh/sshd_config, but the location can be changed using the -f command line option when starting sshd. Some organizations run multiple SSH servers at different port numbers, specifying a different configuration file for each server using this option.

The default values for certain configuration options in OpenSSH are quite restrictive and often need to be changed. Usually this is done by editing the default configuration file to change just a few options.

The SSH server actually reads several configuration files. The sshd_config file specifies the locations of one or more host key files (mandatory) and the location of authorized_keys files for users. It may also refer to a number of other files.

Many individual developers and power users wish to maximize their convenience rather than go for maximum security. For such use, we recommend the following settings for homes, development servers, and universities. For important systems even such organizations should follow the guidelines for configuring enterprise servers.

Symmetric algorithms for encrypting the bulk of transferred data are configured using the Ciphers option. A good value is aes128-ctr,aes192-ctr,aes256-ctr. This should also provide good interoperability.

Key exchange algorithms are selected by the KexAlgorithms option. We recommend ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha256. In particular, we do not recommend allowing diffie-hellman-group1-sha1, unless needed for compatibility. It uses a 768 bit prime number, which is too small by today's standards and may be breakable by intelligence agencies in real time. Using it could expose connections to man-in-the-middle attacks when faced with such adversaries.

We have included the sha-1 algorithm in the above sets only for compatibility. Its use is questionable from a security perspective. If it is not needed for compatibility, we recommend disabling it. NIST has also issued guidance on it.

Some organizations may also want to set policy for PubkeyAcceptedKeyTypes. Same value as for HostKeyAlgorithms would make sense. However, restricting this value could abruptly break business-critical connections, and we recommend only setting it after analyzing all existing authorized keys for the algorithms they use.

c80f0f1006