Closed xavier83 closed 7 years ago
I never tested it on archlinux. In fact I'm very unfamiliar with archlinux.
I'll have to look at the code to understand that this might actually mean. I'll report my findings here shortly, and hopefully try and go for a fix.
@xavier83 It'll be not very easy to debug it, but we should definitely give it a go.
I'll explain first what happens:
When trying to "guess" your username, nm-ssh-service clearly hits an error. I've never run this on arch linux, but perhaps a full debug dump (see README.md to understand how to provide one) can be useful. Then we can see what is the SSH agent socket and speculate why it can't get its ownership.
I think that regardless, if that fails, nm-ssh-service should use root's known_hosts file. I'll probably amend it soon.
I encountered the same error, if you never connected to the host as root, the service gets stuck at the accept key prompt which appears (only?) when you are running it in debug mode. After accepting the key the firts time the vpn works.
Here's the output:
** (nm-ssh-service:3603): WARNING **: Error getting ssh-agent socket ownership: 14
** (nm-ssh-service:3603): WARNING **: Using root's .ssh/known_hosts
** Message: -o
** Message: ServerAliveInterval=10
** Message: -o
** Message: TCPKeepAlive=yes
** Message: ssh started with pid 3618
** Message: OpenSSH_7.5p1, OpenSSL 1.1.0f 25 May 2017
** Message: debug1: Reading configuration data /etc/ssh/ssh_config
** Message: debug1: Connecting to GATEWAY port 22.
** Message: debug1: Connection established.
** Message: debug1: permanently_set_uid: 0/0
** Message: debug1: identity file /home/-/.ssh/id_rsa type 1
** Message: debug1: key_load_public: No such file or directory
** Message: debug1: identity file /home/-/.ssh/id_rsa-cert type -1
** Message: debug1: Enabling compatibility mode for protocol 2.0
** Message: debug1: Local version string SSH-2.0-OpenSSH_7.5
** Message: debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4p1 Debian-10
** Message: debug1: match: OpenSSH_7.4p1 Debian-10 pat OpenSSH* compat 0x04000000
** Message: debug1: Authenticating to GATEWAY:22 as 'root'
** Message: debug1: SSH2_MSG_KEXINIT sent
** Message: debug1: SSH2_MSG_KEXINIT received
** Message: debug1: kex: algorithm: curve25519-sha256
** Message: debug1: kex: host key algorithm: ecdsa-sha2-nistp256
** Message: debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
** Message: debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
** Message: debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
** Message: debug1: Server host key: ecdsa-sha2-nistp256 SHA256:VFUW8dC3tqxOqNloW2nqgFfpwnyaqd1+xdOvzqpcNXE
The authenticity of host 'GATEWAY' can't be established.
ECDSA key fingerprint is SHA256:VFUW8dC3tqxOqNloW2nqgFfpwnyaqd1+xdOvzqpcNXE.
Are you sure you want to continue connecting (yes/no)? yes
** Message: Warning: Permanently added 'GATEWAY' (ECDSA) to the list of known hosts.
** Message: debug1: rekey after 134217728 blocks
** Message: debug1: SSH2_MSG_NEWKEYS sent
** Message: debug1: expecting SSH2_MSG_NEWKEYS
** Message: debug1: SSH2_MSG_NEWKEYS received
** Message: debug1: rekey after 134217728 blocks
** Message: debug1: SSH2_MSG_EXT_INFO received
** Message: debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
** Message: debug1: SSH2_MSG_SERVICE_ACCEPT received
** Message: debug1: Authentications that can continue: publickey,password
** Message: debug1: Next authentication method: publickey
** Message: debug1: Offering RSA public key: /home/-/.ssh/id_rsa
** Message: debug1: Server accepts key: pkalg ssh-rsa blen 279
** Message: debug1: Authentication succeeded (publickey).
** Message: Authenticated to GATEWAY ([GATEWAY]:22).
** Message: debug1: Requesting tun unit 1 in mode 1
** Message: debug1: sys_tun_open: tun1 mode 1 fd 4
** Message: debug1: channel 0: new [tun]
** Message: debug1: channel 1: new [client-session]
** Message: debug1: Requesting no-more-sessions@openssh.com
** Message: debug1: Entering interactive session.
** Message: debug1: pledge: network
** Message: debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
** Message: Local device: 'tun1'
** Message: Remote gateway: 'GATEWAY'
** Message: Remote IP: '10.7.0.1'
** Message: Local IP: '10.7.0.2'
** Message: Netmask: '32'
** (nm-ssh-service:3603): WARNING **: netmask unset.
** Message: debug1: Sending command: /sbin/ifconfig tun160 inet 10.7.0.1 netmask 32 pointopoint 10.7.0.2 mtu 1500;
** Message: bash: /sbin/ifconfig: No such file or directory
** Message: debug1: client_input_channel_req: channel 1 rtype exit-status reply 0
** Message: debug1: client_input_channel_req: channel 1 rtype eow@openssh.com reply 0
** Message: debug1: channel 1: free: client-session, nchannels 2
** Message: Terminated ssh daemon with PID 3618.
** Message: debug1: channel 0: free: tun, nchannels 1
** Message: debug1: fd 0 clearing O_NONBLOCK
** Message: debug1: fd 1 clearing O_NONBLOCK
** Message: debug1: fd 2 clearing O_NONBLOCK
** Message: Killed by signal 15.
** (nm-ssh-service:3603): WARNING **: ssh exited with error code 255
I encountered the same error, if you never connected to the host as root, the service gets stuck at the accept key prompt which appears (only?) when you are running it in debug mode. After accepting the key the firts time the vpn works.
I should probably document that you need to accept the host key before the VPN can actually succeed. It can be overwritten by specifying in the options. So running:
$ ssh root@YOUR_HOST
<ACCEPT KEY>
This is probably required. I'll amend the README shortly.
Hopefully f80495e makes things a bit clearer. @arshesney @xavier83 ?
Oh ya, that definitely makes it clear.
To be honest, I kind of assumed that you would try to ssh root@TARGET_HOST
, even to just configure things. Or at least ssh someuser@TARGET_HOST
to configure it. But it's better to be explicit and say what's required. So thanks for the feedback!
Ok, seem like the issue is not on NetworkManager-ssh but wrong configuration. apparently if you use someuser@TARGET_HOST , the host is probably rejecting the tun request as it requires root(equivalent?) permission to create tun device.
Ok, seem like the issue is not on NetworkManager-ssh but wrong configuration. apparently if you use someuser@TARGET_HOST , the host is probably rejecting the tun request as it requires root(equivalent?) permission to create tun device.
Unfortunately yes. I think it's possible without using root, but kind of tricky. I was looking into openssh at the time - thinking it can be done easily, but generally to open new devices (tun/tap) you'll need 0 uid privileges, so I just let it go at the time.
I got the following journal log when trying to connect using NetworkManager-ssh. I am using kde-plasma on archlinux with NetworkManager-ssh install