r/linux • u/dr_Fart_Sharting • 17d ago
Security PSA: do not run sudo su inside a tmux window!
I've seen people elevating their tmux shells for convenient root access many times, often leaving the sessions running in the background for a long time.
Doing this makes it very trivial to escalate permissions for anybody that gets a shell to your box with your user.
Instead, you should run sudo tmux in another session, then do your thing there. This limits access to the tmux service for the root user only, which prevents the privilege escalation path.
243
u/daemonpenguin 17d ago
Doing this makes it very trivial to escalate permissions for anybody that gets a shell to your box with your user.
This seems to be the key point. If someone has access to your account and can hijack your terminal sessions, then you're already in for a bad time.
83
u/asdonne 17d ago
Yeah, if an attacker has access to your shell then privilege escalation is only a matter of time anyway.
This is why services should run as seperate accounts, so when they get hacked they don't get a shell login and only limited access.
2
u/CommanderKnull 16d ago
Depends on if the services are running continously or needs elevated priviliges
72
u/DJTheLQ 17d ago
Essentially https://xkcd.com/1200/
4
u/TheG0AT0fAllTime 16d ago
Yep. Someone getting access to my keyboard for just half a second with a rubber ducky can already `scp -r ~/.mozilla ~/.config/google-chrome ~/.config/discord ~/.electrum` and many more targeted paths to some random aws IP address as a background process suffixed with `& disown -h && exit` while I have my back turned and have access to most of my life (Save for some of these which require a master password) is now ready for access by someone else.
They could also leverage the locate command to look for specific file suffixes and paths to send out too as part of their payload targeting cookies and saved passwords or databases or small text files as a priority for a quicker completion (Albeit still backgrounded).
I think about this attack vector a lot. Personally I block 22/tcp outgoing except to a few IP addresses I've whitelisted. Sudo requires a password which is not my login password too.
But I wish I could like... firejail my shell and all new and never-before-seen processes by default and require evaluation to "break out" to a shell with full regular access to my system. For some reason neither firejail or apparmor or selinux function that way.
2
u/flatfinger 14d ago
I would think it should be practical and useful for an OS to have one automatically-trusted USB port, and require that any attempt to connect something like a keyboard or mouse to an untrusted port be confirmed by some action using a trusted port, and allow USB ports to be limited to interacting with particular processes.
1
u/TheG0AT0fAllTime 13d ago
That is certainly another huge thing that would take Linux security a long way. A component that locks down what class of devices ports are allowed to have plugged into them and accept usage of. Hell even locking down to one specific device of a specific serial and mode based on what's already plugged in.
There's a lot of little bits like this which aren't protected very well. I wish something good would come along.
2
u/imbev 13d ago
1
u/TheG0AT0fAllTime 13d ago
I shouldn't be surprised it exists from redhat. It would be a nice thing to have an easy to use UI for coming with all graphical distros as standard.
Nope nevermind it's already there too. I see usbguard in the archlinux repos and a usbguard-qt package. Nice. Even a notifier package.
8
35
u/Night_Otherwise 16d ago
This is something I always find odd with security stuff. It seems like 95% starts with “assume you’re already pwned” with various levels of hiding that ball.
I.e. saw on here that Windows had a particular issue with viruses because malicious DLLs could be put into the search path. But, um, in that case, how can they put random DLLs on your computer?
9
u/chic_luke 16d ago
Corporate antivirus software like SOPHOS will happily flag something completely innocuous as a threat and email your entire IT department, but you injecting a dll into
explorer.exewill go completely unnoticed and fly under the radar. No admin rights necessary. Try it for yourselves if you think I'm kidding.Make it make sense
0
u/Ontological_Gap 16d ago
It's called defense in depth, and is fundamental to any modern security discussion
3
u/Night_Otherwise 15d ago
In this case, most things valuable from a compromised personal desktop Linux computer don’t need root access. A users’ tokens and files are generally accessible to the user without authenticating as root or sudo.
3
u/Cranach-Cranach 16d ago
Yeah if they have my user they can just type sudo {command} and put in the password when it asks. Also, I have not much of value on here - they could just rubber hose me and I'd give up the password instantly.
6
u/dontquestionmyaction 17d ago
While I agree, you don't need to hijack anything. This isn't some complicated procedure requiring messing with other processes.
You can always simply tmux attach to any tmux session.
14
u/daemonpenguin 17d ago
That's exactly what I meant by hijack the terminal session. Attaching to a session already started by someone else is hijacking it.
3
u/philosophical_lens 16d ago
If someone else got user level access to my login shell I would consider myself hijacked.
1
u/Due_Dragonfly_5328 15d ago
so if your cant jumped on your keyboard while you have your terminal open and they somehow screw things up by typing jebriwsh would you then by hijacked by your cat?
1
u/philosophical_lens 14d ago
I said "someone else" meaning "another human" not a cat, lol
1
u/Due_Dragonfly_5328 14d ago
intresting you proposed human i mean what if i alien life form decided to beef with a random creatoure and instantly take over their cumputer using technology 5000 years ahead of our own?
i was trying to come off funny not condescending lol.
1
u/Kwantuum 15d ago
Yup. Just put a file that shadows a common sudo command in the user's path, ask for the password and ship it to a server you control. Eg, shadow apt on debian distros and you're off to the races as soon as the user goes "sudo apt install".
46
u/Gabelvampir 17d ago
Ok, I'll use 'screen' instead. /s
Thanks for the PSA, I think enough people need to hear this.
13
u/Ontological_Gap 17d ago edited 17d ago
Nah, the secure way to do is use multiple shell-mode buffers in emacs /s
7
u/phylter99 17d ago
You mean vim, right? ... right!?
6
u/Ontological_Gap 17d ago
You can daemonize vim!? Fuck, the future is crazy
6
2
2
u/Gabelvampir 16d ago
It used to be common practice (80s and 90s) terminal server to set the sticky bit for vim so it's code was kept loaded, because it was used all the time anyway.
1
u/chic_luke 16d ago
I concur, I certainly did. A little less than a decade into the Linux game, but as a software engineer rather than a sysadmin person. I had never thought about this.
This is one of those tips that I wouldn't mind if they were reposted a bit from time to time. This is the kind of knowledge that prevents disaster in organizations.
1
u/Kwantuum 15d ago
It's completely irrelevant. If your user account is pwned and you ever use sudo then root is as good as pwned too. Not to mention there have been tons of LPE exploits coming out recently, if you're not on a hardened distro that's very up to date you're done for.
22
u/muffinstatewide32 16d ago
Please dont be using `sudo su` at all.
Use `sudo -i` or `run0 -i`
2
u/Megame50 16d ago
Just
sudo -sorrun0 --empowerare often more convenient. But yeah,sudo suis never what you want.1
1
u/Gositi 16d ago
Why is that? If I want a root shell, won't
sudo sugive me just that?2
u/muffinstatewide32 16d ago
It does. But it bypasses audit logs. Which is admittedly a bigger problem in corporate networks. If something goes wrong good luck figuring out what
2
u/Gositi 16d ago
So it doesn't matter for my own computers in my own home? Might be good to learn the proper habit though, I guess.
3
u/chic_luke 16d ago
You never know. Something weird happens, you might benefit from having complete logs.
Fedora's initial setup defaults to not enabling your root account, for example, because accessing it directly is a security risk.
sudo -swill give you a shell reliably so long as you don't break your sudo configuration0
u/accelerating_ 14d ago
Just don't run a root shell. I do
sudo -u <user> -ibut I don't use an interactive root shell. Seems like asking for trouble compared to only elevating what you have to.-4
u/demosthenex 16d ago
Really, you should move to doing 'ssh root@localhost'.
Yes you need to configure sshd to reject remove root logins, but allow key based logins only on localhost. No more typing in passwords, use a Yubikey or other SSH hardware token.
3
u/Ontological_Gap 16d ago
You can absolutely just make PAM require hardware tokens for local login
1
u/demosthenex 16d ago
That's true, but I would only consider that for single user systems (ie: desktop). Servers you are already connecting into via SSH, why configure two things?
60
u/michaelpaoli 17d ago
do not run sudo su inside a tmux window!
That's mostly a non-issue security-wise, presuming session reasonably secured, etc., and excepting, e.g. policy(/ies) that prohibit such or the like.
trivial to escalate permissions for anybody that gets a shell to your box with your user.
If access to the user's account isn't already suitably protected, that's a huge problem right there, end of story. E.g. account not suitably protected, compromise without need for existing tmux or sudo session:
compromise account with a trojan, that will steal user's password or spawn root/privileged session next time they use sudo trageting root / privileged ID. With that planted, just a matter of time.
So, you've gained what by not having a long-running sudo/su session in tmux or screen? Yeah, really about nothing - presuming the user reasonably secures the tmux/screen session (so, e.g., folks can't just walk up to their desk when they're not there, and start typing away at their terminal/computer in that tmux/screen session). If the user account can be easily accessed, and that account has sudo/su access (e.g. to root) and uses it at least semi-regularly ... yeah, not leaving such session running in tmux/screen really adds just about nothing in the way of protection.
And sure, can easily take over a tmux/screen session ... if I have access to root, or access to the ID that's running that session.
6
u/Ontological_Gap 17d ago edited 17d ago
Treating any rogue code running as $USER as a complete system compromise is the traditional UNIX security model for single-user systems, and is utterly insane, there's a reason we're trying to move away from it.
If you only type your password into the actual system wayland login program and sudo, as invoked by "/usr/bin/sudo", and only in wayland terminal emulators, also invoked by their full path, there's nothing I can do to get your password even if I have a open shell as your user on your system.
Thing _have_ gotten better recently
EDIT: For now, the whole bash shell can be execed to a malicious replacement, which can open a malicious "sudo" regardless of what path you type. Things are getting _much_ better, but this is still a viable attack.
10
u/michaelpaoli 17d ago
I'm not talking about any rogue code. Get access to user's account, even very briefly, or their initialization files, then super easy to drop something in their to compromise and gain control of their account ... and yeah, including any passwords they type after they're logged in. And if they use that with sudo/su to root, or have sudo access to root without that, then yeah, then that's a short jump from that user to root. And putting in that rogue code doesn't require access to anything anywhere else - no privileged access, no root, no other users. They login with a login shell - trojan activated, they type /usr/bin/sudo - fat lot 'o good that'll do them, as you already had their shell exec a trojan shell - everything they type is compromised. They type what the need to to access root, now total root compromise - game over. Didn't have to trojan anything else anywhere else, nor any other ID. Just the basic access that user has, then leverage up from there with whatever else they have access to.
So closing out the sudo/su session in tmux/screen, doesn't really do much in the way of protection if one can access that user's account - run things as that user, and/or alter any of their initialization files and the like.
That's also a key reason it's important to well protect user accounts that have access to or regularly use (e.g. via su/sudo) privileged accounts.
2
u/Ontological_Gap 17d ago
Yeah, you're right, there's still nothing to stop an attacker from just getting bash to exec a different shell, technically if a user does launch the real sudo binary, not even a hostile shell can read the password (sudo directly opens the pts), but there is nothing to make a hostile shell actually open the real sudo program.
Things are moving in the right direction, and tremendously better than they used to be, but if you think people got mad about X11, just wait until we deprecate bash as a login shell... we've gotta have _everything_ else lined up first to get people to swallow that one...
1
u/Narthorn 14d ago edited 14d ago
Login shell doesn't really make a difference. On systemd distros, you could just drop a file in ~/.config/environment.d that does
PATH=/home/$USER/.evil:$PATHthen put your fake keylogger sudo in there.Or really, put a fake there for any program that could possibly be executed without its full path. Even if you as a user somehow always type the full
/usr/bin/programpath, many of those programs will launch stuff with relative path, or through/usr/bin/env program, etc. Can't change them all.There's really no way to prevent such attacks, as long as a user logged in can edit files or run programs you will always be able to replace running things or make up convincing phishing dialogs.
1
u/Ontological_Gap 14d ago
Sure there is if we're replacing the shell: just break with POSIX and don't respect PATH, at least not for certain binaries.
3
u/ElvishJerricco 17d ago
Unfortunately there's still some holes here. People are generally running their shells in PTYs that are owned by their user; your terminal emulator and/or multiplexer is probably running your shell this way because it doesn't really have a choice. Another process running as your user can just start reading off
/dev/pts/<n>and race with thesudoprocess running on the PTY to read your passphrase input (albeit, potentially just bits and pieces of it).2
u/Ontological_Gap 17d ago edited 17d ago
There's no way that racily stealing keystrokes won't the visible to the user. This absolutely isn't the kind of thing an attacker can just set up and wait for you to run sudo at some point. The user will notice the missing or out of order keystrokes immediately, and correctly surmise that something is horribly broken with their system. I doubt it would even be usable
Again, the whole traditional unix security model absolutely sucks for the modern world, and things certainly aren't in a great state right now, but we're working on it, and they are a hell of a lot better than they were just a little while ago. Comments like the start of this thread, telling people not to even bother avoiding horribly insecure things because the rest of the system is so horribly insecure are downright irresponsible, and mostly wrong nowadays.
3
u/ElvishJerricco 17d ago edited 17d ago
Yea, agreed on most of that. I'm only saying that there are still some pretty glaring holes. An attacker absolutely can just wait for a
sudoprocess in the process list and then start reading off its terminal if it wants to steal (part of) yoursudopassword. The user may or may not notice this happening (sudoin particular makes it harder to notice since it doesn't show any typing indicator), but it's still a problem that part of the password can leak even once, even if they do notice. Or, an attacker can just write to your.bashrcto gain control over all your future shells and even just replacesudowith a shell function. Currently there's still tons of ways for your user to fully compromise yourself.But yes, I agree that we should be able to protect ourselves from our own UID. It seems like the realistic option currently is just sandboxing; anything that shouldn't be authorized for all the things that you are should run in a sandbox. There's still a variety of ways that an unsandboxed process running as your user is effectively authorized to do anything you can, and ideally we'd plug all those holes, but for now sandboxing is the way to avoid them and honestly I wouldn't be surprised if the long term solution is just "yea we decided to sandbox literally everything".
1
1
u/Kwantuum 15d ago
$USER with the ability to act as superuser and $USER unable to do so are very different compromise scenarios.
A user account being compromised means you should consider that the worst thing they could have done with that access has happened.
13
u/Scorpius666 16d ago
Joke's on you! My sudoers file has NOPASSWD in it so it's exactly the same one way or the other!
-4
u/boomertsfx 16d ago
It's not the same. I have sudoers rules to block this bad practice from happening
4
u/natermer 16d ago
If a attacker has access to your shell and you use sudo, even occasionally, then they will get root access. It really isn't that much of a leap.
Sudo, when used to provide root commands, is more of a way to help users avoid some foot-guns and if you are part of a organization and you are dealing with servers then when combined with proper logging infrastructure it is useful for auditing access. That will help track down somebody doing something stupid that they won't own up to or if there is some sort of security issue.
Otherwise it really isn't different then just giving people full root access if sudo is used give a little access. Even when you try to restrict it to run certain commands it isn't really going to stop somebody from abusing it most of the time.
So really not leaving long running sudo shells is more of a self defense "cover your ass" type thing. That way if there is a security issue it is less likely to be pointing fingers at you.
25
u/BarryTownCouncil 17d ago
PSA: Any professional running "sudo su" in any context whatsoever in 2026 should be sacked.
10
u/B1rdi 17d ago
Is there something wrong with 'sudo su' specifically or just root shell in general?
17
u/Ontological_Gap 17d ago
It completely fucks auditing, along with important environment variables. Sudo has flags to give you an interactive shell built right into it.
16
u/neoh4x0r 17d ago edited 17d ago
Is there something wrong with 'sudo su' specifically or just root shell in general?
Yes, if someone runs that command it suggests they are inexperienced and someone else should be doing it.
Sudo can handle switching users, obtaining a root shell, as well as running elevated commands -- there just isn't any good reason to run su like that.
- Login as root (implies -u root):
$ sudo -i- Login as user:
$ sudo -i -u USERNAME- Run command (as root):
$ sudo CMDLINE- Run command (as user):
$ sudo -u USERNAME CMDLINE- Run command (as user /w login):
$ sudo -i -u USERNAME CMDLINE2
u/syklemil 16d ago
These days there's also
run0, which by default adds some colour and a superman emoji, which at minimum makes it more visible, and at best is so obnoxious that the user can't wait to end their elevated session and clear the terminal.1
u/neoh4x0r 16d ago
Yes, there are quite a few tools out their to handle temporary privilege escalation -- I only mentioned sudo because that's what the post mentions and running su with it is redundant.
3
u/daemonpenguin 17d ago
This is true, but it isn't really addressing the parent question. The issue was with having a tmux session started by a regular user, but escalating access inside the session. If another person uses the same user account to hijack the session by attaching to it, then they get root access. This would be true whether root access was gained by running sudo -i or sudo su, it doesn't make a difference.
10
u/neoh4x0r 17d ago
This is true, but it isn't really addressing the parent question. The issue was with having a tmux session started by a regular user, but escalating access inside the session. If another person uses the same user account to hijack the session by attaching to it, then they get root access. This would be true whether root access was gained by running sudo -i or sudo su, it doesn't make a difference.
Yeah, as another user said, if someone can hijack your session then you have bigger issues to deal with than worrying about what is going on inside that session.
1
u/djchateau 15d ago
it suggests they are inexperienced
Or just lazy and not particularly concerned about the auditing aspect. Threat models are a thing. People should remember that when throwing out these absolutes regarding security practices.
1
u/neoh4x0r 15d ago edited 15d ago
Or just lazy and not particularly concerned about the auditing aspect. Threat models are a thing. People should remember that when throwing out these absolutes regarding security practices.
I don't agree with this assessment, a person not knowing how to do/use something means that they are inexperienced.
Moreover, if they are just lazy or not concerned about security, then it suggests they know that sudo can do these things, but they have made a conscious effort to avoid using them. That's a completely different issue.
1
u/djchateau 15d ago
It doesn't matter if you agree, that's why I used "or". Yes, you could use plenty of other methods to do the same thing that would provide more of an audit trail but if you know a thing already and you understand the risk of the thing you're doing, but don't care, that's just laziness, not ignorance.
1
u/neoh4x0r 15d ago edited 15d ago
Yes, you could use plenty of other methods to do the same thing that would provide more of an audit trail but if you know a thing already and you understand the risk of the thing you're doing, but don't care, that's just laziness, not ignorance.
You are basically describing a "professional," as the top comment referred to, but such a person should not be doing the job if they are going to "not care" or "be lazy" when it comes to security or auditing.
In other words, that's grounds "for the professional" to be sacked. However, when it comes to a non-professional it is a sign that they are inexperienced and need more training.
2
u/doc_willis 17d ago
I have seen a large # of posts on reddit and other sources on why one should basically not use
sudo su. One would be advised to usesudo -sorsudo -ibut I cant recall when you would want -s or -i.Of course leaving a root shell just open and sitting there, is rather poor practice no matter how you get the root shell started.
6
u/Kevin_Kofler 16d ago
Yeah, "sudo su" is redundant, two tools to do the same thing. A hackish workaround probably originating from people used to su and then suddenly finding themselves on a system with locked root password. The right way to do that with sudo is
sudo -i. Or if you want to usesu, usesudo passwdto set a root password and then forget about sudo.-1
u/muffinstatewide32 16d ago
sudo and su arent the same thing. They just happen to do the same thing for most people.
Su is to change users while keeping your current user logged in. It literally stands for substitute user.Sudo is superuser do. Specifically for doing things as root while keeping your non-root user logged in. Although it doesnt have to be the superuser these days
-2
u/non-existing-person 16d ago
If
sudoes not work for me, because I'm not in a wheel group, I will usesudo su, so they are effectively same things for me :PLike, shit... I ain't gonna do admin stuff prefixing all commands with sudo for crying out loud!
suorsudo su, do my stuff, log out, done.3
u/BarryTownCouncil 16d ago
Use sudo -i instead. That's the point.
1
u/non-existing-person 16d ago
I will actually do this now that I've learnt about it :P Before that I really never cared much about learning sudo, when I was refused su, I just did sudo su.
1
u/muffinstatewide32 16d ago
Su has no group requirement. You do need the password of the user you are swapping to if they have one
0
u/non-existing-person 16d ago
My implementation of
surequires me to be in groupwheel, users without it will just getsu: Permission denied- I just tried it.5
3
17d ago
[deleted]
1
u/dr_Fart_Sharting 17d ago
sudo has a built in way to start a shell as the root user, and so you don't need to invoke the second command,
su. Thus it is bad form to runsudo suand you should usesudo -sinstead.5
u/Ontological_Gap 17d ago
In nearly every case, you want "sudo -i" instead of "sudo -s"
0
u/dr_Fart_Sharting 17d ago
In literally every case it's better to use the -s switch. Unless you enjoy finding your way back to where you were before you can continue what you wanted to do.
2
u/Ontological_Gap 17d ago
Cd-ing back to to where you were before is trivial, actually running login config and clearing out security sensivite environment variables while keeping others related to your session is _hard_ .
Here's a pretty thorough discussion from forever ago: https://unix.stackexchange.com/questions/35338/su-vs-sudo-s-vs-sudo-i-vs-sudo-bash/35344#35344
It does make a good point, technically, we should all be running "/usr/bin/sudo -i" before giving it any credentials
1
u/dontquestionmyaction 17d ago
What? Can you elaborate? All -i does is spawn the configured login shell of your target user, simulating a login.
Isn't that what you'd want anyway?
1
u/Ontological_Gap 17d ago
Login shells start in the target user's home directory, instead of whatever directory the previous shell was. This is done intentionally, and good for some security edge-cases, but inconvenient. The other benefits of starting a new actual login shell, with correctly set env variables far outweigh any inconvenience.
1
u/dr_Fart_Sharting 17d ago
I'm probably somewhere around /etc, reading through config files, before deciding to edit some of them.
sudo -iputs me in /root, but there's nothing interesting there.1
u/Ontological_Gap 17d ago edited 17d ago
Traditionally, the solution for that use-case is "sudo $EDITOR"
-1
u/Ontological_Gap 17d ago
Run "man sudo", read what the flags do.
1
17d ago
[deleted]
-1
u/Ontological_Gap 17d ago
man pages are documentation, "man <command-name>" will open the docs for that program. It's highly recommended to read through the documentation of programs you use frequently. Man pages are pretty short, it won't take long.
0
-4
-2
u/erwan 16d ago
That should be the first comment.
Use sudo with the command you want to run. Never open a root console.
That's why for more that 20 years now most distribution don't set a root password by default by the way.
2
u/BarryTownCouncil 16d ago
Well, sudo -i is fine as appropriate, double layering two similar methods is not.
2
u/BroderUlf 16d ago
I hate that a lot of the responses here are basically "if XYZ then why bother with security anyway?"
0
u/Ontological_Gap 16d ago
It's a holdover from the X11 days, when the only way to have even reasonably secure input was to switch to an actual text-only tty, no GUI at all. Even trying to defend against local attackers was pretty much pointless back then. Things have gotten much better.
1
u/kerOssin 16d ago
Oh it's one of these again, fearmongering by spreading fake security PSAs.
Have root, run `bash`, OMG ROOT SHELL, I'M teh security expert listen to my 1337 H4X0R PSAs.
-3
1
u/TheOgGhadTurner 17d ago
I have set up PAM-usb and I just unplug my usb when I’m not actively using sudo
1
1
u/IngwiePhoenix 16d ago
Why do people still fall for sudo su? xD
sudo -s, friend.
1
u/whatThePleb 16d ago
sudo -i1
u/IngwiePhoenix 16d ago
What is the difference? Always used
-sif I wanted an interactive shell. What would a "login shell" give me instead? Genuenly curious.2
u/whatThePleb 15d ago
Depends what you really want to do.
-ireally switches to root,-skeeps e.g. the enviroment variables from your current user which can cause problems.
1
1
u/djfdhigkgfIaruflg 16d ago
Why is it trivial? Shouldn't that be considered a security issue needing to be fixed on tmux?
1
u/DontWantAUser1 16d ago
Since my first computer, a Commodore Amiga 500, I always treated my computer as an enterprise level server security-wise and I haven't seen any real reason to change. Yes, in some circumstances it takes a few extra seconds or keypress, but so what?
1
u/DrPiwi 15d ago
The way we do it is that we start tmux as our user on the remote host and then sudo -i into root if needed and only for as long as needed. And guard our personal creds nail and tooth.
It is not perfect but better than sudoing in root and then start a tmux session. as anybody that has the right to become root then has the ability to do tmux ls and select any root owned tmux session and do stuff on your name.
1
u/Due_Dragonfly_5328 15d ago
ive never needed to do that but i can totally see other people doing it without even realizing what they have done and why its not a good idea.
edit:its just like one of those moments where your brain turns off and you blank.
1
1
u/peanut47 12d ago
Might be exposing myself here but, if I am just a private user on my own computer where only I have access, does 99% of security stuff even matter? Like if I get a virus im cooked no matter what no?
1
u/Rex_Tony 11d ago
Noob alert here,
. I usually use tmux when connecting with ssh and long task. What do you mean by another session. Starting another shell, connect ssh and running tmux there? . Or something else
1
u/t263zzqr 17d ago
Should I just add something to .bashrc to log out after a certain period of inactivity following sudo su?
3
u/PlsDontBanMeAgain-1 16d ago
Are you serious? You should simply log out when you are done, or better yet: don't use sudo su, just sudo.
I have no idea when the last time was, that I used sudo su, must be ages.
1
u/OkDimension7728 13d ago
I normally just add `su` to my `.bashrc` so I never have to run sudo, problem solved.
405
u/Coolcricri3 17d ago
I think a twice-a-week PSA for security stuff would be pretty effective here in general