If the password used for the user, in the remote machine, is different from that of the machine he/she is connecting from, the attacker will not be able to gain root access, even if the account has permission to escalate priviledges.
- attach to an existing screen session that has an existing process under sudo inside it
- edit .bashrc to alias sudo to something that records the password, then come back later
- spawn a background process that waits for the user to run sudo, then opens the pty and uses TIOCSTI to type commands at it
Also, if the attacker actually has control over the sysadmin's local machine, they can do a lot more damage, like any of the above locally, or
- send an email from the admin's account to the team saying "Hi, I'm trying to run this command but I left my RSA token at home, can anyone help?"
- add a browser extension that rewrites all <pre> tags to include a https://thejh.net/misc/website-terminal-copy-paste -style attack
- commit to code or configuration-management repos adding a back door and trigger a deployment
None of these are technically difficult attacks. Requiring a separate sudo password might slow down a script kiddie, but that's about it.
First, sudo should not be cached for this very reason. Second, agent caching should never be enabled for this very reason. Third, agent forwarding should never be enabled for this very reason.
Indeed, using key authentication to log in and then using a password to upgrade to sudo is, I think, very reasonable.
which most often is not the default on vps/root/clouds, that's basically my point. if you use sudo, use it with a password.