ssh force user to user ssh-add

Question

I am trying to understand how this functionality works. I have digital ocean account. I have given digital ocean an ssh public key to associate with any server that I spin up. Once I've created a droplet if I try to ssh as root to the server it fails, but if I do an ssh-add and give it a the specific key that I defined with my digital ocean account then it allows me to log in. If I were to add another user account and put a different public key in that accounts authorized_hosts file I would be able to log in without using ssh-add.

Can someone explain to me how this functionality works? How do I force a user to use ssh-add?

EDIT: I did a verbose ssh, it seems to only try these keys, but not any of the other keys that I have in my .ssh directory including the one I have setup for digital ocean. That I suspect may be part of the problem.

debug1: Authentications that can continue: publickey
debug1: Trying private key: /Users/username/.ssh/id_dsa
debug3: no such identity: /Users/username/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /Users/username/.ssh/id_ecdsa
debug3: no such identity: /Users/username/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /Users/username/.ssh/id_ed25519
debug3: no such identity: /Users/username/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.

Answer 1

I think conceptually you're confusing the idea of running an SSH agent versus adding a key to an already-running SSH agent.

Normally, the workflow for adding a SSH key to a session is as follows:

1. Execute ssh-agent $SHELL, where $SHELL could be bash, zsh etc. as in ssh-agent bash
2. Associate the specific private key to the agent shell session using ssh-add
3. Connect to whatever host has the specific public key for the private key you're using in your shell session in authorized_hosts.

Note that you can use ssh-add -l at any time to see what keys you have loaded.

So in this case, the reason you're able to connect is that you're using ssh-add to add your key into your current session, which will automatically be checked when you attempt to ssh via account@host

You can see an example of this checking if you add verbosity flags to your SSH attempt using -v(vvv):

debug1: Offering RSA public key: /home/patrick/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279

With -v only, I get the following: (adding more v's increases the amount of debug verbosity you get)

debug1: Offering RSA public key: /home/patrick/.ssh/id_rsa
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
debug1: Authentication succeeded (publickey).

The reason your initial SSH session is failing without doing an ssh-add may be because your key is stored in a specific directory that isn't checked by default via SSH. However when you execute ssh-add you're adding the key to the entire session, and SSH knows to use that by default instead of searching ~/.ssh or somewhere else.

According to the SSH manpage:

-i identity_file

Selects a file from which the identity (private key) for RSA or DSA >authentication is read. The default is ~/.ssh/identity for protocol version 1, and ~/.ssh/id_rsa and ~/.ssh/id_dsa for protocol version 2. Identity files may also be specified on a per-host basis in the configuration file. It is possible to have multiple -i options (and multiple identities specified in configuration files).

So if your key is named something that's not the above filenames, or in a different location, SSH won't see it unless you specifically use the -i flag to indicate the path and filename, or you use ssh-add to add it to your session.

You can test this theory by using the -i flag with SSH to test your key. If you were to execute ssh -i $KEYLOCATION account@host you should get a successful login.

Double check that your private key file is in ~/.ssh and named id_rsa or whatever keytype it may be. Having that will probably mean you don't have to execute ssh-add in the future.