Token can be used by anyone, without user validation
Hello I'm opening this issue either to correct my understanding of a feature, or to raise a security bug. We are currently running warpgate v0.16.0. We're using tokens to provide temporary access to our internal user to targets outside of their usual scope, and external companies that have a warpgate account, but not access to any server by default.
Our understanding of the documentation https://warpgate.null.page/tickets/ is the following
- Creating a ticket require both a user and a target
- The ticket isn't sensitive information, it can be shared with the recipient on trusted communication tool
- A specific ticket only works for the user it has been created for, using whatever auth method is setup for that user (In our case, ssh key)
This morning i did a silly test, after creating a token for an external company, i tried it on my laptop, and it worked. If our understanding is correct, it should have, but we though that maybe because my user and key was already authorized to log into the server, it defaulted to that and worked for that reason. We tried on a brand new virtual desktop and tried on it, and it also worked, dashing that possibility.
We checked warpgate log, and it shows the the passwordless/keyless connection being established as the target user
10/15/2025, 2:16:54 PM daacf15b-3025-4a3c-a121-06e03d119407 Closed channel: 5c735c19-0d1c-4b00-9028-71413efc808f
10/15/2025, 2:16:54 PM daacf15b-3025-4a3c-a121-06e03d119407 Closed connection
10/15/2025, 2:16:54 PM daacf15b-3025-4a3c-a121-06e03d119407 Disconnect
10/15/2025, 2:16:17 PM daacf15b-3025-4a3c-a121-06e03d119407 Authorized for <TARGET_SERVER> with a ticket client_ip: <CLIENT_IP>
10/15/2025, 2:16:17 PM <USER>-ext daacf15b-3025-4a3c-a121-06e03d119407 Opening shell channel_id: 5c735c19-0d1c-4b00-9028-71413efc808fclient_ip: <CLIENT_IP>
10/15/2025, 2:16:17 PM daacf15b-3025-4a3c-a121-06e03d119407 Connected address: <SOURCE_IP>:22
10/15/2025, 2:16:17 PM <USER>-ext daacf15b-3025-4a3c-a121-06e03d119407 Opening session channel channel: 5c735c19-0d1c-4b00-9028-71413efc808fclient_ip: <CLIENT_IP>
10/15/2025, 2:16:17 PM <USER>-ext daacf15b-3025-4a3c-a121-06e03d119407 Recording session daacf15b-3025-4a3c-a121-06e03d119407 client_ip: <CLIENT_IP>name: shell-channel-2path: "/data/warpgate/recordings/daacf15b-3025-4a3c-a121-06e03d119407/shell-channel-2"
10/15/2025, 2:16:17 PM daacf15b-3025-4a3c-a121-06e03d119407 Connecting address: <SOURCE_IP>:22username: user_N3
10/15/2025, 2:16:17 PM daacf15b-3025-4a3c-a121-06e03d119407 Keyboard-interactive auth as <ticket> client_ip: <CLIENT_IP>
10/15/2025, 2:15:40 PM <USER>-ext aa497e76-cd23-4db7-b224-f861b9c0ab7f Opening shell channel_id: e877ef3a-94ad-464a-b5f9-f630e0a7ead8client_ip: <DST_IP>
10/15/2025, 2:15:40 PM <USER>-ext aa497e76-cd23-4db7-b224-f861b9c0ab7f Opening session channel channel: e877ef3a-94ad-464a-b5f9-f630e0a7ead8client_ip: <DST_IP>
10/15/2025, 2:15:40 PM <USER>-ext aa497e76-cd23-4db7-b224-f861b9c0ab7f Keyboard-interactive auth as <ticket> client_ip: <DST_IP>
10/15/2025, 2:15:40 PM aa497e76-cd23-4db7-b224-f861b9c0ab7f Connected address: <SOURCE_IP>:22
10/15/2025, 2:15:40 PM <USER>-ext aa497e76-cd23-4db7-b224-f861b9c0ab7f Recording session aa497e76-cd23-4db7-b224-f861b9c0ab7f client_ip: <DST_IP>name: shell-channel-2path: "/data/warpgate/recordings/aa497e76-cd23-4db7-b224-f861b9c0ab7f/shell-channel-2"
10/15/2025, 2:15:40 PM aa497e76-cd23-4db7-b224-f861b9c0ab7f Connecting address: <SOURCE_IP>:22username: user_N3
Can you please clarify if tokens are supposed to be treated like a password or a private key and our understanding is wrong ? Or if this a Bug and the target user should have been validated but isn't.
Thank you for your time.
The ticket secret is sensitive information and tickets bypass auth method policies. The primary use case for these is programmatic access where interactive authentication isn't possible, e.g. you can use a ticket in a DATABASE_URL even if the corresponding normally has 2FA enabled.