Ssh – Azure VM key fingerprint

azureazure-networkingsshvirtual-machines

I just created an Ubuntu VM on Azure. It says to use ssh to connect to the VM. When I try to SSH for the first time from the command line, it asks to verify ECDSA key fingerprint, but I cannot see it anywhere in the Azure Portal, whether it is the correct one of the machine I created.

Any help to find in Azure Portal would be much appreciated. Thanks.

Best Answer

it asks to verify ECDSA key fingerprint, but I cannot see it anywhere in the Azure Portal,

It is a by design behavior, just enter your password to login.

like this:

The authenticity of host 'HOST NUMBER DELETED)' can't be established.
RSA key fingerprint is 'blah blah blah blah blah blah blah'.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'myiphost' (RSA) to the list of known hosts.
root@myiphost's password: your_password

Update:

Here is my test:

VM1: jasoncli
VM2: jasonubuntu

I am try to use VM1 to SSH VM2, after SSH completed, Linux will record the target server's(VM2) host key to VM1 known_hosts, like this:

[root@jasoncli@jasonye ssh]# cat ~/.ssh/known_hosts 
10.168.172.115 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBPeJQ8c7h002Flqu18aVYpUf+6HmXUS5UbMV7usyrrOUPyAMZcYBuek/DhEG2HmNAH0qLGurHdV66QCxM8oee1k=

We can find VM2's host key here:

root@jasonubuntu:/etc/ssh# cat ssh_host_ecdsa_key.pub 
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBPeJQ8c7h002Flqu18aVYpUf+6HmXUS5UbMV7usyrrOUPyAMZcYBuek/DhEG2HmNAH0qLGurHdV66QCxM8oee1k= root@jasonubuntu
root@jasonubuntu:/etc/ssh# pwd
/etc/ssh

In this way, Linux will check the key to make sure the server is actually that server you are want to connect.

Update3:

For now, Azure does not support use console to connect to Azure VM. To get the ssh_host_ecdsa_key.pub, we can use custom script extension via Azure portal, like this:

Here is the script.sh:

cat /etc/ssh/ssh_host_ecdsa_key.pub

We can find the result in Azure portal:

Related Solutions

Amazon EC2 – Understanding SSH RSA Fingerprint

You can verify the fingerprint using the AWS console for instances with cloud-init.

The following is on an instance running Amazon Linux.

There is a init.d script called cloud-init:

cloud-init is the distribution-agnostic package that handles early initialization of a cloud instance.

Some of the things it configures are:

setting a default locale

setting hostname

generate ssh private keys

adding ssh keys to user's .ssh/authorized_keys so they can log in

setting up ephemeral mount points

preparing package repositories and performs a variety of at-boot customization actions based on user-data

Once you launch an instance, you can view the system log output via the AWS console without using SSH. (Which avoids your catch-22 - you can see the fingerprint before you access the instance).

You can do this by

going to your EC2 Management Console page,
clicking the "Instances" link on the sidebar,
selecting the instance you want to log into, and
navigating to Actions > Instance Settings > Get System Log.

Get System Log

If you scroll through that output, you will see something like the following:

Running cloud-init
...

cloud-init:  sshGenerating public/private rsa key pair.
Your identification has been saved in /etc/ssh/ssh_host_rsa_key.
Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub.
The key fingerprint is:
aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa root@example.com
The key's randomart image is:
+--[ RSA 2048]----+
|       aa        |
|  a    a         |
|     aa   a   a  |
|  a    aaa       |
|     aaaaa   a   |
| a   a aa        |
|aaaa   a  aa     |
|aaaaaa     a     |
| aa      a       |
+-----------------+
Generating public/private dsa key pair.
Your identification has been saved in /etc/ssh/ssh_host_dsa_key.
Your public key has been saved in /etc/ssh/ssh_host_dsa_key.pub.
The key fingerprint is:
bb:bb:bb:bb:bb:bb:bb:bb:bb:bb:bb:bb:bb:bb:bb:bb root@example.com
The key's randomart image is:
+--[ DSA 1024]----+
|                 |
|                 |
|                 |
|       b  b      |
|        b     b  |
|    b    b b     |
|  bb b bb        |
| b  bbb bb    b  |
|  bbbb   bbb     |
+-----------------+
ec2: 
ec2: #############################################################
ec2: -----BEGIN SSH HOST KEY FINGERPRINTS-----
ec2: 2048 aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa  root@example.com (RSA)
ec2: 1024 bb:bb:bb:bb:bb:bb:bb:bb:bb:bb:bb:bb:bb:bb:bb:bb  root@example.com (DSA)
ec2: -----END SSH HOST KEY FINGERPRINTS-----
ec2: #############################################################
[  OK  ]

