starred/pikvm-pikvm

Fork 0

mirror of https://github.com/pikvm/pikvm.git synced 2026-03-02 18:16:56 -05:00

Expire KVM session #805

New issue

Closed

opened 2026-02-20 14:06:37 -05:00 by deekerman · 10 comments

deekerman commented

2026-02-20 14:06:37 -05:00

Owner

Originally created by @cconkrig on GitHub (Jan 6, 2024).

Originally assigned to: @mdevaev on GitHub.

Describe the bug
HTTP/Web authentication seems to never timeout/expire unless you restart kvmd service or manually logout. If you restart the kvmd service, then auth is cleared and users are forced to login again. This is a security risk if someone forgets to logout manually.

To Reproduce
1.) Login to the web gui.
2.) Open the KVM control to display the remote computer.
3.) Close the browser (do not logout as a lot of users will do).
4.) Re-open the browser (even days/weeks? later) and you are still logged in.

Expected behavior
You should be re-prompted to login.

Desktop (please complete the following information):

OS: Windows 11
Browser: Chrome
Version: 120.0.6099.130 (64-bit)
VNC client (if used): N/A

PiKVM info:

Raspberry Pi board version: RPi 4
PiKVM platform: v3-hdmi
Video capture type: CSI bridge
KVMD version:
kvmd 3.287-1
kvmd-fan 0.26-1
kvmd-oled 0.26-1
kvmd-platform-v3-hdmi-rpi4 3.287-1
kvmd-webterm 0.47-1
uStreamer version: ustreamer 5.45-1
Linux kernel: Linux pikvm 6.1.61-1-rpi-ARCH #1 SMP Fri Nov 3 20:48:52 MSK 2023 armv7l GNU/Linu

Originally created by @cconkrig on GitHub (Jan 6, 2024). Originally assigned to: @mdevaev on GitHub. **Describe the bug** HTTP/Web authentication seems to never timeout/expire unless you restart kvmd service or manually logout. If you restart the kvmd service, then auth is cleared and users are forced to login again. This is a security risk if someone forgets to logout manually. **To Reproduce** 1.) Login to the web gui. 2.) Open the KVM control to display the remote computer. 3.) Close the browser (do not logout as a lot of users will do). 4.) Re-open the browser (even days/weeks? later) and you are still logged in. **Expected behavior** You should be re-prompted to login. **Desktop (please complete the following information):** - OS: Windows 11 - Browser: Chrome - Version: 120.0.6099.130 (64-bit) - VNC client (if used): N/A **PiKVM info:** - Raspberry Pi board version: RPi 4 - PiKVM platform: v3-hdmi - Video capture type: CSI bridge - KVMD version: kvmd 3.287-1 kvmd-fan 0.26-1 kvmd-oled 0.26-1 kvmd-platform-v3-hdmi-rpi4 3.287-1 kvmd-webterm 0.47-1 - uStreamer version: ustreamer 5.45-1 - Linux kernel: Linux pikvm 6.1.61-1-rpi-ARCH #1 SMP Fri Nov 3 20:48:52 MSK 2023 armv7l GNU/Linu

deekerman

2026-02-20 14:06:37 -05:00

closed this issue
added the
type:feature

resolution:fixed
labels

deekerman commented

2026-02-20 14:06:40 -05:00

Author

Owner

@mdevaev commented on GitHub (Jan 6, 2024):

This is implemented intentionally so as not to bother the user. Personally, my eyelid twitches every time sites ask me to relogin without any meaning. Are you sure this is necessary?

@mdevaev commented on GitHub (Jan 6, 2024): This is implemented intentionally so as not to bother the user. Personally, my eyelid twitches every time sites ask me to relogin without any meaning. Are you sure this is necessary?

deekerman commented

2026-02-20 14:06:40 -05:00

Author

Owner

@cconkrig commented on GitHub (Jan 6, 2024):

Yes. It's a major security risk if a user doesn't remember to log out and walks away. It should be a flag or be configurable in the yaml. Why have OTP if you are just always logged in?

@cconkrig commented on GitHub (Jan 6, 2024): Yes. It's a major security risk if a user doesn't remember to log out and walks away. It should be a flag or be configurable in the yaml. Why have OTP if you are just always logged in?

deekerman commented

2026-02-20 14:06:40 -05:00

Author

Owner

@mdevaev commented on GitHub (Jan 7, 2024):

I assume that if a user uses a computer with public access, then he should lock the screen when he leaves or log out on his own. Otherwise, there is no safe time interval, because even five minutes of physical access is enough to steal cookies or do something else. In short, a timeout does not solve the security problem in any way.

@mdevaev commented on GitHub (Jan 7, 2024): I assume that if a user uses a computer with public access, then he should lock the screen when he leaves or log out on his own. Otherwise, there is no safe time interval, because even five minutes of physical access is enough to steal cookies or do something else. In short, a timeout does not solve the security problem in any way.

deekerman commented

2026-02-20 14:06:40 -05:00

Author

Owner

@mdevaev commented on GitHub (Jan 10, 2024):

What interval do you consider acceptable?

@mdevaev commented on GitHub (Jan 10, 2024): What interval do you consider acceptable?

deekerman commented

2026-02-20 14:06:40 -05:00

Author

Owner

@mdevaev commented on GitHub (Jan 28, 2024):

Sup?

@mdevaev commented on GitHub (Jan 28, 2024): Sup?

deekerman commented

2026-02-20 14:06:41 -05:00

Author

Owner

@safesploit commented on GitHub (Aug 4, 2024):

This session_timeout should be defined in the config file, such that it can be chosen by the admin.
Otherwise, have session_timeout = 0 which allow the user to remain logged in forever.

I think the issue @cconkrig was raising more focused on not having the choice to decide.

@safesploit commented on GitHub (Aug 4, 2024): This `session_timeout` should be defined in the config file, such that it can be chosen by the admin. Otherwise, have `session_timeout = 0` which allow the user to remain logged in forever. I think the issue @cconkrig was raising more focused on not having the choice to decide.

deekerman commented

2026-02-20 14:06:41 -05:00

Author

Owner

@KingRat0011 commented on GitHub (Aug 6, 2024):

I do think this is needed, it is a security risk for me when someone leaves the session open, so I upvote a timeout please, like a auto logout

@KingRat0011 commented on GitHub (Aug 6, 2024): I do think this is needed, it is a security risk for me when someone leaves the session open, so I upvote a timeout please, like a auto logout

deekerman commented

2026-02-20 14:06:41 -05:00

Author

Owner

@adamoutler commented on GitHub (Jan 25, 2025):

I'm using Chromium under Ubuntu and I was logged out when I closed the browser.

@adamoutler commented on GitHub (Jan 25, 2025): I'm using Chromium under Ubuntu and I was logged out when I closed the browser. ![Image](https://github.com/user-attachments/assets/024dc29a-fe55-4c69-8031-77fc640c3900)

deekerman commented

2026-02-20 14:06:41 -05:00

Author

Owner

@mdevaev commented on GitHub (Feb 8, 2025):

I added the login option to specify the time when the session will expire.

By default, an infinite session is used, but if the user switch the time selector, the browser will remember it.
It is possible to set the global config value of maximum time in accordance with your security policy (is not set by default = infinite). User without root privileges can't change it.
If the global limit is set, but the user wants a longer session, he won't get it.
If the session is expired, it does not affect other sessions of the same user.
Clicking Logout leads to the logout of all sessions of this user, as it was before.

The default settings are selected for backward compatibility reasons. This will be available in the next release.

Note the expiration of the session invalidates the authorization token. This means that no new connections will be established, but existing long-lived connections (websockets for hid, video) will not be terminated. It seems that usually no one cares about similar problems, and closing a browser tab by a decent user solves it. However, it seems to me a good idea to plan a way to immediately terminate all connections when the token was expired. Like, time's up, get out :)

@mdevaev commented on GitHub (Feb 8, 2025): I added the login option to specify the time when the session will expire. * By default, an infinite session is used, but if the user switch the time selector, the browser will remember it. * It is possible to set the global config value of maximum time in accordance with your security policy (is not set by default = infinite). User without root privileges can't change it. * If the global limit is set, but the user wants a longer session, he won't get it. * If the session is expired, it does not affect other sessions of the same user. * Clicking `Logout` leads to the logout of all sessions of this user, as it was before. The default settings are selected for backward compatibility reasons. This will be available in the next release. Note the expiration of the session invalidates the authorization token. This means that no new connections will be established, but existing long-lived connections (websockets for hid, video) will not be terminated. It seems that usually no one cares about similar problems, and closing a browser tab by a decent user solves it. However, it seems to me a good idea to plan a way to immediately terminate all connections when the token was expired. Like, time's up, get out :) ![Image](https://github.com/user-attachments/assets/d5b3b826-1fed-4126-a9f8-1305e726d99d)

deekerman commented

2026-02-20 14:06:41 -05:00

Author

Owner

@mdevaev commented on GitHub (Feb 10, 2025):

Released: https://docs.pikvm.org/auth/#session-expiration

@mdevaev commented on GitHub (Feb 10, 2025): Released: https://docs.pikvm.org/auth/#session-expiration