In no particular order, try these things:
Check which commands, if any, the current user can execute with sudo:
sudo -l
This will give you some output similar to this:
[sudo] password for daniel:
Matching Defaults entries for daniel on localhost:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin
User daniel may run the following commands on localhost:
(ALL : ALL) ALL
If there is an ALL line in the output similar to above, you can get a root shell:
sudo -s
If the administrators have done only allowed a user to use a specific set of commands, you may be able to leverage one of them to gain a shell. Examples of this are pagers such as more. You may be able to !/bin/bash and have it execute a shell as root.
Notice the settings env reset and mail badpass. The administrator may have set up additional restrictions. Read the manual page for sudoers for more information. In this particular case, if you input a bad password, the systems administrator will receive an email saying that you failed the password attempt. This is likely to get you discovered.
The env reset setting, if not present, will allow you to abuse the PATH environment variable, which may yeild an easy win when executing shell scripts with sudo.
Try to find hashes/passwords already present on the system or elsewhere on the network and try them against other services. This may be very noisy and get you discovered, however.
Check each users ~/.ssh for weak/passwordless keys and try them elsewhere.
Might be able to hijack one and login to other machines, or login as root w/ key locally.
Search for CVEs or use linux-exploit-suggester for kernel exploits.
Figure out which distro and version is running. May be easy as Googling "Distro Version exploit."
Show environment variables. You might get lucky and have a password, key, or something nice in there.
Review everything that is running, especially as root. For example, mysql may be running as root, which may lead to being able to read root-owned files.
Review all of this. There may be something listening localhost only that is vulnerable.
Find suid files. These may have issues that can be leveraged to get root or elevate your privileges to some other service. Figure out versions (--help, --version, dpkg -l |grep package, ...) Cross-reference exploitdb or CVE searches.
Find world-writable files. You may be able to edit these in some way to elevate privileges. Good examples are configuration directories. Some lesser experienced sysadmin will chmod -R 777 /directory if they are having issues with permissions. You can then go in and add/modify configuration settings.
Might have plaintext credentials in config files.
Might have emails containing passwords, keys, etc. May have useful info in crontabs.
You might get lucky and score a password in their .bash_history or even a spreadsheet full of credentials. There may be emails, pcaps, notes, software, keys, etc that will be interesting as well.
You'd be surprised what you find in here, too. Highly situational and depends on what they are running and how it is configured.
Other accounts may be authenticating using plain-text protocols.
Use your imagination here. Might be able to catch them logging in and giving you something nice.