-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
FR: Fast user switching #713
Comments
Although not at the same time, I find it useful to be able to switch accounts to access different groups of machines from my laptop. Prior to 1.0, with the tailscale-linux-switchuser tool I was saving copies of relay.conf for different email addresses and setting I tried to save this new file for different email addresses similarly, and copy the right one for the address I want to login to tailscale with, but that didn't seem to work even after restarting tailscaled. Is there an easy way to switch accounts in the current setup? I thought I'll ask before trying to dive down into finding the details of the new file :) |
Note: related issue: #183 |
@happyalu, a workaround for user switching is to install the latest unstable tailscale stream (at least version 1.1.372) and try the |
Related issue: #662 |
|
A hacky 🧙♂️ workaround to achieve this is to run two separate tailscale containers in Docker and connect them to a shared container LAN. Then you can manually route any traffic that you want to expose/route to those networks from the host using iptables rules.
version: '2.4'
services:
tailscale1:
hostname: tailscale1
image: tailscale:latest
build: https://github.com/tailscale/tailscale.git#v1.4.4
command: tailscaled
networks:
tslan0:
ipv4_address: 192.168.99.10
cap_add:
- NET_ADMIN
volumes:
- /dev/net/tun:/dev/net/tun
- ./tailscale1_state:/var/lib/tailscale
tailscale2:
hostname: tailscale2
image: tailscale:latest
command: tailscaled
networks:
tslan0:
ipv4_address: 192.168.99.20
cap_add:
- NET_ADMIN
volumes:
- /dev/net/tun:/dev/net/tun
- ./tailscale2_state:/var/lib/tailscale
networks:
tslan0:
external: true
name: tslan0 # create the virtual LAN that will be shared by the two hosts, each connected to a separate tailscale network
docker network create --driver=bridge --subnet=192.168.99.0/16 tslan0
# then make any forwarding rules you want with iptables, e.g.
# iptables -t nat -A PREROUTING -p tcp --dport 8000 -j DNAT --to-destination 192.168.99.10:8000
# iptables -t nat -A POSTROUTING -j MASQUERADE
# then start the containers and log into your two separate tailscale accounts
docker-compose up
docker-compose exec tailscale1 tailscale up # click the link and auth node 1 to account #1 (then clear your cookies / logout)
docker-compose exec tailscale2 tailscale up # click the link and auth node 2 to account #2 (using your other tailscale account) It's a bit cumbersome, but better than nothing. If you have trouble, experiment with adding |
I see #1129 was closed as a duplicate of this, which also mentions fast user switching. Is that also covered by this issue? For me connecting to multiple networks at the same time is not that important, but switching between my personal and corporate account is very time consuming. |
@hkrutzer, yes, it's the same client work required for both. |
OK, I thought this issue might be different because I don't think you would encounter "Should we have multiple local IP addresses, one per account?" or any of the other bullet points for faster user switching 🙂 |
Being able to easily switch accounts would be enough for most cases, much better than the situation we have right now. I am commenting because this issue seems to contemplate a much more complicated use-case that might not be as needed, and can come after the ability to switch accounts. This would be life-changing for those of us using Tailscale for personal use and for corporate. |
I'll agree with @adrm on that - just the ability to log in to multiple accounts and switch between them with a click would be a good enough solution that it probably wouldn't be worth the additional 90% of the work to make accessing multiple networks at once work (especially given the complexities in the bullet points in the issue). My hacky workaround for now is to share my personal machines with my corporate Tailscale user, and then log in with the corporate user on the Tailscale client. This does have privacy implications - for example, corporate IT could change my password, log in as me, and access my personal machines. But I find it unlikely enough that I'm accepting the risk. Plus, all my personal machines need additional authentication (SSH key etc.), and I find it unlikely that corporate IT is going to start brute forcing my keys/passwords. If anyone sees a hole in that workaround that I'm missing, I'd love to hear it! |
+1 for being able to switch between accounts. |
Is this a priority at the moment? Looking forward on this feature! |
The existence of this bug implies that it's a priority. There are many bugs and many priorities. This is not the top priority. But we're making progress towards this one by working on other necessary stuff first. |
@bradfitz Thanks for the update! |
Really looking forward to this feature. Simple switching between accounts, not simultaneous use, would be a perfect solution for many i guess. At the moment I have a corporate account and personal business accounts. |
I think I'm against the grain. I see most people testing Tailscale at home and then using it at work. I went the other way around. I'm implementing it at work and holy $#!^ it's fast and easy to use. So I want it now at home too. A simple drop-down to switch between accounts would be awesome. |
@bradfitz I think Tailscale is throwing away part of the acquisition funnel here, if a developer o devops starts using tailscale at personal level and re-uses the equipment between clients and personal setups, they won't recommend Tailscale it to clients because that would ruin their personal setup given there is no way to use multiple network or switch easily between accounts. |
+1 on this but with a quick reminder: |
Updates #713. Signed-off-by: Walter Poupore <walterp@tailscale.com>
Updates #713 Signed-off-by: Maisem Ali <maisem@tailscale.com>
Updates #713 Signed-off-by: Maisem Ali <maisem@tailscale.com>
Updates #713. Signed-off-by: Walter Poupore <walterp@tailscale.com> Signed-off-by: Walter Poupore <walterp@tailscale.com>
… text Matches the UI clients Updates #713 Signed-off-by: Mihai Parparita <mihai@tailscale.com>
… text Matches the UI clients Updates #713 Signed-off-by: Mihai Parparita <mihai@tailscale.com>
Fast user switching has now shipped in Tailscale 1.34. It is available for the CLI on Linux, Mac and Windows, and in the Mac and Windows UI clients, see the blog post for a summary: https://tailscale.com/blog/fast-user-switching/. There is also more complete documentation for the feature at https://tailscale.com/kb/1225/fast-user-switching/. Thanks for your patience for this long-awaited feature. If there are any bugs or additional platforms or feedback to consider, please file them as separate GitHub issues (instead of extending this one). |
Noticed when testing FUS on tailscale-on-macOS, that routing would break completely when switching between profiles. However, it would start working again when going back to the original profile tailscaled started with. Turns out that if we change the addrs on the interface we need to remove and readd all the routes. Updates tailscale#713 Signed-off-by: Maisem Ali <maisem@tailscale.com>
Updates tailscale#713 Signed-off-by: Maisem Ali <maisem@tailscale.com>
This makes it so that the backend also restarts when users change, otherwise an extra call to Start was required. Updates tailscale#713 Signed-off-by: Maisem Ali <maisem@tailscale.com>
Exposes a REST-y API for interacting with the profile switching introduced in tailscale#6022. Updates tailscale#713 Signed-off-by: Mihai Parparita <mihai@tailscale.com>
We do not need to wait for it to complete. And we might have to call Shutdown from callback from the controlclient which might already be holding a lock that Shutdown requires. Updates tailscale#713 Signed-off-by: Maisem Ali <maisem@tailscale.com>
Updates tailscale#713 Signed-off-by: Mihai Parparita <mihai@tailscale.com>
We were not updating the LoginProfile.UserProfile when a netmap updated the UserProfile (e.g. when a node was tagged via the admin panel). Updates tailscale#713 Signed-off-by: Maisem Ali <maisem@tailscale.com>
Updates tailscale#713 Signed-off-by: Maisem Ali <maisem@tailscale.com>
Updates tailscale#713 Signed-off-by: Maisem Ali <maisem@tailscale.com>
We would end up with duplicate profiles for the node as the UserID would have chnaged. In order to correctly deduplicate profiles, we need to look at both the UserID and the NodeID. A single machine can only ever have 1 profile per NodeID and 1 profile per UserID. Note: UserID of a Node can change when the node is tagged/untagged, and the NodeID of a device can change when the node is deleted so we need to check for both. Updates tailscale#713 Signed-off-by: Maisem Ali <maisem@tailscale.com>
Updates tailscale#713 Signed-off-by: Maisem Ali <maisem@tailscale.com>
This adds a `--nickname` flag to `tailscale login|set`. Updates tailscale#713 Signed-off-by: Maisem Ali <maisem@tailscale.com>
We were not calling checkPrefs on `opts.*Prefs` in (*LocalBackend).Start(). Updates tailscale#713 Signed-off-by: Maisem Ali <maisem@tailscale.com>
…iles We were not checking the currentUserID in all code paths that looped over knownProfiles. This only impacted multi-user Windows setups. Updates tailscale#713 Signed-off-by: Maisem Ali <maisem@tailscale.com>
Profile keys are not deleted but are instead set to `nil` which results in getting a nil error and we were not handling that correctly. Updates tailscale#713 Signed-off-by: Maisem Ali <maisem@tailscale.com>
We merge/dedupe profiles based on UserID and NodeID, however we were not accounting for ControlURLs. Updates tailscale#713 Signed-off-by: Maisem Ali <maisem@tailscale.com>
Updates tailscale#713 Signed-off-by: Maisem Ali <maisem@tailscale.com>
Updates tailscale#713. Signed-off-by: Walter Poupore <walterp@tailscale.com> Signed-off-by: Walter Poupore <walterp@tailscale.com>
… text Matches the UI clients Updates tailscale#713 Signed-off-by: Mihai Parparita <mihai@tailscale.com>
(context added on 2022/09/14)
What are you trying to do?
Log into multiple tailscale accounts at once (eg. example@gmail.com and example@example.com) and easy switch between accounts, i.e. improve the "Log in to a different account..." flow on a device, (possibly) without requiring re-authentication. Access only machines on the network you are currently logged into.
FR to access all the machines on both networks simultaneously: #183
How should we solve this?
The basics of this are not that complicated to do purely client side:
Complexity arises from specific details:
Should we have multiple local IP addresses, one per account? Is that even possible on all platforms? Or should we get help from the control server to assign the same IP address to all accounts? But if we do that, what about accounts with custom IP subnet designations?
If we have multiple local IP addresses, there needs to be a good way to choose which local IP address to use for a given outgoing connection. (Based on routes?)
If we use a single local IP address, this could violate users' privacy expectations. Their distinctive identities end up tied together in the control server. It's a lot more elegant if we can support multi-login entirely client side.
If two accounts export the same subnet routes (--advertise-subnets), you can get conflicts between them.
If two accounts have different DNS overrides, they can conflict. (This isn't so bad if we use the DNS settings only for particular subdomains rather than globally.)
Corporate admins may not like the idea of a single machine being on both the corporate and non-corporate networks at once (although it's probably not as bad as being on both the Internet and the corporate network at once.)
The text was updated successfully, but these errors were encountered: