SSH key verification is failing.

No idea what is happening. You may try to edit/create a client ssh config file and set the IdentityFile explicitly.

This is what I usually do with linux system, convert to mac.

vim ~/.ssh/config # (it should be /Users/bhatr011/.ssh/config in your case)
# Add the following config
Host prefferedhostname
    User root
    Hostname 104.236.184.105
    Port 22
    PreferredAuthentications publickey
    IdentityFile /path/to/your/private/key

Then you should be able to ssh to your droplet simply by typing

ssh prefferedhostname

The host key and the SSH key you use to log in are two different things.

One authenticates the host for you to verify (the host key), and the other one is the key you use to identify yourself and authenticate to your account.

If you delete a droplet and create a new one with the same IP, for instance, you will see a SSH host key verification failed because the SSH host key of your first droplet and the second one aren’t the same. This is a security feature so you can detect man in the middle attacks.

When you restore a snapshot, unfortunately DigitalOcean messes around a lot of files, especially the SSH ones. Even if you carefully prepare your host key, note down its fingerprint and then snapshot hoping to restore it as-is, you’ll find that they heavily modify your disk image upon restoration, leading to these sort of errors.

The only “safe” way to prevent MitM attacks on your box is this:

Take a snapshot, restore it, reset the root password, log in through web console, check the SSH host key fingerprint, then log in over SSH verifying the key.

If you don’t want to risk filesystem corruption when resetting the root password, restore your droplet using a password rather than the SSH keys. You will be asked to change it on first log in.