remote login via ssh and public keys

Depending on the command you used to create the key this would determine whether or not you would have been prompted to set a passphrase with the ssh key.

using this command in the terminal will generate a key and you will prompted you set a password but if you press enter without setting a password it carries on and generates the key without setting a password.

ssh-keygen -b 1024 -t dsa

If you ran the same command but added and extra function then it wont prompt you to set a password. either way you can easily generate the key without a password.

ssh-keygen -N "" -b 1024 -t dsa

copy your public key 'id_dsa.pub' into the autorized_keys2 file on your server

If you don't already have an authorized_keys2 file first of all copy your id_dsa.pub to your desktop

Then your terminal use the command

cat ~/Desktop/id_dsa.pub >> ~/.ssh/authorized_keys2

Then test your connection from your remote client

ssh myserver.local

change myserver.local for the actual server address.

If this lets you log in without asking for password then your key is working.

Then you can secure the ssh server by editing /etc/sshd_config

uncomment and change the following lines as necessary:


SyslogFacility AUTHPRIV
LogLevel INFO
PermitRootLogin no
StrictModes yes
MaxAuthTries 6
PermitEmptyPasswords no
PubKeyAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys2
RSAAuthentication no
RhostsAuthentication no
PasswordAuthentication no
ChallengeResponseAuthentication no


then save the /etc/sshd_config

To test your setup from your remote device rename your private key to id_dsa.test

then initiate the connection to the server you should now get the message 'permission denied public key'

then rename your private key back to id_dsa

and this time your connection will work.

You need a little clarification here.

When you turn off password authentication its stops an ssh login using the user account password on that machine your logging into. This would prevent a brute force attack.

When you have a password associated with your rsa key it is using a password to unlock the key. This password is not in anyway associated with the password on your user account on the server. So this setup still requires you to enter your key password when you login. But this setup still stop brute force attacks as standard user password authentication is disabled.

The only way this could be broken is if your remote device was stolen and the theif had both your public and private key and time on their hands to crack the ssh key password. If you used a really long secure password this would take months to crack and you could in that time send a signal to the iphone to disable the phone or wipe the phone.

You can lock down remote login even further by only allowing your user account ssh access in the sharing preferences. But this is unnecessary as you have disabled password authentication in the sshd_config.

1) In Sharing > Remote Login, do I still need an account listed to be able to use ssh logins with a public key? I ask because currently (i.e. password authentication enabled), when no accounts are listed, login via public key doesn't work. In other words, an account has to be listed for public key logins to work.

Yes you still need an account name to login to that computer. However you don't need to specify an account in the sharing preferences. You can lock down the security further by limiting which user accounts can login via ssh.

by default if you don't specify a username when you login it will use the username of the device your logging in from. So to use an alternative login name you would use

ssh john@server.local

whereas john can be anyname or your choosing.

Put another way: if turn off password authentication for ssh in sshd_config, how should Sharing > Remote Login be configured?

If you turn off password authentication you still need to allow your user account to login via ssh in the sharing preferences or you can allow all.

2) According to that MacOS X Hints article:

"Leopard has now a built-in support for SSH authentication with public keys.

OSX has been able to use ssh public key authentication since day 1 of the beta release of osx. It is not new to leopared it has been around for years.

Just open Terminal and ssh to your public-key-enabled server. A Keychain window appears, proposing you to enter the pass phrase, and then remembering it in your keychain. "

I have not used this functionality as I don't use any passwords for ssh logins.

They're talking about the password associated with the key. But on second thought, that password is being saved on the client, not the server, right?

I am sure this is the case.

Offending key in /Users/user/.ssh/known_hosts:7

Edit your known_hosts file and remove entry 7.

The next time you access that host, a new known_hosts entry will be created.

This generally happens if you upgrade or re-install the OS on the remote system, or force ssh to generate a new ssh host key.

I'm having the same issue. I know that the only reason that the server should gen a new key is if you reinstall or gen a new key manually. My problem is that I haven't done either. When this happens most often for me is when I access from a new location. I port my MacBook around to different networks. Is it possible that it's creating a new ssh key based on inbound information (i.e., you're coming from a new public IP and it's thinking it needs to generate a new key for the session/future sessions for client:IP)? That's the only plausible explanation.

I'm chasing this up from server side on my OS support forum (sabayon linux/linuxquestions.org) but any input you can offer here would be greatly appreciated.

Gryyphyn, out.

The .ssh/known_hosts file contains lines with 2 fields. The first field is host name or IP address of the remote system you are connecting to.

If this field changes (maybe because of DHCP address assignment and/or dynamic DNS name generation by the DHCP server), it might cause ssh to complain.

Do you have any ~/.ssh/config or /etc/ssh_config entries relating to the known_hosts processing? See:

man ssh_config

those passwords are associated with the private keys on the client computer, not the public keys on the server computer. IF someone steals the private key from the client computer, they would have had to have gained physical access to your computer and logged in as you or as admin user then sudo -s in order to copy it, or logged in as an admin user via AFP or Screen Sharing/VNC. If they can do that, they don't need to screw around with stealing your ssh private key anyways. The minute you think that the private key on the client computer has been compromised, you delete the public key on the server. Then the private key is useless.

You don't associate passwords with public keys? Isn't that a security risk? What if someone stole the key?

My keys are secured in an encrypted disk image. So even if someone had physical access to my computer they would have to crack the 32 character password I have on my disk image.

I do it this way so I only have to remember 1 password to unlock my keys rather than have to remember lots of passwords for each ssh key.

I created a encrypted volume and name the volume .ssh

I then delete ~/.ssh

then I symlink my mounted disk image to ~/.ssh