Help with error "Bad owner or permissions on /home/username/.ssh/config"

[KronosTheLate]

I am able to run ~ $ssh pi@192.168.4.2 with no problem to connect passwordless to my RaspberryPi. When I try to run connect_remote on the client, I get the following error:

julia> connect_remote("pi@192.168.4.2", tunnel=:ssh)
┌ Warning: Tunnel output
│   errors =
│    Bad owner or permissions on /home/dennishb/.ssh/config
│    
└ @ RemoteREPL ~/.julia/packages/RemoteREPL/BFqrB/src/tunnels.jl:31
┌ Error: Exceeded maximum socket connection attempts
└ @ RemoteREPL ~/.julia/packages/RemoteREPL/BFqrB/src/tunnels.jl:87
ERROR: IOError: connect: connection refused (ECONNREFUSED)
Stacktrace:
 [1] wait_connected(x::Sockets.TCPSocket)
   @ Sockets ~/.julia/juliaup/julia-1.9.1+0.x64.linux.gnu/share/julia/stdlib/v1.9/Sockets/src/Sockets.jl:528
 [2] connect
   @ ~/.julia/juliaup/julia-1.9.1+0.x64.linux.gnu/share/julia/stdlib/v1.9/Sockets/src/Sockets.jl:563 [inlined]
 [3] connect
   @ ~/.julia/juliaup/julia-1.9.1+0.x64.linux.gnu/share/julia/stdlib/v1.9/Sockets/src/Sockets.jl:549 [inlined]
 [4] connect_via_tunnel(host::String, port::Int64; retry_timeout::Int64, tunnel::Symbol, ssh_opts::Cmd, region::Nothing, namespace::Nothing)
   @ RemoteREPL ~/.julia/packages/RemoteREPL/BFqrB/src/tunnels.jl:80
 [5] setup_connection!(conn::RemoteREPL.Connection)
   @ RemoteREPL ~/.julia/packages/RemoteREPL/BFqrB/src/client.jl:138
 [6] #Connection#38
   @ ~/.julia/packages/RemoteREPL/BFqrB/src/client.jl:128 [inlined]
 [7] Connection
   @ ~/.julia/packages/RemoteREPL/BFqrB/src/client.jl:120 [inlined]
 [8] connect_remote(host::String, port::Int64; tunnel::Symbol, ssh_opts::Cmd, region::Nothing, namespace::Nothing)
   @ RemoteREPL ~/.julia/packages/RemoteREPL/BFqrB/src/client.jl:487
 [9] top-level scope
   @ REPL[4]:1

on the server (Pi), there is a Julia process running, connected with SSH, with using RemoteREPL having been run. It may be noteworthy that I am using 1.6 on the server (Pi), and 1.9 on the client, which could be the problem. However, the error message indicates that something else is the problem.

The contents of .ssh.config (on the server side) were

Host 192.168.4.2
  HostName 192.168.4.2
  User pi

I do not recall having configured this manually. I tried adding the lines

Host 192.168.4.2
  User pi
  IdentityFile ~/.ssh/id_rsa

to the .ssh/config file on the client, but that did not change anything.

Any help on what may have gone wrong?

[c42f]

Bad owner or permissions on /home/dennishb/.ssh/config

What are the owner and permissions on this file?

It may be noteworthy that I am using 1.6 on the server (Pi), and 1.9 on the client

This will be a problem because Serialization is not back/forward between Julia versions. But it's not the problem you're having right now.

[KronosTheLate]

Is this screenshot sufficient to inform you about the permissions? I can edit the file without SUDO, and I am on a personal laptop as the only user.

[KronosTheLate]

In case it is relevant, the command was run from a Julia process started from within VSCode.
Edit: Also, the only SSH changes inside .ssh on the server (Pi) side is that the SSH keys have been moved over by running ssh-copy-id pi@192.168.4.2 from the client. So if the content of .ssh/config is important on the server side, that could also be where it is going wrong.

[c42f]

Is this screenshot sufficient to inform you about the permissions?

It looks ok. At least that's what my .ssh/config permissions seem to be.

Try ls -lh ~/.ssh and ls -lhd ~/.ssh on both client and server sides maybe?

You can see the ssh command which is being executed by looking in the ssh_tunnel() function and trying to execute that same command manually.

[c42f]

Actually I think those permissions were somehow broken on my end too - I haven't used RemoteREPL since I reinstalled my laptop.

I suggest you run the following command on both client and server to fix permissions:

