Thanks for the clarifications.I simplified the setup (non-sudo user for proxy;
same usernames on both machines) to be able to debug. But it still does not
work.
Multifile authentication on proxy succeeds. But seems like it not using correct
ssh command line to connect to backened server. Logs on the proxy are attached
below. There are no logs on the backend xpra server. The sshd logs on the
backend server says that the connection was closed by the proxy [preauth].
1. I now start proxy as non-sudo user1 on machine1 and attach it to
non-priveldged tcp port1. Give it a display number disp1.
xpra proxy :disp1 --bind-tcp=0.0.0.0:port1
--tcp-auth=multifile:filename=path-to-multifile -d auth
Machine1 is running newer version of XPRA (xpra proxy version 1.0-r13637).
multifile looks like following :-
user1|pswd1|1000|1000|ssh:user1@machine2:disp2||
2. start an xpra server on machine2 under the user account with with same
username user1. Give it a display number disp2.
xpra start :disp2DISPLAY=:disp2 xeyes &
Machine2 is using older version of XPRA (0.15.10 r11439). Not sure if this
creates any problems.
3. Try attaching to backend server on machine2 from machine 1 using ssh
transport and public key authentication.
xpra attach ssh:user1@machine2:disp2
This works fine. So seems like different versions are compatible.
4. Try attaching from xpra clent running on machine3 (win7 machine).
xpra attach --password-file=pswd.txt tcp:user1@machine1:port1
OR
xpra attach tcp:user1:pswd1@machine1:port1
Proxy Logs :-
2016-09-16 11:03:55,160 New tcp connection received from
IP3:1834^[[0m^[[36m2016-09-16 11:03:55,160 socktype=tcp,
authclass=('multifile', <class'xpra.server.auth.multifile_auth.Authenticator'>,
{'filename': 'path-to-multifile2.txt'}),encryption=,
keyfile=^[[0m^[[36m2016-09-16 11:03:55,161 creating authenticator
('multifile',<class 'xpra.server.auth.multifile_auth.Authenticator'>,
{'filename': 'path-to-multifile2.txt'})with username=user1^[[0m^[[36m2016-09-16
11:03:55,161 multifile=multi passwordfile^[[0m^[[36m2016-09-16 11:03:55,161
processing authentication withmulti password file, response=None, client_salt=,
challenge_sent=False^[[0m^[[36m2016-09-16 11:03:55,161
challenge:('dc743d422f664331be64f48c22913d8144207dcab83c4ec2bdd6ed21a88a7567','hmac')^[[0m2016-09-16
11:03:55,161 Authentication required by multipassword file authenticator
module^[[0m2016-09-16 11:03:55,162 sending challenge for 'user1' using hmac
digest^[[0m^[[36m2016-09-16 11:03:55,271 processing authentication withmulti
password file, response=864f4fff84caf265599ff84726295167,
client_salt=38643238663234613531386134353065386363383266363131346438393164356338383537383062303665363431396162633432363735643634643066346133,challenge_sent=True^[[0m^[[36m2016-09-16
11:03:55,271 mtime(path-to-multifile2.txt)=1473994487.22^[[0m^[[36m2016-09-16
11:03:55,271 loaded 184 bytes from
'path-to-multifile2.txt'^[[0m^[[36m2016-09-16 11:03:55,272 line 1:
^[[36m2016-09-1611:03:55,272 found 7 fields^[[0m…. Something here
…hex(salt)=5c07050c5556005307570e57000603545a06550c54520e5203065d090a555c04570c0a05005c5303520e565500545a530007500453530755570c5c5151015704,hash=864f4fff84caf265599ff84726295167^[[0m^[[36m2016-09-16
11:03:55,272 authentication challengepassed^[[0m^[[36m2016-09-16 11:03:55,272
start_proxy(Protocol(tcpsocket: internalIP1:port1<- IP3:1834), {..}, None)
found sessions: (1000,1000, ['ssh:user1@IP2:disp2'], {},
{})^[[0m^[[36m2016-09-16 11:03:55,273 start_proxy:proxy-virtual-display=:disp1
(ignored), user specified display=None,
founddisplays=['ssh:user1@IP2:disp2']^[[0m2016-09-16 11:03:55,499 proxy video
encoders: x264^[[0m2016-09-16 11:03:55,499 new proxy instance
started^[[0m2016-09-16 11:03:55,499 for client tcp socket: internalIP1:port1<-
IP3:1834^[[0m2016-09-16 11:03:55,499 and server
Pipe(ssh:user1@IP2:disp2)^[[0m2016-09-16 11:03:55,500 proxy instance now also
availableusing unix domain socket:^[[0m2016-09-16 11:03:55,500
path-to-.xpra/ip-internal-IP1-proxy-11703^[[0m^[[31m2016-09-16 11:03:55,503
Error: SSH connection to thexpra server failed^[[0m^[[31m2016-09-16
11:03:55,504 check your username, hostname, displaynumber, firewall,
etc^[[0m^[[31m2016-09-16 11:03:55,504 for server:
ssh:user1@IP2:disp2^[[0m^[[31m2016-09-16 11:03:55,504 the command line used
was:^[[0m^[[31m2016-09-16 11:03:55,504 ssh -x -l user1 -T IP2 sh -c
'xprainitenv;~/.xpra/run-xpra _proxy :disp2 || $XDG_RUNTIME_DIR/xpra/run-xpra
_proxy:disp2 || xpra _proxy :disp2'^[[0m2016-09-16 11:03:55,504 stop(server
connection lost,Protocol(None))^[[0m2016-09-16 11:03:55,505 removing socket
path-to-.xpra/ip-internal-IP1-proxy-11703^[[0m2016-09-16 11:03:55,505 proxy
instance 11703 stopped^[[0m
Regards, Mukul ( https://sites.google.com/site/mukulagrawal )
On Thursday, September 15, 2016 10:24 AM, Antoine Martin via shifter-users
<shifter-users@lists.devloop.org.uk> wrote:
On 15/09/16 11:39, Mukul Agrawal via shifter-users wrote:
> If I want xpra proxy on machine1 to connect to xpra server on machine2 using
> ssh with public key authentication and no password, then how should I set it
> up?
I have not tested this, but SSH connections from the proxy should be
using the public key of the user running the proxy server process and
not the key of the user you authenticate as. (which may not have a user
account at all on the system running the proxy)
> Public keys are already in default locations and xpra is able to attach
> directly from machine2 to machine 1 using standard format: xpra attach
> ssh:username@machine1:display.
I thought the server you wanted to connect to was "machine 2" and not
the other way around?
> But when I try to connect via proxy from client machine3, proxy is not being
> able to authenticate.
Have you checked your ssh server logs for an answer?
> It sends the challenge but then there is no log after that.
Please share the log sample up to that point to help clarify things.
Note: when using SSH connections, the server does not need to use
another socket authentication module. That's usually just redundant.
> I am using multifile like this :-
> username|pswd|1000|1000|ssh:machine1:display||
> and attach command from machine3 like this:-xpra attach
> tcp:username:pswd@machine2:proxyPORT
>
> Are the usernames and passwords actually associated with login accounts on
> the target machine or their significance is only with respect to multifile
> resolution?
It depends: if the proxy server runs as root, each proxied connection
will run as the uid and gid you defined. (ie: 1000 above)
But the connection to the backend server is made before changing uid, so
the ssh key used will not be the one of the user specified in multifile.
If you don't mind using SSH with passwords, you should be able to use
something like this (untested):
|username|pswd|1000|1000|ssh/username2:password2@machine2/display||
We could also change the code to:
* add support for ssh options to multifile, so you could specify the
keyfile for each user
* change the ordering so the connection to the backend server happens
after changing uid and gid (but this would only work with the proxy
running as root)
Feel free to create tickets for this.
> Can password be left blank for public key authentication?
That doesn't make sense: the password in multifile is for authentication
to the proxy, not to the backend server.
Unless you're trying to connect via ssh to your proxy? (but why?)
Cheers
Antoine
>
> Thanks.
>
> _______________________________________________
> shifter-users mailing list
> shifter-users@lists.devloop.org.uk
> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>
_______________________________________________
shifter-users mailing list
shifter-users@lists.devloop.org.uk
http://lists.devloop.org.uk/mailman/listinfo/shifter-users
_______________________________________________
shifter-users mailing list
shifter-users@lists.devloop.org.uk
http://lists.devloop.org.uk/mailman/listinfo/shifter-users
