Ssh-keygen Ecdsa-sha2-nistp256

[Zulema Estabrooks]

Onthe client you can SSH to the host and if and when you see that same number, you can answer the prompt Are you sure you want to continue connecting (yes/no)? affirmatively. Then the ECDSA key will get recorded on the client for future use.

And look for the 2 lines like "host key algorithms: ..." where the first appears to be the server's offer, and the 2nd is the client's. Or to pick out those 2 lines automatically, try this (and to exit hit ctrl+d):

some points are confusing as to is it possible to remove key algorithms from existing defaults - Highest level keys are New RSA-sha2/256/512 and ed25519 keys for best security using ssh-keygen -t ras -a -b 4096 -a 113 to gen. Legacy support is apparently reading ssh news that ssh1 will be totally gone - its 45bit and 96 bit max - dsa keys also depreciated also be eliminated. Its fixed on 128/1024 bit max found hackable. (poss NSA did that and lame/excuse as debug code left in- highly doubt that naming it heartbleed) so all high cost paying secure RSA key structures have to be reworked to support and keep higher standards going forward. set what keys you wish to use as described in /etc/ssh/sshd_config try doing 2 key auth 3 key works too ie: sshd_config "AuthenticationMethods publickey,publickey,publickey"- make sure ssh -Q kex listings match both A and B servers or desktops as example poss do a diff on their output - and make sure same key exhng algorithms match. ecdsa keys newer in production are also kina weak sugg not to use. or get - keyexchange refused partial access secure msg. Lots of good infoz just patient to search it.

I've found this answer, which is fine for RSA and DSS:Using public key from authorized_keys with Java security, and this discussion of the openssh format for ECDSA: -why-do-ssh-keygen-and-java-generated-public-keys-have-different-sizes

However I'm getting lost trying to adapt the RSS/DSA code for ECDSA - I'm not sure how to set up an ECPublicKeySpec. It needs ECPoint, EllipticCurve, ECParameterSpec, ECField. The openssh format only contains two integers, which makes sense for ECPoint, but I don't know how to set up the rest.

Adapting the code from Using public key from authorized_keys with Java security, and refering to RFC 5656, section 3.1, the following block added to decodePublicKey will parse the single BigInt value Q, which is "the public key encoded from an elliptic curve point":

For completeness, here's the code I've gone with. It's nearly-pure JCE, with a sprinkling of Bouncycastle inside helper methods (this updates the example code in Using public key from authorized_keys with Java security):

Currently, Bitbucket Cloud does not yet support the sk-ecdsa-sh...@openssh.com key format, and this is the reason why you are receiving the error message when trying to add a key with this type.

Please consider this post as a request for adding this functionality. Secure keys have been around a long time, it's a bit sad bitbucket is the only provider to miss this. (don't worry though, Microsoft has not caught up either)

I would suggest you to add your vote there, since this helps both developers and product managers to understand the interest. Also, make sure you add yourself as a watcher in case you want to receive first-hand updates from that ticket. Please note that all features are implemented with this policy in mind.

When doing ssh -v example.com I can see debug1: Server host key: ecdsa-sha2-nistp256 SHA256:..., but this is not the same as the ssh-rsa key eventually stored in known_hosts after correcting the problem.

One pretty easy way is to use ssh-keyscan. This command will request keys from the remote server. For example if I wanted the rsa, ecdsa, and ed25519 host keys from demo.example.org I might use this command.

Host keys are generally found under /etc/ssh/ on the server you are trying to connect to. The server host key string printed in the verbose output is simply the fingerprint of the server's public key, not the actual key itself.

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,

Already remove keys but not succeed (stop ssh then restart ssh again) then uninstall then install open ssh again but still not succeed. known_hosts both user and root is emty but connection is not still possible.(ecdsa-sha2-nistp256 host key mismatch for 192.168.4.61 !)

In this section, you can find information about SSH keys, including how to generate them and how to rotate them. For details about using Transfer Family with AWS Lambda to manage keys, see the blog post Enabling user self-service key management with AAWS Transfer Family and AWS Lambda.

You can set up your server to authenticate users using the service managed authentication method, where usernames and SSH keys are stored within the service. The user's public SSH key is uploaded to the server as a user's property. This key is used by the server as part of a standard key-based authentication process. Each user can have multiple public SSH keys on file with an individual server. For limits on number of keys that can be stored per user, see AWS Transfer Family endpoints and quotas in the Amazon Web Services General Reference.

As an alternative to the service managed authentication method, you can authenticate users using a custom identity provider, or AWS Directory Service for Microsoft Active Directory. For more information, see Working with custom identity providers or Using AWS Directory Service for Microsoft Active Directory.

In the following examples, we do not specify a passphrase: in this case, the tool asks you to enter your passphrase and then repeat it to verify. Creating a passphrase offers better protection for your private key, and might also improve overall system security. You cannot recover your passphrase: if you forget it, you must create a new key.

However, if you are generating a server host key, you must specify an empty passphrase, by specifying the -N "" option in the command (or by pressing Enter twice when prompted), because Transfer Family servers cannot request a password at start-up.

Your SSH key pair is now ready to use. Follow steps 3 and 4 to store the SSH public key for your service-managed users. These users use the keys when they transfer files on Transfer Family server endpoints.

Windows uses a slightly different SSH key pair format. The public key must be in the PUB format, and the private key must be in the PPK format. On Windows, you can use PuTTYgen to create an SSH key pair in the appropriate formats. You can also use PuTTYgen to convert a private key generated using ssh-keygen to a .ppk file.

For security, we recommend the best practice of rotating your SSH keys. Usually, this rotation is specified as a part of a security policy and is implemented in some automated fashion. Depending upon the level of security, for a highly sensitive communication, an SSH key pair might be used only once. Doing this eliminates any risk due to stored keys. However, it is much more common to store SSH credentials for a period of time and set an interval that doesn't place undue burden on users. A time interval of three months is common.

Using the API, you can update existing users by using the DeleteSshPublicKey API to delete a user's Secure Shell (SSH) public key and the ImportSshPublicKey API to add a new Secure Shell (SSH) public key to the user's account.

Retrieve the SSH key that you want to delete by entering the following command. To use this command, replace serverID with the server ID for your Transfer Family server, and replace username with your username.

Next, import a new SSH key for your user. At the prompt, enter the following command. To use this command, replace serverID with the server ID for your Transfer Family server, replace username with your username, and replace public-key with the fingerprint of your new public key.

Finally, delete the old key by running the following command. To use this command, replace serverID with the server ID for your Transfer Family server, replace username with your username, and replace keyID-from-step-2 with the key ID value that you copied in step 2 of this procedure

The AWS storage blog has a post that describes how to simply decrypt files without writing any code using Transfer Family Managed workflows, Encrypt and decrypt files with PGP and AWS Transfer Family.

If you're using GnuPG version 2.3.0 or newer, you must run gpg --full-gen-key. When prompted for the type of key to create, choose RSA or ECC. However, if you choose ECC, make sure to choose either NIST or BrainPool for the elliptic curve. Do not choose Curve 25519.

If you want to use one key and passphrase for all of your users, you can store the PGP key block information under the secret name aws/transfer/server-id/@pgp-default, where server-id is the ID for your Transfer Family server. Transfer Family uses this default key if there is no key where the user-name matches the user that's executing the workflow.

3a8082e126