You should first file a complaint with the server's administration, observing that public key authentication is vastly more secure than simply a password, but I'll assume you've already done so, and your admins are simply idiots.
Apple sadly removed ssh-askpass when they integrated its functionality into ssh, scp, and ssh-add. There is however an SSHKeychain package that provides an ssh-askpass with an Apple-like Cocoa password prompt for macports' openssh package. It should fix your problems the way you want, perhaps even setting the SSH_ASKPASS variable for you.
Just fyi, I'd usually recommend against installing the openssh macports package itself because it break your Apple password prompt, but once you've installed SSHKeychain macports usually offers a more recent openssh than Apple.
There is nothing wrong imho with embedding passwords in scripts when the server disables public key authentication, i.e. if they cared about security, they should reenable public keys. There are even servers that intentionally break sshpass. You could access such machines using the following expect script :
#!/usr/bin/expect -f
set timeout -1
set send_human {.05 0.1 1 .07 1.5}
eval spawn $argv
match_max 100000
expect {
-re "USERNAME@(\[0-9A-Za-z_\\-\\.\]+)'s password: "
{ sleep 0.1 ; send -- "PASSWORD\r" ; sleep 0.3 }
}
interact
You may speed up this script by reducing the sleeps and send_human delays.
There is a lot of conflicting information I've read whenever I look up information on using ssh-agent
(passphrase saving/reusing process) under Mac OS X. Most resources seem to suggest that simply issuing ssh-add -K
will let you store your passphrase, and will automatically configure OS X to launch ssh-agent
automatically and load your stored passphrase.
Note: Running ssh-add -K
will only work if you have your private key file in one of the common locations, those locations being limited to: ~/.ssh/id_rsa
, ~/.ssh/id_dsa
, ~/.ssh/identity
. If the file is located anywhere else you should specify that path after the -K in the command above.
The reason you are getting the key file passphrase dialog when connecting to the second (key-less) server is likely because the default configuration of SSH servers is to use public key authentication first, and 'keyboard interactive' authentication second.
Because you have a public key with a standard name/location (~/.ssh/id_rsa
), your OpenSSH client helpfully submits the private key in order to allow the server to match it against an allowed authorized_keys
file.
There are a small handful of ways to prevent this, the easiest two being to pass a flag on the command line, or add it as a permanent configuration item in your ~/.ssh/config
file.
When connecting to the secondary/key-less server, you can add -o "PubkeyAuthentication=no" when connecting. Something like ssh -o "PubkeyAuthentication=no" me@devserver2
.
Open up ~/.ssh/config
in your favorite text editor, create it first if you must, and enter the following:
Host devserver2
User me
PubkeyAuthentication no
Now, if you simply type ssh devserver2
the username and pubkey configuration will be read in and used, and you should be prompted for your password and nothing else.
(Note: Replace devserver2 with the actual hostname of the server. Alternatively, pick a nice hostname, such as devserver2, and add a property between User and PubkeyAuthentication called 'Hostname' and put the name or IP address of the server there. Afterwards, you actually can simply type 'ssh devserver2' and all the configuration properties will work their respective magic.)
Best Answer
Finder in macOS Sierra appears to only add the id_rsa key by default. If you want to add other keys you either have to add them manually or alter the configuration.
on my machine a simple
ssh-add ~/.ssh/test.key
worked.According to this guide you can also store the keys in your keychain:
In ~/.ssh create config file with the following content:
You can read more about this on the Apple Developer Site