SSH and Passphrase broken after upgrade

Question

Level 1

0 points

SSH and Passphrase broken after upgrade

HI guys,

Just upgraded to Mavericks and I realise that it breaks my SSH sessions when I use the private/public + passphrase authentication.

ssh -v localhost

OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011

debug1: Reading configuration data /Users/myuser/.ssh/config

debug1: /Users/myuser/.ssh/config line 77: Applying options for *

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 *

debug1: Connecting to localhost [::1] port 22.

debug1: Connection established.

debug1: identity file /Users/myuser/.ssh/myuser_sshkey_rsa type 1

debug1: identity file /Users/myuser/.ssh/myuser_sshkey_rsa-cert type -1

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_6.2

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

debug1: match: OpenSSH_6.2 pat OpenSSH*

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug1: kex: server->client aes128-ctr hmac-md5-etm@openssh.com

zlib@openssh.com

debug1: kex: client->server aes128-ctr hmac-md5-etm@openssh.com

zlib@openssh.com

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

debug1: Server host key: RSA 4d:48:99:86:76:c3:35:4e:b6:08:f2:07:cf:fd:bf:dc

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

debug1: Found key in /Users/myuser/.ssh/known_hosts:183

debug1: ssh_rsa_verify: signature correct

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug1: SSH2_MSG_NEWKEYS received

debug1: Roaming not allowed by server

debug1: SSH2_MSG_SERVICE_REQUEST sent

debug1: SSH2_MSG_SERVICE_ACCEPT received

debug1: Authentications that can continue: publickey,keyboard-interactive

debug1: Next authentication method: publickey

debug1: Offering RSA public key: /Users/myuser/.ssh/myuser_sshkey_rsa

debug1: Server accepts key: pkalg ssh-rsa blen 1047

debug1: key_parse_private_pem: PEM_read_PrivateKey failed

debug1: read PEM private key done: type <unknown>

Saving password to keychain failed

debug1: key_parse_private_pem: PEM_read_PrivateKey failed

debug1: read PEM private key done: type <unknown>

debug1: key_parse_private_pem: PEM_read_PrivateKey failed

debug1: read PEM private key done: type <unknown>

debug1: Next authentication method: keyboard-interactive

Password:

and yes, myuser_sshkey_rsa.pub is in the .ssh/authorized_keys

I did not change the keys after Mavericks upgrade. It just couldnt work as it was working in the preivous version.

Any idea on whats going on?

thanks

Mac mini, OS X Mavericks (10.9)

Posted on Oct 23, 2013 8:15 AM

Reply

Answer 1

Oct 24, 2013 10:34 AM in response to cameleons

If you have a backup of the older version of your /private/etc/ssh_config file, try uncommenting out the line:

MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160

Reply

Answer 2

cameleons Author

Level 1

0 points

Oct 24, 2013 6:06 PM in response to brentwolfe01

hi,

diff between before and after upgrade of /private/etc/ssh_config is null.

The file content:

# $OpenBSD: ssh_config,v 1.26 2010/01/11 01:39:46 dtucker Exp $

# This is the ssh client system-wide configuration file. See

# ssh_config(5) for more information. This file provides defaults for

# users, and the values can be changed in per-user configuration files

# or on the command line.

# Configuration data is parsed as follows:

# 1. command line options

# 2. user-specific file

# 3. system-wide file

# Any configuration value is only changed the first time it is set.

# Thus, host-specific definitions should be at the beginning of the

# configuration file, and defaults at the end.

# Site-wide defaults for some commonly used options. For a comprehensive

# list of available options, their meanings and defaults, please see the

# ssh_config(5) man page.

Host *

SendEnv LANG LC_*

# ForwardAgent no

# ForwardX11 no

# RhostsRSAAuthentication no

# RSAAuthentication yes

# PasswordAuthentication yes

# HostbasedAuthentication no

# GSSAPIAuthentication no

# GSSAPIDelegateCredentials no

# GSSAPIKeyExchange no

# GSSAPITrustDNS no

# BatchMode no

# CheckHostIP yes

# AddressFamily any

# ConnectTimeout 0

# StrictHostKeyChecking ask

# IdentityFile ~/.ssh/identity

# IdentityFile ~/.ssh/id_rsa

# IdentityFile ~/.ssh/id_dsa

# Port 22

# Protocol 2,1

# Cipher 3des

# Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc

# MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160

# EscapeChar ~

# Tunnel no

# TunnelDevice any:any

# PermitLocalCommand no

# VisualHostKey no

# ProxyCommand ssh -q -W %h:%p gateway.example.com

# XAuthLocation added by XQuartz (http://xquartz.macosforge.org)

Host *

XAuthLocation /opt/X11/bin/xauth

Tried uncommenting the line but still have the same errors (see previous post)

Reply

Answer 3

Oct 30, 2013 3:45 PM in response to cameleons

Me too.

It looks like older encrypted private keys don't have the header to define how the key is encrypted.

For example here's the head of my old id_rsa

> -----BEGIN ENCRYPTED PRIVATE KEY-----

> M11...

After doing the fix steps from below

< -----BEGIN RSA PRIVATE KEY-----

< Proc-Type: 4,ENCRYPTED

< DEK-Info: AES-256-CBC,444...

<

< tk4...

Found answer here: http://apple.stackexchange.com/questions/106107/cannot-unlock-password-protected -ssh-key-in-os-x-mavericks

Here's the steps:

$ cd ~/.ssh
$ cp id_rsa id_rsa.bck
$ openssl rsa -in id_rsa -out id_rsa
$ openssl rsa -in id_rsa -aes256 -out id_rsa

Whee!

Reply

Answer 4

cameleons Author

Level 1

0 points

Oct 30, 2013 7:48 PM in response to Daveilers

I actually found someone having the similar error:

http://apple.stackexchange.com/questions/106364/osx-ssh-agent-no-password-pastin g-and-problem-with-pkcs8

Apparently, if you followed http://martin.kleppmann.com/2013/05/24/improving-security-of-ssh-private-keys.ht ml then your only way to make it work is to go back to another private key format such as aes256 etc.

Reply