On OSX, the native ssh-add client has a special argument to save the private key's passphrase in the OSX keychain, which means that your normal login will unlock it for use with ssh. On OSX Sierra and later, you also need to configure SSH to always use the keychain (see Step 2 below).
Alternatively you can use a key without a passphrase, but if you prefer ...
As of macOS Sierra 10.12.2 Apple added an ssh_config option called UseKeychain which allows a 'proper' resolution to the problem. Add the following to your ~/.ssh/config file:
From the ssh_config man page on 10.12.2:
On macOS, specifies whether the system should search for passphrases in the ...
I had this issue as well when attempting to deploy some code using Capistrano. Very frustrating. Here are two methods I know of to deal with this issue.
Method 1: Add all known keys to the SSH agent.
So one solution I found is to run ssh-add with the -A option—which adds all known identities to the SSH agent using any passphrases stored in your keychain—...
The best solution I've found today (2017) is to use Homebrew and Cask to install osxfuse and sshfs. Note that Homebrew core deprecated all FUSE-related formulae in 2020 so you need to install sshfs from a tap:
brew install --cask macfuse
brew install gromgit/fuse/sshfs-mac
sshfs username@hostname:/remote/directory/path /local/mount/point -ovolname=...
First, run ssh-add -K and check whether this fixes your problem.
Removed the rsa_id.pub file and regenerated a new one (must be in ~/.ssh/):
ssh-keygen -y -f id_rsa > id_rsa.pub
Ensured permissions were set to 600 for both id_rsa and id_rsa.pub (must be in ~/.ssh/):
chmod 600 id_rsa*
Ran the following command:
After doing this, ...
You should be using SSH keys to authenticate with rather than putting your password on the command line as it's extremely insecure.
The way this works is once you have your SSH keys set up, all you have to do is issue the command:
and without typing another thing, you will be automatically logged in.
Copy SSH Public Key to Mac/FreeBSD/Linux ...
Why not just use an SSH Tunnel via OSX's built in Terminal?...
Launch an SSH tunnel
To initiate your SSH tunnel, simply open Mac OSX Terminal.app and connect to your remote server via SSH with the following flags:
ssh -D 8080 -C -N email@example.com
This will launch our SSH tunnel on port 8080 and route all traffic (securely) through the server at ...
You can enable bash shell completion by installing bash-completion via brew:
brew install bash-completion
Then add the following to your ~/.bash_profile:
if [ -f $(brew --prefix)/etc/bash_completion ]; then
. $(brew --prefix)/etc/bash_completion
(Edit: brew tap homebrew/completions is deprecated as of 2018.)
Configure your system, system-wide, for all connections
By editing: /etc/ssh/ssh_config
And add the line:
Or, per-server ~/.ssh/config
What this basically does it sends keep alive packet, every 10 seconds...
I had a similar problem, in that I was being asked every time for my pub-key passphrase. Per suggestion of user "trisweb" above, I turned on these options to ~/.ssh/config:
But it still prompted every time I wanted to use ssh. Eventually I turned on ssh -v and found this debug line:
Welcome to the wonderful world of OS X Keychain and ssh-agent! From the man page:
ssh-agent is a program to hold private keys used for public key authentication (RSA, DSA, ECDSA). The
idea is that ssh-agent is started in the beginning of an X-session or a login session, and all other
windows or programs are started as clients to the ssh-...
To disable storing passphrase in keychain you should add following lines to ~/.ssh/config file:
If you already have passphrase stored in keychain you can delete it using commands:
sqlite3 keychain-2.db 'delete from genp where agrp="com.apple.ssh.passphrases"'
If you would like to have a behavior ...
The issue is ssh is waiting for a connection to your ssh-agent. You can test this by running SSH_AUTH_SOCK= ssh firstname.lastname@example.org.
If this is indeed the issue (as it was for me), then you probably have multiple LaunchAgents that are listening on the socket at SSH_AUTH_SOCK and one of them is doing the wrong thing. For example, I had one from MacPorts that was ...
To all where the above did not work, my issue appears to have been because I was duplicating the UseKeychain yes & AddKeysToAgent yes in all ssh key profiles / shortcuts. I updated my ~/.ssh/config file to declare these only once and they now all load on login without prompting for passwords on startup, e.g:
Has Apple locked this file [/System/Library/LaunchDaemons/ssh.plist] down definitively?
Yes, they have, you need to disable SIP (System Integrity Protection), but note that editing ssh.plist is not the only option to change the SSH server port, there are other ways to achieve the same result.
There are (at least) 4 ways to change the port sshd listens on:
As explained here, this is the recommended method since macOS 10.12.2:
Add the following lines to your ~/.ssh/config file:
Any key you add to the ssh-agent using the ssh-add /path/to/your/private/key/id_rsa command will be automatically added to the keychain, and should be autoloaded upon reboot.
Developer Jeremy Huddleston Sequoia announced yesterday that this problem is solved in XQuartz 2.7.8_beta2:
XQuartz 2.7.8_beta2 is available for download.
You can see http://xquartz.macosforge.org/trac/wiki/X112.7.8 for a
full set of changes, but most noteworth ones are:
1) xauth now correctly parses the Yosemite launchd $DISPLAY ...
To disable strict host checking on OS X for the current user, create or edit ~/.ssh/config and add the following lines:
Host [IP Address]
A typical example for the hosts in your local network could be:
Depending on your ...
You can stop the ssh service by typing the following:
$ sudo launchctl unload /System/Library/LaunchDaemons/ssh.plist
To start it again, use this:
$ sudo launchctl load -w /System/Library/LaunchDaemons/ssh.plist
Thanks to Clive, I have a better understanding of this new 'feature'. When you type in your passphrase Sierra adds it to your Keychain but not to the ssh-agent. If your identity isn't in ssh-agent there is no way to manage it with ssh-add. To manage (ie. remove) your identity from Keychain you need to add your identity to ssh-agent by using ssh-add. Once you ...
One option is add your private SSH key to macOS Keychain, then use TouchID for Keychain authentication. You will want to use ssh-add -K ~/.ssh/[your-private-key] -- however on macOS 10.12 Sierra the feature needs to be enabled by editing editing ~/.ssh/config and adding:
Host * (asterisk for all hosts or add specific host)
I was editing the wrong configuration file! Instead of /etc/ssh_config, I edited private/etc/sshd_config. I think this probably would have also worked if I edited /etc/sshd_config as per the updated answer from @GhostLyrics, but I didn't test that yet so I can't say for sure. After that, I restarted the service with sudo launchctl stop com.openssh.sshd and ...
There are several possibilities. Your example will obviously not work, but you can achieve something similar using sshpass utility:
sshpass -p password ssh host@IP
Note, this is not recommended because the password will be visible for other processes or in the shell history.
A much better way to do the same is to set up the passwordless authentication ...
I assume the shell of your Mac is bash.
You need to complete ssh command, for more detail you can read man complete
comp_ssh_hosts=`cat ~/.ssh/known_hosts | \
cut -f 1 -d ' ' | \
sed -e s/,.*//g | \
For macOS 10.12 Sierra ssh-add -K needs to be run after every reboot. To avoid this create ~/.ssh/config with this content.
Apple has added Technote 2449 which explains what happened.
Prior to macOS Sierra, ssh would present a dialog asking for your passphrase and would offer ...
If you are here and your system is running anything from 10.10 and newer, the sysadminctl command is your best friend. It does a lot of magic that DSCL can't do.
Here's the output for sysadminctl:
sysadminctl[21233:29122637] Usage: sysadminctl
-deleteUser <user name> [-secure || -keepHome]
-newPassword <new password> -oldPassword <...