System Log Output

Above each "randomart" image is the type of signature, such as RSA or DSA. Find the kind you are given (RSA in your case), and check the fingerprint above it.

If you wish to verify that the same key is the one on the instance (as a proof of concept, after you have SSH'd in), you can run:

ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub
2048 aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa  root@example.com (RSA)

Alternate Approach:

In order to avoid the problem, you can use your own keys - since you generated the key, you know the fingerprint. The issue then becomes one of getting your new key onto the instance without using SSH.

Most instances use cloud-init and will support user-data. This applies to any such instance. Since you need to stop an instance in order to modify user-data, this approach requires that you either are a: launching an instance for the first time (and are setting yourself up to use known keys) or b: can stop the instance, modify the user-data, and restart the instance.

Generate a key For example, using PuttyGen on Windows:

Create a user-data script:

If you are launching a new instance, you just need to specify the keys you want to use, if you are restarting an instance that is already running, you need to have cloud-init reconfigure SSH to pull in the new keys. By default, the SSH config module of cloud-init is run once per instance, so you need to set it to run always (each boot) (This might not be ideal in some circumstances, but can be modified after you know the key, if required)

The user-data would take the following form:

#cloud-config
cloud_config_modules: #only needed if restarting an instance, omit if launching a new instance
  ...list all existing modules
  - [ssh, always]  #this is changed to always (default is once per instance)

ssh_keys:
  rsa_private: |
    -----BEGIN RSA PRIVATE KEY-----
    -----END RSA PRIVATE KEY-----

    ssh-rsa #public_key

For example:

#cloud-config
cloud_config_modules:
  - locale
  - [ssh, always]
  - set-passwords
  - mounts
  - yum-configure
  - yum-add-repo
  - package-update-upgrade-install
  - timezone
  - puppet
  - disable-ec2-metadata
  - runcmd

ssh_keys: #you can specify rsa, dsa, and ecdsa keys
  rsa_private: |
    -----BEGIN RSA PRIVATE KEY-----
    MIIEoQIBAAKCAQEAopbE8beKaKajF/SFOtntO9xt5XVZW5rlQCW6PVY1jXCq5dbj
    nEQoBGBIp6jsqLcnwYQW/tU4zXi7T0kX6NlVywiMOtjnyoOkLCX2R5OjMap3hlyj
    AO/PCKW7pE4vAHd7HyYvGW/gPezGW0WeFshp7J7dTXZdSmDquZI15rEsz07QsKWy
    /SH/rjYVObAQJN78CuU7C41LRshEeTSBM0jBSnp3jL1Ocw66qe4sV6jbcQN6QzK3
    77e+KzpUDmcxaB7plTWDSpjxVFWbY6PQcsz5d/h60wSKu90Ia9fNMHWs7cbyELhK
    VPBRs4JtWKndjtISCd5T34UnKmtTpq6g/ocrrwIBJQKCAQB7Ck/Zg/oKAZAtzcyb
    PSI7I1oVbY+68cI+Yb1e2XSiYxmLVoK7cdkYEYMXGA0KDhA/auD4MqeGvDq4ildI
    bR5UdSvZgYzQmvjHdqyJMXSUSaaPMVjCcEmlrdobeW+tU3/Ei5lDrpvb1caKQoV5
    Bl3/LB0YBovJlXNb//FwTrogVhYFexcda+DxN5a2oNSCwMosdgCP4gz+hX9zTAl9
    k/VOkLaj2h7URfsuAmwwZ+m24Bpz1r7vEtec0PraoKkBpVxBeNDPwMdosTrpGS49
    V+YRRiM8yShuRPF9mAwo62kcD7K5bToppyb6CLdCi06CTcAmQ5Sb+UwHqC/rdZI0
    wmnNAoGBAPxj6ecjM0AwrPf2TPJOtdEUHvFnc6bB23C32Yr7IWjNhij0BGG/D8Cv
    smCXDwYDH7Ss4CN/mMzG43QhfyyAz0T0BjpFmZEYqYOJAB7cwpdx4zjHzoc7WKiI
    vXPml2hdd37iVRNq6raUgDLpKfVkpY8FKcJjzFuiCXDOU1+mNxPbAoGBAKTqD/+X
    oDGsf6hkV7vgPLIXc3/BZco0l9kNkemto9RVIsr3D40bfe4PuJg3fjwFYDTq9s79
    WFR5sG/eSpNJtSGTz6LN5TQoL5xLMCIysajc+JN64w4TYCDGSEk4Xgv0X0cCgJfF
    RCedv9qObGT9/KCI/9Y/5jlZsVphNsAk4Xm9AoGBAKO2bjUP6eRymbWY1/ceTGvx
    YC3iPS3lh2u1hjCi5T0PsPf4OjGQsEWiZd3JxI5HNykWMIW6jKCBAj19guxvOlY9
    a9LFXLEkwPtfyLoSp7wuMoWyCWx5hZ3AeuNlI/CrVG36mAyYYOUiDfeCfBTLqajg
    wSQlDu9UWSaTq7OqFeNdAoGAFkkkway0yHFBrvjNle3esEhbt1F8dUVgoMp7gHFp
    KogLnuMdxvXglcrF6w5rATEorTSCN6Wx/ZPnaRAzl1z8zS+mb/JPZ+nBPqJgc1L1
    adir+EEJ7SU2gPgzSCo2OPeCfzewgzZVUXYurtT55CJSkjwG5Znurc3ZskR9BTVq
    k+kCgYARZXWS0Wyy5piq7WX7w2Hc6bVEPMCU+yJcbJ8E+F8meoQ1kXIRqIB+cAsq
    /3z3JmU19yOGms557POXgEFseMMFai3i2wTQ4mGPOM3a7yEeeKl1Zg5eHVUdVd+n
    PDzs9D+9umc6mXrRiRwJPQWo8pIKXb7SqjIA73M7H+98CBtb5w==
    -----END RSA PRIVATE KEY-----

    ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAopbE8beKaKajF/SFOtntO9xt5XVZW5rlQCW6PVY1jXCq5dbjnEQoBGBIp6jsqLcnwYQW/tU4zXi7T0kX6NlVywiMOtjnyoOkLCX2R5OjMap3hlyjAO/PCKW7pE4vAHd7HyYvGW/gPezGW0WeFshp7J7dTXZdSmDquZI15rEsz07QsKWy/SH/rjYVObAQJN78CuU7C41LRshEeTSBM0jBSnp3jL1Ocw66qe4sV6jbcQN6QzK377e+KzpUDmcxaB7plTWDSpjxVFWbY6PQcsz5d/h60wSKu90Ia9fNMHWs7cbyELhKVPBRs4JtWKndjtISCd5T34UnKmtTpq6g/ocrrw== rsa-key-20140716

Stop your instance and modify the user-data:

Start the instance, and connect to it:
Note that the fingerprint shown here matches the one displayed when the key was generated.

If you are stopping the instance and have access to another instance, you can also mount the root volume and modify the keys directly without using user-data (the keys will not be overwritten since cloud-init only runs SSH config once per instance by default). An alternate approach, if you are planning ahead, is to setup cloud-init (or an init script) to log the SSH keys each boot, which increases the probability you will find them in the console log after a restart.

SSH key stopped working on Ubuntu Azure VPS

I realize my mistake. Thanks @kasperd for helping me figure it out. I followed Azure's SSH creation instructions to the letter. When I generated my key, I used this command

openssl req -x509 -key ~/.ssh/id_rsa -nodes -days 365 -newkey rsa:2048 -out myCert.pem

which generates a new key that expires after 365 days. It just so happens that yesterday was that 365th day which means my key no longer works. Since that was the only key to the VM I guess I'm screwed? Kinda seems like it. Ugh.

Update: Per @kasperd 's comments, the fact that my server stopped letting me SSH in exactly a year after setting it up may just be a crazy coincidence. Thanks to a conversation via the discussion thread over on the Azure documentation site, I discovered that Azure Linux VMs created via the gallery are loaded with the Microsoft Azure Linux Agent which allows admins to reset SSH through the command line (i.e. Powershell). So while it's a pain for me to switch over to Windows, I was able to follow the steps and reset SSH options on my VM. Unfortunately, I still wasn't able to SSH into my machine. Obviously I did something drastic to my machine that wasn't covered by the reset options, but for users with less drastic cases hopefully they can follow some of these links to help their situation.

Best Answer

Related Solutions

Amazon EC2 – Understanding SSH RSA Fingerprint

SSH key stopped working on Ubuntu Azure VPS

Related Topic