I have several local machines that, while working, I frequently use ssh to do something on a different machine. While on that second machine, I may even use ssh to do something on a third machine. All of this works exactly as it should.
If I use JuiceSSH on my Android phone to contact one of my local machines, that also works well. But if, while connected, I try to start an ssh session to a different local machine, it simply times out. The last message seen with "ssh -vvv" is, "debug3: ssh_get_authentication_socket_path:". Up to that point, the output of "ssh -vvv" is identical when running successfully between two local machines without using JuiceSSH.
If instead of trying to start an ssh session immediately upon connecting with JuiceSSH, I first use sudo to become root on the local machine and then try to ssh to another local machine, that works perfectly (provided, of course, that the second machine permits root ssh login). The second ssh session also works if I simply run "sudo su {me} -c ssh" so becoming root isn't the key.
Summary: JuiceSSH -> user@machine1 -> user@machine2 :: FAILS JuiceSSH -> user@machine1 -> sudo on machine1 -> user@machine2 :: WORKS
I've examined the output of the set command for all of these situations and can't find any variables that are different that seem relevant. (Of course, $PPID and similar variables are different.) Can anyone suggest what could be the issue? Or what other tests might be helpful?
On Fri, Aug 23, 2024 at 5:44 PM Dave Close dave@compata.com wrote:
I have several local machines that, while working, I frequently use ssh to do something on a different machine. While on that second machine, I may even use ssh to do something on a third machine. All of this works exactly as it should.
If I use JuiceSSH on my Android phone to contact one of my local machines, that also works well. But if, while connected, I try to start an ssh session to a different local machine, it simply times out. The last message seen with "ssh -vvv" is, "debug3: ssh_get_authentication_socket_path:". Up to that point, the output of "ssh -vvv" is identical when running successfully between two local machines without using JuiceSSH.
If instead of trying to start an ssh session immediately upon connecting with JuiceSSH, I first use sudo to become root on the local machine and then try to ssh to another local machine, that works perfectly (provided, of course, that the second machine permits root ssh login). The second ssh session also works if I simply run "sudo su {me} -c ssh" so becoming root isn't the key.
Summary: JuiceSSH -> user@machine1 -> user@machine2 :: FAILS JuiceSSH -> user@machine1 -> sudo on machine1 -> user@machine2 :: WORKS
I've examined the output of the set command for all of these situations and can't find any variables that are different that seem relevant. (Of course, $PPID and similar variables are different.) Can anyone suggest what could be the issue? Or what other tests might be helpful?
I hope the sudo did not create directories with the wrong ownership. And SSH sometimes fails if directory permissions are not expected, like allow Others read or write access to .ssh/ directory.
At this point, I would visit each machine and:
mkdir -p ~/.ssh chown -R dclose:dclose ~/.ssh chmod -R o-rwx ~/.ssh
Jeff
Jeffrey Walton wrote:
At this point, I would visit each machine and:
mkdir -p ~/.ssh chown -R dclose:dclose ~/.ssh chmod -R o-rwx ~/.ssh
That would be guaranteed to cause failure. For example, my private keys cannot have 0777 permissions!
I wrote:
I have several local machines that, while working, I frequently use ssh to do something on a different machine. While on that second machine, I may even use ssh to do something on a third machine. All of this works exactly as it should.
If I use JuiceSSH on my Android phone to contact one of my local machines, that also works well. But if, while connected, I try to start an ssh session to a different local machine, it simply times out. The last message seen with "ssh -vvv" is, "debug3: ssh_get_authentication_socket_path:". Up to that point, the output of "ssh -vvv" is identical when running successfully between two local machines without using JuiceSSH.
If instead of trying to start an ssh session immediately upon connecting with JuiceSSH, I first use sudo to become root on the local machine and then try to ssh to another local machine, that works perfectly (provided, of course, that the second machine permits root ssh login). The second ssh session also works if I simply run "sudo su {me} -c ssh" so becoming root isn't the key.
Summary: JuiceSSH -> user@machine1 -> user@machine2 :: FAILS JuiceSSH -> user@machine1 -> sudo on machine1 -> user@machine2 :: WORKS
I've examined the output of the set command for all of these situations and can't find any variables that are different that seem relevant. (Of course, $PPID and similar variables are different.) Can anyone suggest what could be the issue? Or what other tests might be helpful?
The solution was provided through the openssh mailing list. I've added an alias to my system and will use it when connecting from JuiceSSH:
alias xssh="unset SSH_AUTH_SOCK; ssh"
On 8/23/24 3:17 PM, Dave Close wrote:
Jeffrey Walton wrote:
At this point, I would visit each machine and:
mkdir -p ~/.ssh chown -R dclose:dclose ~/.ssh chmod -R o-rwx ~/.ssh
That would be guaranteed to cause failure. For example, my private keys cannot have 0777 permissions!
I think you're misinterpreting that command. It *removes* all "other" permissions from the files. I'm not sure what the point of it is, but it won't harm anything.
On Sat, Aug 24, 2024 at 3:24 AM Samuel Sieb samuel@sieb.net wrote:
On 8/23/24 3:17 PM, Dave Close wrote:
Jeffrey Walton wrote:
At this point, I would visit each machine and:
mkdir -p ~/.ssh chown -R dclose:dclose ~/.ssh chmod -R o-rwx ~/.ssh
That would be guaranteed to cause failure. For example, my private keys cannot have 0777 permissions!
I think you're misinterpreting that command. It *removes* all "other" permissions from the files. I'm not sure what the point of it is, but it won't harm anything.
SSH server will refuse a connection from the user if the permissions on the .ssh/ directory, keys or authorized_keys are too loose. See, for example, https://stackoverflow.com/q/67000681.
Jeff
On 8/24/24 12:31 AM, Jeffrey Walton wrote:
On Sat, Aug 24, 2024 at 3:24 AM Samuel Sieb samuel@sieb.net wrote:
On 8/23/24 3:17 PM, Dave Close wrote:
Jeffrey Walton wrote:
At this point, I would visit each machine and:
mkdir -p ~/.ssh chown -R dclose:dclose ~/.ssh chmod -R o-rwx ~/.sshThat would be guaranteed to cause failure. For example, my private keys cannot have 0777 permissions!
I think you're misinterpreting that command. It *removes* all "other" permissions from the files. I'm not sure what the point of it is, but it won't harm anything.
SSH server will refuse a connection from the user if the permissions on the .ssh/ directory, keys or authorized_keys are too loose. See, for example, https://stackoverflow.com/q/67000681.
Sure, but ssh was working and using sudo isn't going to add permissions to the files. (It's not even going to use those files.) But the solution was already found anyway, so this is all irrelevant.
-
Dave Close -
Jeffrey Walton -
Samuel Sieb