35

The main question: How can I securely connect to my personal computer at home from a workplace computer?

Background: I do much of my work on a university computer, but the computer itself is not fantastic, so I SSH into my home machine to run computations. This system works well, but I am facing a dilemma about how to properly secure my home computer. On one hand, I would like to disable password SSH login and only use SSH keys. However, that would require generating an SSH key on my university computer that could relatively easily be seen/copied/used by others. I also don't want to keep my username/IP address in a config file that is easily viewed by others.

The university computer I use is "mine" in that it is at my desk, but anyone with an account can SSH into it and has read access to my home directory where the SSH keys are stored and I don't have sudo privileges to protect against that.

What do you recommend in order to be able to securely connect from a workplace computer to a personal server?

Improve this question
17
  • 18
    "anyone with an account can SSH into it and has access read access to my home directory" I doubt that. If you set the permissions on a file to owner only (which you can do, as the owner), then only your account can read the file and I very much hope you are not all using the same user account.
    – Nobody
    Commented Oct 2, 2019 at 10:25
  • 2
    @Nobody I just checked again and you are right. I can ssh into another user's home directory, but many of the files and directories are protected so I can't read them.
    – user5728491
    Commented Oct 2, 2019 at 12:58
  • 2
    Why disable password security? Key+password security would add an extra layer of security. There are so many ways to lock down SSH, it's good even just to look through the config man page for options you could apply.
    – oldtechaa
    Commented Oct 2, 2019 at 13:09
  • 13
    In fact, openssh will refuse to use a private key if it detects the file and path to it aren't protected (id_rsa readable by user only, $HOME and .ssh not writable by anyone except user). This doesn't protect you against root accounts, and doesn't help if you're using windows and putty or the like, but at least on Unixes it's hard to have a key that works and isn't protected adequately.
    – Guntram Blohm
    Commented Oct 2, 2019 at 15:50
  • 3
    A (personal) threat model should rely as little as possible on how "good" a university is, or how trustable that airport wifi is. I see it the other way around: OP's threat model really depends more on how wealthy he is or otherwise how valuable his private information, or the chance of impersonating him, may be (which we don't know). That (more than the skills of his university sysadmins) will define his threat model. Remember that SSH key harvesting is a thing. And we don't know where user home dirs are backed up... etc. Just an opinion.
    – jjmontes
    Commented Oct 2, 2019 at 17:59

5 Answers 5

Reset to default
46

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 😉).

Improve this answer
15
  • 6
    "So you set up a separate, limited access for running computations" is possibly the way to go in order to protect the rest of the information on that computer +1. For a generic case, 2FA or ephemeral keys is really the only way to prevent privileged users from getting access to your home account.
    – jjmontes
    Commented Oct 2, 2019 at 17:18
  • 5
    "but using a password on it should provide a similar security to a ssh password, except that you need the key file, too" ­— I don't think that's correct. A password-guessing attack on your login password must be done online, and thus subject to rate limits enforced by the home machine's ssh server (and to being noticed in the logs). An attack on the private key, though, is offline. It can thus proceed much faster — as fast as the attacker's resources allow. So you need a longer password/passphrase for the key vs. the account. I suggest you mention this in your answer.
    – derobert
    Commented Oct 2, 2019 at 19:17
  • 2
    "So you set up a separate, limited access (account/VM/container) for running computations." -- This. As long as they're not the sole admin of the workplace computer, someone can always set up a keylogger or fix the SSH client to save any keys used (at least if we get paranoid enough). But any restrictions they set up at your own end isn't theirs to modify at will.
    – ilkkachu
    Commented Oct 3, 2019 at 14:03
  • 1
    Port Knocking might be a useful addition; the home IP address would no longer appear to have a port open at all, discouraging attacks from the general internet. en.wikipedia.org/wiki/Port_knocking
    – studog
    Commented Oct 3, 2019 at 20:24
  • 1
    @Criggie: it is mentioned: "The ssh key could be stolen, but using a password on it..."
    – Ángel
    Commented Oct 4, 2019 at 22:45
13

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:

I've tried the former and use it often.

Improve this answer
5
  • Krypt seems nice! I will take a look on it later.
    – ThoriumBR
    Commented Oct 1, 2019 at 23:27
  • 4
    Basically, use 2FA?
    – Mast
    Commented Oct 2, 2019 at 11:27
  • I like the idea of 2FA. I tried before setting up Duo, but with no success. I'll give these a try!
    – user5728491
    Commented Oct 2, 2019 at 13:07
  • 2
    @Mast: The solutions I suggested are not specifically 2FA, which is a server-side policy of demanding two independent authentication factors. One simple illustration of this is that you can use Krypton as your only authentication factor. What these do is generate a keypair on external hardware (phone or smartcard), and run some software on your SSH client computer client to forward the protocol's key signing requests to that device.
    – Luis Casillas
    Commented Oct 2, 2019 at 21:07
  • 1
    @Mast it's not technically 2FA as it's a single factor but you can use a "2FA device" like a Yubikey (e.g. developers.yubico.com/PGP/SSH_authentication) to store ssh keys and authenticate in a manner so that the ssh key doesn't leave your hardware token.
    – Peteris
    Commented Oct 2, 2019 at 22:43
9

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.

Improve this answer
1

First some things should be fixed... on a *nix system, even if /home/username has world-read permissions (ie, 755 or a ls -ld ~/ looks like rwxr-xr-x) the ~/.ssh directory and its contents should be 600 (for files) and 700 (for directories). In fact, ssh should refuse to connect if these files are readable by other than the owning user. And if your ~/ needs to be world readable for some reason (ie for Apache to read ~/public_html and serve it up at uni.edu/~username), you can still change the perms on ~/.ssh - just chmod 700 ~/.ssh and chmod 600 ~/.ssh/* will fix that.

As far as connecting securely to your home machine, you can generate a private key on some other trusted machine (like your home machine), copy it to a USB drive or other appropriate portable media using a file system that supports Linux permissions (I'd just format it as ext4 for simplicity) and put the key on that. Then when you are at the uni, you can insert and mount the USB drive and do a ssh -i /path/to/private/keyfile -p <port number> [email protected]

If you are paranoid about someone copying the key from ram on your machine, etc. then you just simply shouldn't connect to anywhere not work related.

Improve this answer
0

As a generic answer, you can't. That's true whether the workplace computer is a Windows PC passed down to you from some prior employee with one shared user account and known malware that nobody has gotten around to removing, or a laptop used only by you with a pristine University-blessed version of "security hardened" Solaris installed on it, or anything in between. Either way, there could be a well-hidden keylogger or remote-access tools.

However, in your particular situation (especially as clarified in comments), you are probably safe using private-key authentication, with filesystem permissions to protect the private key against colleagues in general. To protect against administrators, you need to rely on university policy and their adherence to it; against physical theft of the system, the physical security of your lab or office.

I'll echo Ángel's recommendation to create a separate account for your "work" identity on the home computer. Of course, if you actually are connecting to home for the purpose of accessing personal files, that could add some hassle; but for the stated purpose, it should actually keep out some clutter and distraction.

And once you have the separate account, there are other things you can do to lock it down: iptables rules to keep it from connecting to unneeded parts of the Internet; login-time rules to prevent login when you would never be in the office anyway; rules to limit what IP address can connect to that account.

And of course once such a system is set up, keep an eye on the logs and shut everything down if there's ever a sign of an intruder.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .