SSH Client Closes Connection
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.)
Related videos on Youtube
Mintonite
Updated on September 18, 2022Comments
-
Mintonite over 1 year
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,[email protected],hmac-ripemd160 debug2: MACs stoc: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160 debug2: compression ctos: [email protected],zlib,none debug2: compression stoc: [email protected],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,[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected] debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected] debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 debug2: compression ctos: none,[email protected] debug2: compression stoc: none,[email protected] 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: [email protected] debug1: kex: client->server cipher: aes128-ctr MAC: hmac-md5 compression: [email protected] 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
andknown_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. -
Ramhound about 8 yearsThis 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.
-
Mintonite about 8 yearsPlease 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 about 8 years@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.