can't get OS X to let me ssh without a password

L

Lazarus18

In debt medical student
I have setup public/private keys on Linux to let me ssh without a password. Works fine from Linux to Linux.

However, when I try to do the same between my Linux box and OS X it's no go. I have made keys with ssh-keygen -d. I put the public key it generates on my OS X box in ~/.ssh/authorized_keys2. I made sure not to enter a password when generating it.

Are there some options I need to tweak in sshd_config or something? This has just worked w/ Linux. My ssh -v output is below. Thanks for any advice.

ssh -v Rick
OpenSSH_3.0.2p1 Debian 1:3.0.2p1-9, SSH protocols 1.5/2.0, OpenSSL 0x0090603f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Seeding random number generator
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: restore_uid
debug1: ssh_connect: getuid 1000 geteuid 0 anon 1
debug1: Connecting to Rick [192.168.1.100] port 22.
debug1: temporarily_use_uid: 1000/1000 (e=0)
debug1: restore_uid
debug1: temporarily_use_uid: 1000/1000 (e=0)
debug1: restore_uid
debug1: Connection established.
debug1: read PEM private key done: type DSA
debug1: read PEM private key done: type RSA
debug1: identity file /home/rob/.ssh/identity type 0
debug1: identity file /home/rob/.ssh/id_rsa type 1
debug1: identity file /home/rob/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.1p1
debug1: match: OpenSSH_3.1p1 pat ^OpenSSH
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.0.2p1 Debian 1:3.0.2p1-9
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv key bits set: 122/256
debug1: bits set: 1580/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'rick' is known and matches the RSA host key.
debug1: Found key in /home/rob/.ssh/known_hosts:2
debug1: bits set: 1524/3191
debug1: ssh_rsa_verify: signature correct
debug1: kex_derive_keys
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: waiting for SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: authentications that can continue: publickey,password,keyboard-interactive
debug1: next auth method to try is publickey
debug1: try pubkey: /home/rob/.ssh/id_rsa
debug1: authentications that can continue: publickey,password,keyboard-interactive
debug1: try pubkey: /home/rob/.ssh/id_dsa
debug1: authentications that can continue: publickey,password,keyboard-interactive
debug1: next auth method to try is keyboard-interactive
debug1: authentications that can continue: publickey,password,keyboard-interactive
debug1: next auth method to try is password
rob@rick's password:
 
Have you looked at man ssh?

It mentions different ways that ssh authenticates, which I am not going to repost here since you can get it from the command line. It also talks about ssh-agent which is supposed to help you with RSA authentication.
 
I was having all sorts of such troubles myself - one key would work from OS X to Linux/Solaris, another from Linux to Linux, a third from Linux to Solaris.

I forget what the deal was with going from Linux/Solaris to OS X, but I decided the ssh setup on campus was obviously so dodgy, I should not have a password-free key to my home machine there anyway...

In any case, it seems some servers were configured/compiled for certain key algorithms, others weren't but the clients on the same machines were. Much experimentation, and I still don't know how it works, just that it finally more or less does.

And, yes, you do need to specify what authentication options to accept in sshd_config
 
based on your ssh -v output, it looks like it is looking for the key at ~/.ssh/id_rsa or ~/.ssh/id_dsa, but you said that you put the public key in ~/.ssh/authorized_keys2. So maybe you just need to move your key up to the ~/.ssh directory?
 
in /etc/sshd_config make sure you have

RSAAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys
PasswordAuthentication no

and in ~/.ssh

chmod 600 authorized_keys
 
It sounds like what you're saying should work, and indeed you got it to work on Linux.

Though it doesn't help you much, I can tell you I've successfully SSH-ed from Windows/Cygwin to OS X.

-Rob
 
Here's my complete howto on no-pwd-ssh

ssh-keygen -t rsa
generates id_rsa.pub, the public key
and id_rsa, the private key

Copy the public key to the remote host
scp id_rsa.pub user@remotehost:".ssh/authorized_keys"

At the host, set rights
chmod 600 ~/.ssh/authorized_keys

and modify lines in /etc/sshd_conf
RSAAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys
PasswordAuthentication no

Then, you're ready to rock'n roll!
ssh user@remotehost -i id_rsa

:cool:
z4ph0d
 
Still nothing. Asks me for a password everytime. Is it possible that the generated key is of a different length than the expected key? That seems unlikely given that the key I generated on OS X lets me into my Linux box sans password, but it doesn't work the other way around. This makes me think the problem is in sshd_config somehow, but I don't know how. It is below for anyone's viewing pleasure.

# $OpenBSD: sshd_config,v 1.38 2001/04/15 21:41:29 deraadt Exp $

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# This is the sshd server system-wide configuration file. See sshd(8)
# for more information.

Port 22
#Protocol 2,1
#ListenAddress 0.0.0.0
#ListenAddress ::
HostKey /etc/ssh_host_key
HostKey /etc/ssh_host_rsa_key
HostKey /etc/ssh_host_dsa_key
ServerKeyBits 768
LoginGraceTime 600
KeyRegenerationInterval 3600
PermitRootLogin no
#
# Don't read ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes
StrictModes yes
X11Forwarding yes
X11DisplayOffset 10
PrintMotd yes
#PrintLastLog no
KeepAlive yes

# Logging
SyslogFacility AUTH
LogLevel INFO
#obsoletes QuietMode and FascistLogging

RhostsAuthentication no
#
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication yes
# similar for protocol version 2
HostbasedAuthentication no
#
RSAAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
PermitEmptyPasswords no

# Uncomment to disable s/key passwords
#ChallengeResponseAuthentication no

# Uncomment to enable PAM keyboard-interactive authentication
# Warning: enabling this may bypass the setting of 'PasswordAuthentication'
#PAMAuthenticationViaKbdInt yes

# To change Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#AFSTokenPassing no
#KerberosTicketCleanup no

# Kerberos TGT Passing does only work with the AFS kaserver
#KerberosTgtPassing yes

#CheckMail yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net
#ReverseMappingCheck yes

Subsystem sftp /usr/libexec/sftp-server
 
Clarifying question:
Does the private key ask for a passphrase, or is it the host that asks for password?

You might want to try generating a SSH1 key instead of an SSH2 key:
ssh-keygent -t rsa1

In any event, dont give up a passphrase for the key, just hit enter! Keep that private key in a safe place though... If its compromized, anyone can login to the account you generated it for
 
I know not to enter a passphrase when generating the key. Like I said, I can get this to work on Linux machines....

I already had tried rsa1, although I didn't type what you suggested, just ssh-keygen. This is what I had used on Linux (although I've now also gotten rsa2 to work on a different Linux box).
 
I had same problem.
My home directory was set to drwxrwxr-x+ and sshd did not like it.
try to set
StrictModes no
in sshd _config

Furt
 
You must log in or register to reply here.
Back
Top