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?

Anders
  • 65,582
  • 24
  • 185
  • 221
user5728491
  • 453
  • 4
  • 7
  • 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 Oct 02 '19 at 10:25
  • @Nobody Home computers aren't always as properly configured as they should, so it isn't such a crazy idea. – Mast Oct 02 '19 at 11:26
  • @Mastc This is a university computer. – Nobody Oct 02 '19 at 12:34
  • 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 Oct 02 '19 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 Oct 02 '19 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 Oct 02 '19 at 15:50
  • 1
    @Nobody still any sysadmin or domain admin will be able to read that and there may be many admin acounts in a university, and many ot them even unaccounted for. I would recommend treating such a computer as compromised by default. – jjmontes Oct 02 '19 at 17:18
  • @jjmontes That depends on your threat model. For your average (phd or other) student in a good university I think you can trust the accounts given to you by the university to be pretty secure for most purposes. For university employees, probably even more so. – Nobody Oct 02 '19 at 17:45
  • 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 Oct 02 '19 at 17:59
  • 1
    The ssh key protection part could easiest be solved by keeping it on a USB key. Extra steps would be creating a separate "from-uni" user account with a very restricted home and shell, just in case someone /does/ get in. – WooShell Oct 03 '19 at 06:32
  • 1
    FYI you can protect your SSH key with a password – Robert Riedl Oct 03 '19 at 08:43
  • @GuntramBlohm: I think you've got it the wrong way around. Windows security is tighter by design; even the Administrator account cannot be used to read users' files. Administrators can take ownership of files, like root can on Unix, but they cannot undo that. – MSalters Oct 03 '19 at 10:27
  • @RobertRiedl ...and still that doesn't protect you from admins, if you type that password (or insert that USB stick) into a university computer. – Federico Poloni Oct 03 '19 at 16:18
  • I have similar problem and plan to use YubiKey for one time passwords. Unfortunately their solution is not exactly the same with my idea and have to program and change linux login. Have to see whether they have new solutions for SSH. In short, YubiKey can work as USB keyboard. There is button - when you touch it, one time password string (with Enter at the end) is sent as sequence of keys. Keylogger can store the password but it is not valid for next login. The only unprotected part is the SSH session on screen. – i486 Oct 03 '19 at 17:05
  • @MSalters - Whilst Win security has dramatically improved in recent years, suggesting that it is "tighter by design" is bizarre. I guess you could argue that using "default settings" that may be the case. But a Win Admin merely has to add the "Take ownership of files or other objects" permission (for the files in question). Obviously if a Win network is set up properly, only specific "super-admins" would have the ability to do that, but similar config could be done in Linux. – Jeremy Davis Oct 04 '19 at 00:28
  • @FedericoPoloni, I mean, only if they have set up some sort of keylogger...? otherwise passwords entered to ssh (or ssh-agent) are not safed or displayed anywhere – Robert Riedl Oct 04 '19 at 06:22
  • I suppose I should have mentioned that both computers are running Linux. The main concern is to prevent "crimes of opportunity". I don't want to leave the front door to my network wide open to someone who 1) knows the correct username/ip address/port and 2) knows where the key is / what the password is (keylogger perhaps). – user5728491 Oct 04 '19 at 17:34

5 Answers5

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

Ángel
  • 18,824
  • 3
  • 28
  • 65
  • I like the 2FA idea, but this answer gets at my main concerns. Currently my normal user has sudo privileges I use it to administer my entire home network (raspberry pi cluster, multiple computers, etc...) so I really don't want someone to have access to my whole home network through this computer. Thanks! – user5728491 Oct 02 '19 at 13:07
  • 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 Oct 02 '19 at 17:18
  • Might also consider using totp. – R.. GitHub STOP HELPING ICE Oct 02 '19 at 17:22
  • 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 Oct 02 '19 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 Oct 03 '19 at 14:03
  • Also remember that if this is a computer set up by the University and your traffic is going out through the University firewalls, the admins have everything they need for a man-in-the-middle snoop or attack. You would have to implement more extreme measures such as getting keys issued by an outside certificate authority. – doneal24 Oct 03 '19 at 16:41
  • SSH key file can be stolen and password can be seen or logged with keylogger. – i486 Oct 03 '19 at 16:57
  • 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. https://en.wikipedia.org/wiki/Port_knocking – studog Oct 03 '19 at 20:24
  • Might I suggest mentioning adding a passphase to the key? Its not exactly 2FA but it does require a password/phrase to unlock and load the key into a keyagent – Criggie Oct 04 '19 at 07:11
  • 1
    @Criggie: it is mentioned: "The ssh key could be stolen, but using a password on it..." – Ángel Oct 04 '19 at 22:45
  • @studog an iptables rule that drops everything not coming from the IP address of OP work computer would be more effective and also easier to implement and use. – Ángel Oct 04 '19 at 22:47
  • @Ángel Fair enough - I'm making a distinction between any kind of authentication password and an unlock password that is on the ssh key itself before it can be used. The word "password" is somewhat overloaded with distinct meanings here. – Criggie Oct 04 '19 at 23:34
  • @Criggie well, I could have not mentioned password-protecting the ssh key given I would take that for given. The 'password for ssh access' and the 'password on it' are different types of password, but it seems to be quite clear what they are about, imho. – Ángel Oct 05 '19 at 00:02
  • "Use a non-standard port" - Isn't that security by obscurity ? While your other tips (disable pw, define users, restrict allowed IPs) add security benefits, this one does not, in my opinion. – Robert Riedl Oct 06 '19 at 09:41
  • You could argue that it might add up to 16 bits of entropy. Probably zero in this case, where the potential attacker could see your connections or your known_hosts file. It is a common advice, but its main benefit is to spare you a lot of botnet login attempts. – Ángel Oct 07 '19 at 00:55
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.

Luis Casillas
  • 10,681
  • 2
  • 30
  • 42
  • Krypt seems nice! I will take a look on it later. – ThoriumBR Oct 01 '19 at 23:27
  • 4
    Basically, use 2FA? – Mast Oct 02 '19 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 Oct 02 '19 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 Oct 02 '19 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. https://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 Oct 02 '19 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.

dr jimbob
  • 39,312
  • 8
  • 94
  • 164
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> username@ip.or.domain.name

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.

ivanivan
  • 339
  • 1
  • 4
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.

david
  • 721
  • 3
  • 11