chmod go-rwx ~/.ssh/*

[c42f]

Also, you can get the exact ssh tunnel command by turning on debug logging on the client like this:

julia> using RemoteREPL, Logging

julia> global_logger(ConsoleLogger(Logging.Debug));

julia> connect_repl("xyz");
┌ Debug: Connecting SSH tunnel to remote address xyz via ssh tunnel to 27754
│   ssh_cmd = `/home/c42f/.julia/artifacts/cf570328554ecb898e625367a9c9fb2c01f55267/bin/ssh -o ExitOnForwardFailure=yes -o ServerAliveInterval=60 -N -L 127.0.0.1:39133:localhost:27754 xyz`
└ @ RemoteREPL ~/.julia/dev/RemoteREPL/src/tunnels.jl:45
REPL mode remote_repl initialized. Press > to enter and backspace to exit.

[KronosTheLate]

Actually I think those permissions were somehow broken on my end too - I haven't used RemoteREPL since I reinstalled my laptop.

I suggest you run the following command on both client and server to fix permissions:

chmod go-rwx ~/.ssh/*

Are you sure this is correct? From https://stackoverflow.com/questions/50735833/what-is-the-difference-between-chmod-go-rwx-and-chmod-700, one answer states that "go-rwx removes read, write, execute permissions from the group and other users. It will not change permissions for the user that owns the file.", which does not seem like what we want to me.

Based on https://www.ibm.com/docs/en/aix/7.2?topic=c-chmod-command, I am tempted to run chmod a+wrx ~/.ssh/*, which I believe should allow everyone (User, Groups, Others) to write, read and execute anything inside .ssh. But perhaps that is to permissive, and is a security vulnerability? Perhaps it is sufficient to only change the permissions for the current user, by doing chmod u+wrx ~/.ssh/* instead?

I am also just now seeing that my proposed command is to add permission for the user, while yours removes them for groups and others. They are complimentary in a way, so perhaps you meant what you suggested. Does that mean that you believe that a potential fix is to remove permissions for others? It looks like both can be performed by running chmod u=rwx,go= ~/.ssh/*. This is based on the description of = in the linked guide, which states that an equals "Clears the selected permission field and sets it to the permission specified. If you do not specify a permission following =, the chmod command removes all permissions from the selected field."

[KronosTheLate]

Edit: This comment was long and all wrong, so I packed it into a foldable menu. See later comments.

> Also, you can get the exact ssh tunnel command by turning on debug logging on the client like this

I think we have something. The SSH command being run is as follows

ssh_cmd = `/home/dennishb/.julia/artifacts/cf570328554ecb898e625367a9c9fb2c01f55267/bin/ssh -o ExitOnForwardFailure=yes -o ServerAliveInterval=60 -N -L 127.0.0.1:46163:localhost:27754 xyz`

Which is different from the one I normally use:

Independent Study Activity $which ssh
/usr/bin/ssh

Furthermore, when I attempt to excecute the one actually used, I get the permission error!

Independent Study Activity $/home/dennishb/.julia/artifacts/cf570328554ecb898e625367a9c9fb2c01f55267/bin/ssh
/home/dennishb/.julia/artifacts/cf570328554ecb898e625367a9c9fb2c01f55267/bin/ssh: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory

So it seems like the artifact has the wrong permissions.

I tried setting them to my final proposed command in the comment above:

Independent Study Activity $sudo chmod u=rwx,go= /home/dennishb/.julia/artifacts/cf570328554ecb898e625367a9c9fb2c01f55267/bin/ssh
[sudo] password for dennishb:
Independent Study Activity $/home/dennishb/.julia/artifacts/cf570328554ecb898e625367a9c9fb2c01f55267/bin/ssh
/home/dennishb/.julia/artifacts/cf570328554ecb898e625367a9c9fb2c01f55267/bin/ssh: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory

But as you can see, the permissions error persisted. Below is the actual permissions:

Independent Study Activity $ls -l /home/dennishb/.julia/artifacts/cf570328554ecb898e625367a9c9fb2c01f55267/bin/
total 10428
-r-xr-xr-x 1 dennishb dennishb  880112 Apr  1 20:13 scp
-rwx------ 1 dennishb dennishb 3272840 Apr  1 20:13 ssh
-r-xr-xr-x 1 dennishb dennishb 1485176 Apr  1 20:13 ssh-add
-r-xr-xr-x 1 dennishb dennishb 1305152 Apr  1 20:13 ssh-agent
-r-xr-xr-x 1 dennishb dennishb 1916664 Apr  1 20:13 ssh-keygen
-r-xr-xr-x 1 dennishb dennishb 1809096 Apr  1 20:13 ssh-keyscan

I also tried just setting all permissions for the file, but the same error presisted:

Independent Study Activity $sudo chmod a=rwx /home/dennishb/.julia/artifacts/cf570328554ecb898e625367a9c9fb2c01f55267/bin/ssh
Independent Study Activity $ls -l /home/dennishb/.julia/artifacts/cf570328554ecb898e625367a9c9fb2c01f55267/bin/
total 10428
-r-xr-xr-x 1 dennishb dennishb  880112 Apr  1 20:13 scp
-rwxrwxrwx 1 dennishb dennishb 3272840 Apr  1 20:13 ssh
-r-xr-xr-x 1 dennishb dennishb 1485176 Apr  1 20:13 ssh-add
-r-xr-xr-x 1 dennishb dennishb 1305152 Apr  1 20:13 ssh-agent
-r-xr-xr-x 1 dennishb dennishb 1916664 Apr  1 20:13 ssh-keygen
-r-xr-xr-x 1 dennishb dennishb 1809096 Apr  1 20:13 ssh-keyscan
Independent Study Activity $/home/dennishb/.julia/artifacts/cf570328554ecb898e625367a9c9fb2c01f55267/bin/ssh
/home/dennishb/.julia/artifacts/cf570328554ecb898e625367a9c9fb2c01f55267/bin/ssh: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory

In fact, the error is error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory. So it is not about the permissions to the SSH file, but rether to a shared libcrypto file, right?

[KronosTheLate]

You were absolutely right in your command about removing rather than adding premissions. Also about that the permissions should be changed for ~/.ssh/config. I did both of these wrong.

The command that fixed the problem was

chmod go-w /home/dennishb/.ssh/config

I the reason I finally got it was because of a comment from here

So translating it to the English, means that the config file must be owned by root or by the user running the ssh and can not be writable by any group or other users.

Which made me understand that I had to remove write permissions for everyone but the user. So the issue is fixed! (with the fix you offered a few comments back). I will keep this issue open until an addition has been made to the docs about this problem. Perhaps a "Troubleshooting" section would be nice?