Ssh – temporarily disable login using one specific ssh key

Check permissions. OpenSSH will not allow public-key authentication if a user's home directory, ~/.ssh, or ~/.ssh/authorized_keys is world writable. Also, ~/.ssh and ~/.ssh/authorized_keys should probably not be group-writable either. Leave IdentityFile at the default, it's has nothing to do with the server aspect. It points to the default private key file used by the ssh client on UNIX/Linux. ssh_config is used only by the ssh client, and not the OpenSSH sshd server. The contents of authorized_keys should be one line per public key that is authorized to log in and look something like this:

ssh-rsa AAA.../Us= My Public Key comment

Where ... is a bunch of base64 characters ([a-zA-Z/+=]). PuTTYGen can generate two forms of keys: PuTTY and OpenSSH compatible. The OpenSSH compatible will be one long line in the above format. If it's in PuTTY format, you can import it back into PuTTYGen and save as OpenSSH.

Alice can give Bob her public key, and Bob can add a line to his own .ssh/authorized_keys file that will allow Alice to start a ssh session (as Bob) on Bob's workstation foo. Using the command= option, Bob can restrict Alice's key to not grant an interactive shell, but a nested ssh connection to baz as Bob, and using a key locally accessible to Bob on bar.

command="ssh -I .ssh/id_rsa bob@baz:22" ssh-rsa AAA...== alice@whatever

Optionally, you can include further constraint options (no-port-forwarding, from=, etc. - see sshd man page section on AUTHORIZED_KEYS FILE FORMAT).

When Alice runs ssh bob@bar and authenticates with her private key, she will be connected through bar to a ssh session on baz, without having any control over the intermediate session on Bob's workstation.

Note that from the perspective of baz (logging, security audit), there is no distinction between this tunneled connection initiated by Alice, and a "normal" connection by Bob from his own workstation. This may be what you asked for, but not what you want.

For making the protected key available to Alice for her session, you can explicitly set the environment variable SSH_AUTH_SOCK to be the path that Bob uses for his session (change the authorized_keys entry to command="SSH_AUTH_SOCK=/path/to/bobs/agent_socket ssh bob@baz:22" ssh-rsa AAA...) To avoid having to update the path when it changes (logoff/login typically), Bob can run a dedicated agent on Alice's behalf with an explicit path specified (ssh-agent -a ~/.ssh/agent_for_alice and add only the specific key with SSH_AUTH_SOCK=~/.ssh/agent_for_alice ssh-add ~/.ssh/id_rsa and entering the passphrase.