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

Using vpnns for ssh? #15

Open
benburrill opened this issue Jul 27, 2020 · 3 comments
Open

Using vpnns for ssh? #15

benburrill opened this issue Jul 27, 2020 · 3 comments

Comments

@benburrill
Copy link

I'm on Fedora 32 (kernel 5.6.19-300.fc32.x86_64). When I try running ssh through vpnns, I get the following message:

$ vpnns --name vpnname -- ssh user@hostname
Bad owner or permissions on /etc/ssh/ssh_config.d/50-redhat.conf

The process then exits immediately with status code 0.


I would ideally like to use vpnns, but even using ocproxy I'm having problems. In fact I can't get ocproxy to work at all for anything, whereas vpnns seems to work for everything but ssh.

With ocproxy, I'm running it like openconnect --script-tun --script "ocproxy -L 2222:hostname:22" vpngateway --protocol=gp.
When I connect via ssh -p2222 user@localhost, it just hangs. Running ssh in verbose mode ends in the following:

[...]
debug1: Connecting to localhost [127.0.0.1] port 2222.
debug1: Connection established.
debug1: identity file /home/ben/.ssh/id_rsa type -1
debug1: identity file /home/ben/.ssh/id_rsa-cert type -1
debug1: identity file /home/ben/.ssh/id_dsa type -1
debug1: identity file /home/ben/.ssh/id_dsa-cert type -1
debug1: identity file /home/ben/.ssh/id_ecdsa type -1
debug1: identity file /home/ben/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/ben/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/ben/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/ben/.ssh/id_ed25519 type -1
debug1: identity file /home/ben/.ssh/id_ed25519-cert type -1
debug1: identity file /home/ben/.ssh/id_ed25519_sk type -1
debug1: identity file /home/ben/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/ben/.ssh/id_xmss type -1
debug1: identity file /home/ben/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.3
[hangs indefinitely until I stop openconnect]

Adding the -v flag to ocproxy doesn't seem to give any more info.

Similar hanging behavior occurs when I try forwarding the address of an http server (-L 8888:hostname:80) and trying to open localhost:8888 it in firefox. In this case, I am actually able to get it to work with vpnns though when I start a new instance of firefox under vpnns.


Any suggestions you can give as to how to use ssh with ocproxy/vpnns would be greatly appreciated.

@cernekee
Copy link
Owner

$ vpnns --name vpnname -- ssh user@hostname
Bad owner or permissions on /etc/ssh/ssh_config.d/50-redhat.conf

I don't get this error on Ubuntu Bionic. If you use something like ssh -F ~/.ssh/config to tell the client to ignore the systemwide /etc/ssh configuration files, does that help? Might need to play around with it a bit; if nothing works for you I can set up a Fedora VM locally and give it a shot.

One quirk I do see is that under vpnns, ssh tries to save the remote's hostkey to ~root/.ssh/known_hosts. $HOME still points to the unprivileged user's homedir but ssh seems to be looking it up from /etc/passwd.

I can't get ocproxy to work at all for anything,

ocproxy --tcpdump should show what's happening on the IP level, whether the three-way handshake completed, etc.

@benburrill
Copy link
Author

benburrill commented Jul 27, 2020

Thank you! ssh -F ~/.ssh/config does work, although I do get a bunch of permission denied messages like load pubkey "/root/.ssh/id_rsa": Permission denied and as you pointed out, it tries to add the host to /root/.ssh/known_hosts which also fails.

ocproxy --tcpdump

Hmmm, I installed ocproxy from the fedora repos which I guess are out of date. Weirdly, vpnns --version reports 1.70, but the ocproxy package version is 1.60, and ocproxy does not have the --tcpdump option. I will compile from source later today and see if I have any more luck with ocproxy or otherwise see what tcpdump says. But for right now at least I have something that kinda does what I want with vpnns.

@benburrill
Copy link
Author

Yup, the fedora version was definitely at fault. When built from source, ocproxy works perfectly fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants