You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Dear all, in order to get my ssh remotes to work I got on a dvc deep dive I didn't ask for. My setup is such that I have the work-horse system which I want to keep in sync with my local installation behind a ssh proxy. Something like this in the ssh config:
Nothing exotic I assume and I can ssh and scp to the workhorse without problems, so I was a bit surprised when I got Too many authentication failures from dvc status -r workhorse.
As hinted by the error message I figured that the ssh agent might be involved, and after fiddling with asyncssh for a while I figured that it is indeed the case. The script below reproduces the error if the agent_path=None is removed.
Great, so now how do we make dvc-ssh to forget about the agent? Well, there comes the actual bug IMHO. The allow_agent = false in the dvc config is not passed to the asyncssh in any capacity as far as I can tell. Verified by running dvc status --pdb -r workhorse. The only mention of allow_agent I found is in the dvc config schema, no traces in either dvc-ssh, sshfs, or asynssh codebases.
The good news is, that I was able to work around this for now with the help of the SSH_AUTH_SOCK environment variable:
$ SSH_AUTH_SOCK='' dvc status -r daint
The text was updated successfully, but these errors were encountered:
Dear all, in order to get my ssh remotes to work I got on a dvc deep dive I didn't ask for. My setup is such that I have the work-horse system which I want to keep in sync with my local installation behind a ssh proxy. Something like this in the ssh config:
In dvc.config I have then something like this:
Nothing exotic I assume and I can
ssh
andscp
to the workhorse without problems, so I was a bit surprised when I gotToo many authentication failures
fromdvc status -r workhorse
.As hinted by the error message I figured that the ssh agent might be involved, and after fiddling with
asyncssh
for a while I figured that it is indeed the case. The script below reproduces the error if theagent_path=None
is removed.Great, so now how do we make dvc-ssh to forget about the agent? Well, there comes the actual bug IMHO. The
allow_agent = false
in the dvc config is not passed to the asyncssh in any capacity as far as I can tell. Verified by runningdvc status --pdb -r workhorse
. The only mention ofallow_agent
I found is in the dvc config schema, no traces in eitherdvc-ssh
,sshfs
, orasynssh
codebases.The good news is, that I was able to work around this for now with the help of the
SSH_AUTH_SOCK
environment variable:$ SSH_AUTH_SOCK='' dvc status -r daint
The text was updated successfully, but these errors were encountered: