145

AWS EC2 shows the SSH2 fingerprint, not the OpenSSH fingerprint everyone expects. It doesn't say this in the UI. It also shows two completely different kinds of fingerprints depending on whether the key was generated on AWS and downloaded, or whether you uploaded your own public key. Fingerprints generated with ssh-keygen -l -f id_rsa will not match what ...


137

This field is a comment, and can be changed or ignored at will. It is set to user@host by default by ssh-keygen. The OpenSSH sshd(8) man page describes the format of a public key thus: Public keys consist of the following space-separated fields: options, keytype, base64-encoded key, comment. . . . The comment field is not used for anything (but may be ...


91

Necromancing, but adding the following to your sshd_config should do the trick: Match User <username> PasswordAuthentication yes Match all Note that match is effective "until either another Match line or the end of the file." (The indentation isn't significant.)


54

This is briefly explained in manual page for sshd(8) in section about authorized keys: Protocol 2 public key consist of: options, keytype, base64-encoded key, comment. In openssh context of authorized keys, there is only meaning of comment. But there are SSH implementation, that give the meanings to this part, as for example SSH implementation in LANCOM ...


45

The known_hosts file contains the trusted public keys for hosts you connected to in the past. These public keys can be obtained simply by trying to connect to these hosts. Therefore it is no security risk per se. But: It contains a history of hosts you connected to. The information may be used by a potential attacker to footprint organization infrastructure ...


40

According to an older* ssh-config(5) man page, ssh will always try all keys known by the agent in addition to any Identity Files: IdentitiesOnly Specifies that ssh(1) should only use the authentication identity files configured in the ssh_config files, even if ssh-agent(1) offers more identities. The argument to this keyword ...


40

You can pass ssh options with -o: ssh-copy-id -i mykey.rsa.pub -o "IdentityFile hostkey.rsa" user@target


37

The customer is wrong here and does not understand what they're talking about. Changing the passphrase on a private key is a very bad idea, because it has very counter-intuitive security properties. Normally, users think of passwords that they have changed as "no longer secret". They might become throwaway passwords for low-value sites, online handles/...


35

It already is. :) Just put ".keys" on the end of your Github profile URL, like so: https://github.com/tjmcewan.keys


33

You could use Azure CLI to upload id_rsa to Azure Key Vault. azure keyvault secret set --name shui --vault-name shui --file ~/.ssh/id_rsa You could use -h to get help. --file <file-name> the file that contains the secret value to be uploaded; cannot be used along with the --value or --json-value flag You could also download secret ...


31

If you want to bypass key authentication when logging to the server, just run: ssh -o PubkeyAuthentication=no user@host


30

You actually need to login to copy your key, you don't have any access to the remote machine (invalid key and password authentication disabled): Re-enable passwd authentication in /etc/ssh/sshd_config: PasswordAuthentication yes Then restart the service: service sshd restart Copy your public key: ssh-copy-id -i ~/.ssh/id_rsa.pub USER@HOST -p PORT [...


29

The "channel 2" and "channel 3" lines are from ssh. The sshd instance on the remote server is trying to connect to host.com port 27017 in order to service a tunnel connection, and it's getting a "connection timed out" error. In other words, sshd on the remote server can't reach the target of the tunnel. Since the remote host is also the host which you're ...


29

OpenSSH 7.6 has introduced new StrictHostKeyChecking=accept-new setting for exactly this purpose: ssh(1): expand the StrictHostKeyChecking option with two new settings. The first "accept-new" will automatically accept hitherto-unseen keys but will refuse connections for changed or invalid hostkeys. This is a safer subset of the current behaviour ...


28

After I was able to ssh via Google web console, I did the following steps to resolve this: Generate ssh key using ssh-keygen Copy the key.pub file contents Append the contents to ~/.ssh/authorized_keys file sudo nano ~/.ssh/authorized_keys


27

Add EC2 pem key to SSH ssh-add ~/.ssh/KEY_PAIR_NAME.pem


27

RSA is specifically designed to allow you to share that public key, so yes, you can publish it. This is pretty similar to how x.509 (and SSL) with RSA certificates works. Before publishing the file, actually look at it; the only things that need to be in there are the keyword "ssh-rsa" and the base64-encoded key. You may want to keep it to that (I believe ...


26

AWS EC2's key management does not cope with SSH private keys that have passwords set (are encrypted). It doesn't detect this, and simply fails with an uninformative error. If your private key is stored encrypted on disk (like it should be, IMO) you must decrypt it to paste it into AWS's console. Rather than doing that, consider decrypting the password ...


23

It is exactly as you say: The whole concept of public key authentication is that the private key should only be known to the owner, while the corresponding public key can be widely disseminated. The security of your authentication depends on the security of the private key, not of the security of the public key. The fact that somebody else provides you ...


23

That's too complicated (checking if a key has access to a specific prod server). Use the gateway server as jump host that accepts every valid key (but can easily remove access for a specific key which removes access to all servers in turn) and then add only the allowed keys to each respective server. After that, make sure you can reach the SSH port of every ...


22

Congratulations, you've found an Internet tutorial with bad advice. The problem with using a single keypair for multiple computers occurs when any one of the computers is compromised. Then you have no choice but to revoke the keypair everywhere and rekey every single computer which was using that keypair. You should always use unique keypairs per machine ...


22

There are a few ways of fixing this: You can disable host key checking for this particular host. In your ssh_config file (~/.ssh/config), put something like: Host remote.host.name UserKnownHostsFile /dev/null StrictHostkeyChecking no This configures ssh to never store host keys for remote.host.name, but the downside is that now you are open to man-in-the-...


21

If you only have public keys, you can generate the AWS fingerprint as follows: ssh-keygen -e -f id_rsa.pub -m pkcs8 | openssl pkey -pubin -outform der | openssl md5 -c


21

As far as I know the only reason why you would need to pipe a 'y' to ssh-keygen, is if your command is replacing an existing file. In my opinion this is not a good way to do something from a configuration management tool. You should adjust your tasks to make them idempotent. Specifically if you add the creates: filename to your command, then the new keys ...


20

These answers didn't help me out. I really didn't need any crazy scripts. I had created a public key on my client machine in git bash and was trying to copy it to a VPS. After creating your public key, the key should be stored as "(whatever folder you started in)/.ssh/id_rsa.pub" So use this command: cat ~/.ssh/id_rsa.pub | ssh user@123.45.67.89 "cat >&...


20

The simple answer is: You don't. SSH keys and GnuPG (actually, OpenPGP) keys are completely different, even though both protocols can use RSA key pairs. And besides, why would you want to do it? Even if you were to use the same key material to make up your PGP key, you'd still need to distribute your key as a PGP key. You likely haven't been distributing ...


20

There is an accepted answer for this question, but I think it's worth noting that there is a way to do this using the ssh-keygen tool rather than sed: ssh-keygen -i -f ssh2.pub > openssh.pub Where ssh2.pub is your existing ssh2 key and openssh.pub will be the key in openssh format. If you just want to copy and paste you can leave out the redirect and ...


19

That is the default location. You can use AuthorizedKeysFile to change to a different location, but if you don't specify it, then it will look in ~/.ssh/authorized_keys From the man page (e.g., https://www.freebsd.org/cgi/man.cgi?query=sshd_config&sektion=5): AuthorizedKeysFile Specifies the file that contains the public keys that can be used ...


19

You can if you really want, but I wouldn't bother regenerating 2048-bit DH parameters for OpenSSH. There are much more important things you need to do to secure SSH, like disabling weak crypto. What I would do is delete the existing ones which are less than 2048 bits. awk '$5 >= 2000' /etc/ssh/moduli > /etc/ssh/moduli.strong && \ mv /etc/ssh/...


19

Remove the BEGIN and END lines Optionally remove the Comment line (you can keep note of this if you want to add it as a comment later) Remove all remaining line-breaks Add the text "ssh-rsa" to the start of the line The key now becomes: ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEApoYJFnGDNis/2oCT6/h9Lzz2y0BVHLv8joXMs4SYcYUVwBxNzqJsDWbikBn/h32AC36qAW24Bft+...


Only top voted, non community-wiki answers of a minimum length are eligible