1

I can ssh successfully with password from one mac running Yosemite to another, but when I try to use password authentication for ssh from fedora to either Yosemite system, I never get a password prompt - even if I disable key exchange and explicitly require password authentication. All are on the same local network.

Looking at the differences between ssh -vvv from Fedora and Yosemite, the difference seems to be that Fedora has disabled md5 authentication by default (see Redhat bugzilla 1373835, whereas Yosemite the successful login from Yosemite uses it. However nothing changes if I add

-o MACs=hmac-md5-etm@openssh.com

to the Fedora command line. Upgrading from Yosemite is infeasible (hardware limitations). Do you have any suggestions?

PS could someone with enough points please add Fedora/Redhat, or even linux, tags to this to make it more discoverable (unix, which is the narrowest I can add, is far too broad to be useful)?

When I enter

ssh -vvv -o PreferredAuthentications=keyboard-interactive -o PubkeyAuthentication=no user@host

this is the end of the output I get from Fedora (everything before corresponds fairly accurately between Fedora and Yosemite logins, modulo slightly differing available encryptions and diagnostic formats):

debug1: kex: server->client cipher: aes256-gcm@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: aes256-gcm@openssh.com MAC: <implicit> compression: none
debug1: kex: diffie-hellman-group-exchange-sha256 need=32 dh_need=32
debug1: kex: diffie-hellman-group-exchange-sha256 need=32 dh_need=32
debug3: send packet: type 34
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<8192<8192) sent
Connection closed by 192.168.2.12 port 22

Whereas this is what I see in the corresponding Yosemite output:

debug2: mac_setup: found hmac-md5-etm@openssh.com
debug1: kex: server->client aes128-ctr hmac-md5-etm@openssh.com none
debug2: mac_setup: found hmac-md5-etm@openssh.com
debug1: kex: client->server aes128-ctr hmac-md5-etm@openssh.com 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: 132/256
debug2: bits set: 512/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 28:0d:78:e3:61:3a:72:5e:e5:17:b9:27:0b:ad:33:5f
debug3: load_hostkeys: loading entries for host "192.168.2.12" from file "/Users/rim/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /Users/rim/.ssh/known_hosts:7
debug3: load_hostkeys: loaded 1 keys
debug1: Host '192.168.2.12' is known and matches the RSA host key.
debug1: Found key in /Users/rim/.ssh/known_hosts:7
debug2: bits set: 519/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: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /Users/rim/.ssh/id_rsa (0x0),
debug2: key: /Users/rim/.ssh/id_dsa (0x0),
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred keyboard-interactive
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: 
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password:
1
  • there may be something strange going on with the interfaces I would do a tcpdump and see if that brings up something interesting.
    – Deesbek
    Oct 10 '18 at 22:27
1

It turns out that this is due to a bug in the implementation of openssh in OSX Yosemite (too small message buffers to accommodate the modern range of available cyphers - please see Redhat Bugzilla bug 1373835 for details). The workaround given there, to limit the cypher list by specifying it explicitly, as for instance

ssh -o HostKeyAlgorithms=ssh-rsa,ssh-dss -o KexAlgorithms=diffie-hellman-group1-sha1 -o Ciphers=aes128-cbc,3des-cbc -o MACs=hmac-md5,hmac-sha1 user@host

works for me.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .