|01:21||vagrantc has left IRC (vagrantc!~vagrant@2600:3c01:e000:21:7:77:0:40, Ping timeout: 248 seconds)|
|01:26||vagrantc has joined IRC (vagrantc!~vagrant@2600:3c01:e000:21:7:77:0:40)|
|06:28||woernie has joined IRC (firstname.lastname@example.org)|
|06:35||wyre is back|
|07:04||ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)|
|07:07||wyre is now away: Auto away at Fri Feb 3 07:05:55 2023 UTC|
|07:32||wyre is back|
|07:57||vagrantc has left IRC (vagrantc!~vagrant@2600:3c01:e000:21:7:77:0:40, Quit: leaving)|
I am deploying ltsp remotapp for ltsp clients, the clients are configured to boot chrootless image. There won't be any sensitive or personal running on the clients so the clients share one autologin account with kiosk style NFS homedirs.
If I wish passwordless SSH should I setup one SSH key in the autologin user public keys or one SSH key for each client machine?
I know it works but I can't choose where to keep the keys on the clients for ensuring some security for the autologin account
vsuojanen: for kiosks, it's best not to use sshfs at all. Either use tmpfs home, or if you need server-side space, use e.g. 5 GB home loopback files, one per client, encrypted and mounted over nfs
If you opt to use sshfs after all, use one account per pc, and the "sshfs chroot" trick to restrict their access on the server
You can't use a single home for all of them. Not only it's a security issue, but apps will start losing data or crashing
we are using the /home/nfs/$MAC_ADDRESS/home setup, https://github.com/ltsp/ltsp/wiki/Single-guest-session-over-NFS
That's fine, then why do you need ssh keys?
The app isn't available/published to the client network, that's why I use the ltsp server where we have another network connection with xfreerdp
clients will launch xfreerdp as ltsp remoteapp
You can't use a single account for multiple sessions
I don't get one thing though. If it's all passwordless, that means that anyone can run xfreerdp and get the app without a password
So why don't you make it available to the network?
Is it related to security, or the app just won't run in the clients due to its design?
both actually, the app is now launched with Citrix Workspace and it doesn't work well in the Citrix server.
the app is now moved to separate isolated servers (one virtual machine for each user)
And they get there without a password, or they need to enter a username/password in xfreerdp?
And why would you run xfreerdp over remoteeapps (=very slow) instead of running it directly on the clients?
it's one xfreerdp connection, without passwords. only issue is should I implement the ssh keys and how?
I can't answer while I'm missing key information
Why can't the xfreerdp run directly on the clients?
What you described so far needs no server state, so why does xfreerdp need to run on the ltsp server...
I'm sorry. the rdp connection to the appservers can't be opened in the network where the clients are. I thought it would be easier with ltsp remoteapps
vsuojanen: it sounds like you need net forwarding, not application forwarding
Xorg forwarding means a lot of cpu and network usage due to screen capturing, transfering, rendering, and then again capturing and transfering
While if you use a simple proxy server on the ltsp server, or wireguard, or iptables, you don't have any of these issues, AND you don't need to give a server user account to kiosk users
Of course you can do it with ltsp remoteapps too, but its performance will be a lot worse, and its resource requiremens a lot more
I think you have a point, I already did forwarding but I guess I need more thinking. I haven't luckily spent too much here time with the ltsp remoteapps
thank you alkisg for your support, I appreciate it
yes, thanks I'm now getting back on the idea
the app needed very much work in firewall, then I thought ltsp again would save me with some shortcut
You can use wireguard between the ltsp clients and the ltsp server if you must; it requires only one port; and it'll be a looooot faster than remoteapps
yeah I've heard you and other talking about it here, but hadn't started getting to know it yet
|12:15||highvoltage is back|
vsuojanen: man xfreerdp ==> see the /proxy parameter there, it looks like the fastest and more efficient way forward
So you'd run xfreerdp on the ltsp clients, and a proxy server in the ltsp server
yes. good timing.
hmm. i was doing iptables. i will check that too, thanks
|13:27||wyre is now away: Auto away at Fri Feb 3 13:26:08 2023 UTC|
|13:29||woernie has left IRC (email@example.com, Ping timeout: 260 seconds)|
|13:29||woernie has joined IRC (firstname.lastname@example.org)|
|14:13||woernie has left IRC (email@example.com, Ping timeout: 248 seconds)|
|14:14||woernie has joined IRC (firstname.lastname@example.org)|
|14:18||sunweaver is back|
|14:35||woernie has left IRC (email@example.com, Ping timeout: 255 seconds)|
|14:35||woernie has joined IRC (firstname.lastname@example.org)|
|15:26||sunweaver is now away: not here ...|
|16:14||woernie has left IRC (email@example.com, Ping timeout: 260 seconds)|
|16:14||woernie_ has joined IRC (firstname.lastname@example.org)|
|17:08||wyre is back|
|18:21||wyre is now away: Auto away at Fri Feb 3 18:20:21 2023 UTC|
|18:24||vagrantc has joined IRC (vagrantc!~vagrant@2600:3c01:e000:21:7:77:0:40)|
|21:36||wyre is back|
|21:51||jgee1186922 has left IRC (email@example.com, Quit: The Lounge - https://thelounge.chat)|
|21:53||jgee1186922 has joined IRC (firstname.lastname@example.org)|
|22:42||ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)|
|23:41||sunweaver is back|