Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Cannot find known_hosts file if username has whitespace on windows #162

Open
ysl2 opened this issue Jan 12, 2023 · 3 comments
Open
Labels
bug Something isn't working
Milestone

Comments

@ysl2
Copy link

ysl2 commented Jan 12, 2023

My known_hosts file locates in C:\Users\fa fa\.ssh\known_hosts. There is a whitespace on path (fa fa). I have modified your distant.nvim source code to fix this problem, so the distant.nvim plugin can work normally on my machine. But finally I traced that the plugin called the distant.exe package then the bug occured. I have no idea how to modify rust code format. Need help please :-) thanks a lot!

Click here to check git diff for distant.nvim

Bug occured below after running :DistantLaunch ssh://myname@example_host:22<CR>

image

@chipsenkbeil chipsenkbeil added the bug Something isn't working label Jan 12, 2023
@chipsenkbeil
Copy link
Owner

@ysl2 this is actually an issue with the ssh library we use, wezterm-ssh. You could try changing the backend from ssh2 to libssh and see if that fixes your problem. Otherwise we'd need a fix in wezterm-ssh! 😄

@ysl2
Copy link
Author

ysl2 commented Jan 15, 2023

By the way: The distant.nvim plugin conflicts with jbgutierrez/vim-better-comments
Beacuse of this code line:
https://github.com/chipsenkbeil/distant.nvim/blob/v0.2/lua/distant/autocmd.lua#L18
I removed the vim-better-comments plugin to solve this bug.

I solved this but with a llittle flaw.
At first I noticed your distant executable file contains settings ssh.user_known_hosts_files and ssh.identity_files

.or_else(|| options.get("ssh.user_known_hosts_files"))

.or_else(|| options.get("ssh.identity_files"))

I commented this line below, and directly inject a lua table contains settings into the command.connect() function on my nvim init.lua (and do the same thing in command.open()).

https://github.com/chipsenkbeil/distant.nvim/blob/d6e29ad8d877674f4c4b619b0275961081bc33f2/lua/distant/command.lua#L219

image

Also I linked my C:\Users\fa fa\.ssh\ folder to C:\Users\Public\.ssh\

cd C:\Users\Public
mklink /D .ssh "C:\Users\fa fa\.ssh"

This is the minimal nvim init.lua config:

-- NOTE: An example of local variable `hosts` defined by myself, it contains hosts information.
-- local hosts = {
--   {
--     args = { 'ssh://user1@111.222.333.444:22' },
--     opts = {
--       options = {
--         -- ['ssh.backend'] = 'libssh', -- No need to specify this. Just for example.
--         ['ssh.user_known_hosts_files'] = 'C:\\Users\\Public\\.ssh\\known_hosts',
--         ['ssh.identity_files'] = 'C:\\Users\\Public\\.ssh\\id_rsa'
--       }
--     }
--   },
--   {
--     args = { 'ssh://user2@127.0.0.1:2233' },
--     opts = {} -- Or leave it empty on Linux.
--   }
-- }
function DistantConnect(idx)
  require('distant.command').connect(hosts[idx])
end

function DistantOpen(path)
  require('distant.command').open({ args = { path }, opts = {} })
end

vim.keymap.set('n', '<Leader>dc', ':lua DistantConnect()<Left>')
vim.keymap.set('n', '<Leader>do', ":lua DistantOpen('')<Left><Left>")

It can work now with flaw, beacuse I exposed my private .ssh folder to another public place (which path doesn't contains whitespaces).

I don't think this is an elegant way to solve the problem, but it really can work on windows, espacially when the path contains whitespace. I won't set a whitespace username next time if I have a new computer or after reinstalling windows system, beacuse it's too annoying.

@chipsenkbeil
Copy link
Owner

Hm, this could be an issue at some point when CLI arguments are passed around, but I'm not sure at what point in the codebase it happens. Will leave this as a bug to solve at some point for the distant binary, to be revisited when I have a little more time to dig in.

Thanks for the detailed report and glad you found a workaround for the time being!

@chipsenkbeil chipsenkbeil added this to the Backlog milestone Jan 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants