ssh passwordless logins From Mac To Linux

Question

JesusPresley Author

Level 1

0 points

ssh passwordless logins From Mac To Linux

Hey all, past questions are still unresolved or still just not working.

I'm trying to connect via ssh FROM Mac (10.8) TO Linux (latest fully-patched fedora 19).

Here's my Linux sshd_config file:

# egrep -v '^(#|$)' /etc/ssh/sshd_config

Protocol 2

SyslogFacility AUTHPRIV

MaxAuthTries 6

PubkeyAuthentication yes

AuthorizedKeysFile .ssh/authorized_keys

PasswordAuthentication yes

ChallengeResponseAuthentication no

GSSAPIAuthentication yes

GSSAPICleanupCredentials yes

UsePAM yes

X11Forwarding yes

UsePrivilegeSeparation sandbox # Default for new installations.

AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES

AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT

AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE

AcceptEnv XMODIFIERS

Subsystem sftp /usr/libexec/openssh/sftp-server

If I change to 'PasswordAuthentication no' the attempt is rejected outright:

$ ssh user@host

Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

The passwordless auth method works on the rest of my systems:

Linux <-> Linux

Linux -> Mac, but not

Mac -> Linux

I know this has been covered to death but I've followed the instructions here and no love. Also I've been all through this forum and still nada. Any insights would be appreciated.

TT

MacBook Pro, OS X Mountain Lion (10.8.2), i7, 16GB, 750GB, late 2011

Posted on Oct 3, 2013 1:15 PM

Reply

Answer 1

Oct 3, 2013 3:21 PM in response to JesusPresley

This is probably a dumb question, but are you able, or were you able to ssh into the system, with a password?

Can you log into this linux box, from other systems?

Have you tried using 'ssh -vv <hostname>

if so, what get returned on the command line?

Reply

Answer 2

Oct 3, 2013 3:50 PM in response to Nils C. Anderson

Also, check for errors on the linux system, /var/log/messages. Worst case start the server with the '-vv' options, as well.

Reply

Answer 3

BobHarris

Level 9

53,045 points

Oct 3, 2013 3:55 PM in response to Nils C. Anderson

I would be going with 2 ssh -v -v -v tests.

The first Linux to Linux.

The second Mac to Linux.

Compare the debugging output and see where the Mac to Linux took a left turn. Then see if the major differences between the L2L and the M2L give a clue about why the Mac failed.

Also look at the Linux sshd logs in /var/log

It is also possible to set the debug level for sshd via the /etc/sshd_config file (you will need to restart sshd after changing the debug level. Also remember to remove the DEBUG option when you are done.

Reply

Answer 4

etresoft

Level 8

46,104 points

Oct 3, 2013 4:28 PM in response to JesusPresley

JesusPresley wrote:

I've been all through this forum and still nada.

That's because you are in the wrong forum. Try this one: http://www.fedoraforum.org

Reply

Answer 5

Oct 3, 2013 9:30 PM in response to JesusPresley

Here is how I use ssh to connect to OpenVMS, and the sequence is basically the same to the Linux boxes that I deal with. Typically somewhat simpler than OpenVMS actually, as you don't need to convert the key formats.

Here are links to a three-part Gentoo ssh writeup.

Make absolutely certain that the private keys are correctly protected; ssh can enforce that.

Reply

Answer 6

JesusPresley Author

Level 1

0 points

Oct 4, 2013 8:27 AM in response to Nils C. Anderson

Nills, I can login from the mac to the linux box via standard auth (UN/PW); No problem, works fine.

Here's the ssh session output:

mac:~ username$ ssh -vv lin_user@dest_host

OpenSSH_5.9p1, OpenSSL 0.9.8y 5 Feb 2013

debug1: Reading configuration data /etc/ssh_config

debug1: /etc/ssh_config line 20: Applying options for *

debug1: /etc/ssh_config line 53: Applying options for *

debug2: ssh_connect: needpriv 0

debug1: Connecting to dest_host [dest_host] port 22.

debug1: Connection established.

debug1: identity file /Users/username/.ssh/id_rsa type 1

debug1: identity file /Users/username/.ssh/id_rsa-cert type -1

debug1: identity file /Users/username/.ssh/id_dsa type 2

debug1: identity file /Users/username/.ssh/id_dsa-cert type -1

debug1: Remote protocol version 2.0, remote software version OpenSSH_6.2

debug1: match: OpenSSH_6.2 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_5.9

debug2: fd 3 setting O_NONBLOCK

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie- hellman-group14-sha1,diffie-hellman-group1-sha1

debug2: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-dss

debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blow fish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib

debug2: kex_parse_kexinit:

debug2: kex_parse_kexinit: first_kex_follows 0

debug2: kex_parse_kexinit: reserved 0

debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie- hellman-group14-sha1,diffie-hellman-group1-sha1

debug2: kex_parse_kexinit: ssh-rsa,ssh-dss

debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se

debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: none,zlib@openssh.com

debug2: kex_parse_kexinit:

debug2: kex_parse_kexinit: first_kex_follows 0

debug2: kex_parse_kexinit: reserved 0

debug2: mac_setup: found hmac-md5

debug1: kex: server->client aes128-ctr hmac-md5 none

debug2: mac_setup: found hmac-md5

debug1: kex: client->server aes128-ctr hmac-md5 none

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

debug2: dh_gen_key: priv key bits set: 121/256

debug2: bits set: 521/1024

debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

debug1: Server host key: RSA e1:0c:2a:b9:fa:4b:ae:a3:ca:18:64:01:98:fd:01:19

debug1: Host 'dest_host' is known and matches the RSA host key.

debug1: Found key in /Users/username/.ssh/known_hosts:49

debug2: bits set: 508/1024

debug1: ssh_rsa_verify: signature correct

debug2: kex_derive_keys

debug2: set_newkeys: mode 1

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug2: set_newkeys: mode 0

debug1: SSH2_MSG_NEWKEYS received

debug1: Roaming not allowed by server

debug1: SSH2_MSG_SERVICE_REQUEST sent

debug2: service_accept: ssh-userauth

debug1: SSH2_MSG_SERVICE_ACCEPT received

debug2: key: /Users/username/.ssh/id_rsa (0x7ffd63c10b30)

debug2: key: /Users/username/.ssh/id_dsa (0x7ffd63c1db60)

debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

debug1: Next authentication method: publickey

debug1: Offering RSA public key: /Users/username/.ssh/id_rsa

debug2: we sent a publickey packet, wait for reply

debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

debug1: Offering DSA public key: /Users/username/.ssh/id_dsa

debug2: we sent a publickey packet, wait for reply

debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

debug2: we did not send a packet, disable method

debug1: Next authentication method: password

lin_user@dest_host's password:

debug2: we sent a password packet, wait for reply

debug1: Authentication succeeded (password).

Authenticated to dest_host ([dest_host]:22).

debug1: channel 0: new [client-session]

debug2: channel 0: send open

debug1: Requesting no-more-sessions@openssh.com

debug1: Entering interactive session.

debug2: callback start

debug2: client_session2_setup: id 0

debug2: fd 3 setting TCP_NODELAY

debug2: channel 0: request pty-req confirm 1

debug1: Sending environment.

debug1: Sending env LANG = en_US.UTF-8

debug2: channel 0: request env confirm 0

debug2: channel 0: request shell confirm 1

debug2: callback done

debug2: channel 0: open confirm rwindow 0 rmax 32768

debug2: channel_input_status_confirm: type 99 id 0

debug2: PTY allocation request accepted on channel 0

debug2: channel 0: rcvd adjust 2097152

debug2: channel_input_status_confirm: type 99 id 0

debug2: shell request accepted on channel 0

Last login: Thu Oct 3 13:25:08 2013 from mac

[lin_user@dest_host ~]#

Reply

Answer 7

Oct 4, 2013 9:28 AM in response to JesusPresley

Make sure you don't have a key file name collision; either client-side or server-side key file names can get tangled. That osxdaily script only works for one session. For example, I usually name the private and the public key files based on the target host name. This avoids conflicts, and makes key replacements obvious.

Reply

Answer 8

JesusPresley Author

Level 1

0 points

Oct 4, 2013 9:40 AM in response to JesusPresley

I've added a new step (1); never had to do this before but this is what broke it loose.

1) Remote Host:

(not always necessary but there can be odd failures without this step)

$ ssh-keygen -t rsa -f ~/.ssh/id_rsa

2) Local Workstation:

Create host-specific key and store in standard location

$ ssh-keygen -t rsa -f ~/.ssh/user_hostname

3) Linux: Copy key to remote host

$ ssh-copy-id -i ~/.ssh/user_hostname.pub user@hostname

4) Mac: Copy key to remote host (no ssh-copy-id on macs)

$ cat ~/.ssh/user_hostname.pub | ssh user@hostname 'cat >> ~/.ssh/authorized_keys'

Thanks for helping me to get the wheels turning.

TT

Reply

Answer 9

etresoft

Level 8

46,104 points

Oct 4, 2013 10:07 AM in response to JesusPresley

Any reason why you are not using dsa keys?

Also, Linux tends to make easy things hard and that encourages some lax security processes. I suggest you create a new dsa key on your Mac. Disregard most advice to use a blank passphrase and create a strong passphrase for your private key. The OS X Keychain also includes ssh-agent. Enter your passphrase once and store it in your keychain. Copy that to your Linux machines. You will end up with a much more secure key than before.

Reply

Answer 10

Oct 4, 2013 1:10 PM in response to JesusPresley

There's no need for a keygen on the remote host, so I do not know what you are doing there.

ssh works securely by only relocating the public key off the local host. Not the private key.

The private key — which is part of a keygen — is held privately, and for ssh on the host originating the connection.

FWIW, please take the time to read the links I've posted, and including the gentoo intro.

Reply

Answer 11

JesusPresley Author

Level 1

0 points

Oct 7, 2013 11:13 AM in response to MrHoffman

MrHoffman, I've only skimmed the provided links so far but they look great. I'll fully digest them through the week with some testing.

Good write-ups, Thank you.

TT

Reply

Answer 12

Mar 15, 2014 8:47 AM in response to JesusPresley

This is how I did it - from a MBA to an ubuntu box: You have to make sure that you know what your host and user name are on the mac.

>

ssh-keygen -t rsa -C "yourname@yourdomain.ext"

Yourdomain is - hostname -

eg bobs-mini.local

yourname is - whoami bob

Set a passphrase when asked for one.

Then copy the id_rsa.pub file to a new file authorized_keys in

the .ssh directory of the user that you are sshing into the server with.

You can check errors at /var/log/auth_log

In may case the new user I had setup on the linux box had the incorrect permission on the home dir. Never would of know this withoug the auth_log file telling me!!!

You will be asked for the passphrase (set when you use the ssh-keygen command) once when connecting for the first time.

I think the main problem stems from using ssh-keygen without setting it up with the correct host and user name.

If you don't you have to ssh into the server with the same user name on the mac and linux box to get this to work with no password.

Reply

Answer 13

Mar 15, 2014 5:49 PM in response to Thabo Da Husky

Thabo Da Husky wrote:

This is how I did it - from a MBA to an ubuntu box: You have to make sure that you know what your host and user name are on the mac.

The public key is tied to the originating private key. By default, the ssh public keys aren't specific to any originating host with the ssh systems I've worked with; you can allow the originating host name to default. You can copy the keys around, for instance.

Then copy the id_rsa.pub file to a new file authorized_keys in

the .ssh directory of the user that you are sshing into the server with.

Expect to place the key filename in the list of authorized keys in whatever file the target system is using, but not the contents of the key file itself.

Consider renaming the keys to the host name; there are various ways to do that, including a file rename via mv or such. Usually to the host name. This because it's far too common to end up with multiple id_rsa.pub files around.

You will be asked for the passphrase (set when you use the ssh-keygen command) once when connecting for the first time.

I'd expect to be asked for the passphrase for every connection established. Not just the first. It's security against having the private key copied around or otherwise exposed.

Reply