0

I'm attempting to establish 2-way SSH communication between a MacBook (192.168.1.3) running OS X 10.9.5 and a desktop computer (192.168.1.2) running Korora 23 (basically Fedora 23 with additional applications, packages, & repositories at installation). I've set up each computer as both a host and a client. Can successfully ssh from OS X client to Linux host, but going from Linux client to OS X host results in this output (I've replaced the port number with xxxxx):

$ ssh MacBook -vvv
OpenSSH_7.2p2, OpenSSL 1.0.2g-fips  1 Mar 2016
debug1: Reading configuration data /home/alex/.ssh/config
debug1: /home/alex/.ssh/config line 1: Applying options for *
debug1: /home/alex/.ssh/config line 4: Applying options for MacBook
debug3: kex names ok: [diffie-hellman-group-exchange-sha256]
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: resolving "192.168.1.3" port xxxxx
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 192.168.1.3 [192.168.1.3] port xxxxx.
debug1: Connection established.
debug1: identity file /home/alex/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/alex/.ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2
debug1: Remote protocol version 2.0, remote software version    OpenSSH_6.2
debug1: match: OpenSSH_6.2 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 192.168.1.3:xxxxx as 'alex'
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: diffie-hellman-group-exchange-sha256,ext-info-c
debug2: host key algorithms: ssh-rsa
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-  ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128- cbc,aes192-cbc,aes256-cbc,arcfour
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256- ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour
debug2: MACs ctos: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160
debug2: MACs stoc: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160
debug2: compression ctos: zlib@openssh.com,zlib,none
debug2: compression stoc: zlib@openssh.com,zlib,none
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: host key algorithms: ssh-rsa
debug2: ciphers ctos: 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: ciphers stoc: 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: MACs ctos: 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: MACs stoc: 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: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: diffie-hellman-group-exchange-sha256
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-md5 compression: zlib@openssh.com
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-md5 compression: zlib@openssh.com
debug1: kex: diffie-hellman-group-exchange-sha256 need=16 dh_need=16
debug1: kex: diffie-hellman-group-exchange-sha256 need=16 dh_need=16
debug3: send packet: type 34
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<3072<8192) sent
debug3: receive packet: type 31
debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
debug2: bits set: 1543/3072
debug3: send packet: type 32
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug3: receive packet: type 33
debug1: got SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: ssh-rsa SHA256:gv0L2YQKQKyddwo09OecUJcy/W5ACn/PxzmhBqh9i4I
debug3: put_host_port: [192.168.1.3]:xxxxx
debug3: put_host_port: [192.168.1.3]:xxxxx
debug3: hostkeys_foreach: reading file "/home/alex/.ssh/known_hosts"
debug3: record_hostkey: found key type RSA in file /home/alex/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from [192.168.1.3]:xxxxx
debug3: hostkeys_foreach: reading file "/home/alex/.ssh/known_hosts"
debug3: record_hostkey: found key type RSA in file /home/alex/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from [192.168.1.3]:xxxxx
debug1: Host '[192.168.1.3]:xxxxx' is known and matches the RSA host key.
debug1: Found key in /home/alex/.ssh/known_hosts:1
debug2: bits set: 1520/3072
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug2: set_newkeys: mode 0
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /home/alex/.ssh/id_rsa (0x5605a87e8660), explicit
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred publickey
debug3: authmethod_lookup publickey
debug3: remaining preferred: 
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/alex/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

On the OS X host in /private/var/log/system.log the only relevant entry seems to be:

MacBook.local sshd[2291]: Connection closed by 192.168.1.2 [preauth]

Ownerships & permissions on Linux:

$ ls -al /home
total 32
drwxr-xr-x.  4 alex alex  4096 Apr  7 15:49 .
dr-xr-xr-x. 18 root root  4096 Feb  6 13:59 ..
drwx------. 28 alex alex  4096 Apr 12 15:07 alex
drwx------.  2 root root 16384 Apr  7 15:41 lost+found
$ ls -al ~/.ssh/
total 32
drwx------.  2 alex alex 4096 Apr 11 16:40 .
drwx------. 28 alex alex 4096 Apr 12 15:07 ..
-rw-------.  1 alex alex  400 Apr  4 23:50 authorized_keys
-rw-------.  1 alex alex 2540 Apr 12 13:48 config
-rw-------.  1 alex alex 1679 Apr 11 16:28 id_rsa
-rw-r--r--.  1 alex alex  394 Apr 11 16:28 id_rsa.pub
-rw-------.  1 alex alex  401 Apr 11 16:40 known_hosts

On OS X:

ls -al ~/.ssh/
total 64
drwx------   8 alex  alex    272 11 Apr 16:43 .
drwxr-xr-x@ 73 alex  staff  2482 12 Apr 15:13 ..
-rw-r--r--@  1 alex  alex   6148 11 Apr 16:43 .DS_Store
-rw-------@  1 alex  alex    719 11 Apr 16:39 authorized_keys.rtf
-rw-------@  1 alex  alex   2556  5 Apr 00:13 config
-rw-------   1 alex  alex   1675  4 Apr 23:04 id_rsa
-rw-r--r--   1 alex  alex    400  4 Apr 23:04 id_rsa.pub
-rw-------   1 alex  alex    401  8 Apr 22:31 known_hosts

Also tried 644 permissions on authorized_keys and known_hosts on both computers. Have re-issued key pairs from the Linux client (where the problem seems to be), but nothing changed. I manually pasted the clients' public keys to the hosts' authorized_keys files, ensuring the key is in a single line; also pasted them into the router's SSH Authentication key field.

Have googled and read for hours; couldn't find much that addresses the following lines, which seem to be the key to the problem:

debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method

My situation of connection closed by client seems to be much less common than connection closed by host.

Would greatly appreciate some help.


Thanks axiac for picking up my silly mistake. Other than seeing the .rtf extension and realising the format was wrong, did any of the other output provide any clues to solving the problem?

I went to Get Info for that file, removed .rtf, opened with iText Express, went to Style and ticked Plain, saved in /.ssh, changed ownership and permissions, removed the other authorized_keys file, rebooted the Mac, and could finally connect from the Linux client! After all the configurations of files, firewalls, permissions - on 2 different OSes, SELinux, router, and maybe other configurations I can’t even remember, it all came down to a stupid font error for 1 file. SSH is a great protocol for transferring files between 2 computers, but definitely unforgiving and not easy to get right. Especially when working with different OSes and wanting to go in both directions. Thanks again.

2

The problem is on your OSX box. You edited the authorized_keys file using the default OSX "text" editor and it automatically appended the .rtf (Rich Text Format) extension to the file.

Rename ~/.ssh/authorized_keys.rtf to ~/.ssh/authorized_keys then open it with a plain text editor (vi, nano etc) and check it doesn't contain RTF markup code.

It should be identical with the file id_rsa.pub from the Linux box. (It can contain more than one public keys on separate lines.)

3
  • This is a very good answers. @Mintonite you should have made your answer more like this, instead of using an answer, to get help to your own problem.
    – Ramhound
    Apr 12 '16 at 20:12
  • Please excuse my unfamiliarity with this system. I attempted to post as a comment, but got a message that it was too long. Tried to give the answer an up-vote but got some message about not enough points. Thanks all for the help & information.
    – Mintonite
    Apr 13 '16 at 2:08
  • @Ramhound - I wasn't using an answer to get help to my own problem. As I thought I made clear, the problem was solved by axiac's answer. I wanted to list the steps I took to put his solution into effect, mainly because it might help others.
    – Mintonite
    Apr 13 '16 at 3:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.