SSH from a shared workplace computer
Given that you have a stable computer, I would go ahead and do use ssh keys instead of a password for ssh access (even if you were using a different lab computer each time, a ssh key in a portable usb would probably still be preferable).
The ssh key could be stolen, but using a password on it should provide a similar security to a ssh password, except that you need the key file, too. Yes, the ssh client can be compromised to steal the key passphrase, but the difficulty would be equivalent to that of compromising the client to steal the ssh password. Do remember that you may load ssh identities into an agent in such way that they require confirmation before being used (as well as unloading/not using a ssh-agent at all, although I recommend it).
A hardware token (as recommended by Luis) would be best in protecting the ssh key, but it might not be an option.
As for not showing the IP address you connect to, if you are using the openssh client you want the HashKnownHosts yes ssh_config option (for some distros that's even the default). Probably not really worth hiding, though, it shouldn't be "secret stuff", and cold be easily extracted from network logs.
On the server, as a way to further protect the login from unauthorized random hosts, you could:
- Disable password authentication (that you wanted to do)
- Restrict the users that are able to log in (to the only one allowed)
- Use a non-standard port
- Restrict the IP address that are allowed to connect. Being an University, 'your' computer will have a static outbound IP address, probably even a public IP address just for you. Worst case, restrict to the University range.
These are mostly "additional measures", since they can't deter a determined attacker that abused his superuser power on your computer,¹ but I feel it's good to at least list them for future readers.
However, the important solution to your problem is you don't give general access to your home computer. Since you want to connect through ssh, I assume your home machine will be a Linux/BSD/MacOS one.
You will probably have a user account there from which you perform daily tasks such as browsing the internet, writing (personal) emails, or watching youtube videos. However, you don't need access to any of that, as you only care about computations. So you set up a separate, limited access for running computations. You could be connecting to a Virtual Machine or a container, but just a separate account should serve for your needs. You only need that the hardware is fast(er), an account with a little space and the needed programs installed on the machine would do fine. Some basic Unix permissions that didn't allow other users to access your "home files" would be enough.² Obviously, keep your home computer patched against local escalation exploits.
A second potential issue would be that an attacker that accessed that low-privilege account were to compromise other devices in your local network. As well as securing adequately the other devices, you could either negate all network access to that low-privilege user, or restrict that to outside addresses only.
¹ E.g. the ssh key wouldn't work from other machines, but they could proxy through yours to access
² There are all kinds of processor sidechannels but mostly not relevant, you can disable sshd when accessing it locally, and shouldn't leave sensitive things running anyway (no, you shouldn't leave a CA running there ).
If you're allowed to install and run your own software on that computer, there are solutions that allow you to use key authentication with a key on external hardware like a smartphone or security token:
- https://krypt.co/docs/start/installation.html
- https://developers.yubico.com/PGP/SSH_authentication/
I've tried the former and use it often.
If you want to be secure using a public computer, your best bet is to use multi-factor authentication; e.g., a trusted SSH private key (that only allows access to servers with multi-factor auth setup) as well as using your mobile device as a second factor (either through approval in an app on your device or by typing in a pass code) (e.g., through google authenticator).
Remember all activity on that public computer could be unsafe. Someone may have installed hardware/software keyloggers, an admin as root could be looking inside your private home directory, etc. If you encrypt the SSH key on disk, an admin could dump memory after you decrypted it for use and reconstruct the decrypted version, etc.