2

I do not mean this to be an opinionated question, I am just trying to see if I am missing something here:

It seems like using a username and password to use the SSH because the username and password can be typed in from any computer whereas a private key needs to be stored on every computer you use for SSH.

Therefore if you want the ability to SSH into a server from any computer you should stick with username and password.

Is this premise correct?

closed as primarily opinion-based by bahamat, Michael Homer, Archemar, Anthon, slm Apr 8 '15 at 12:26

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    I would say yes but the drawback is your risking the security of your machine in a much greater factor than if you were to set up a key pair. – ryekayo Apr 8 '15 at 1:30
  • @ryekayo: I know that this is a comment, and that comments are held to a lower standard of quality than answers.  But, could you please elaborate on how the OP would risk the security of his machine?  Are you talking about keystroke loggers and shoulder surfing? – Scott Apr 8 '15 at 2:42
  • 2
    Because without keys your machine is vulnerable to password cracker programs/brute force attacks. This could also be vulnerable to keystroke loggers as well. – ryekayo Apr 8 '15 at 2:44
  • See Why is using SSH key more secure than using passwords? on Security-SE. – mattdm Apr 8 '15 at 23:26
9

No, because if SSH does not find a valid key, it will fall back to password anyway. Therefore you lose nothing by having keys set up for your main machines.

  • 5
    Unless the server has password authentication disabled... – jasonwryan Apr 8 '15 at 1:40
  • Well, yes, but in that case you definitely shouldn't stick with username & password ;-) – seumasmac Apr 8 '15 at 2:06
  • 2
    The point is that hardened systems will have password authentication disabled altogether, otherwise they would still be subject to brute force attacks… which would in turn mean there are no advantages to having a key because it can be bypassed. – sleblanc Apr 8 '15 at 6:36
  • 1
    The password does not have to be memorizable. You could set up a true random 64 character password that you carry in your wallet. If whoever gets hold of your wallet also knows that you are a server admin and for which servers, and knew to look in your wallet for the password, then you are likely to be in danger of rubber-hosing anyway. – dotancohen Apr 8 '15 at 8:20
  • 1
    dotancohen, at this point you may as well store the key in your wallet. – sleblanc Apr 8 '15 at 19:21
8

whereas a private key needs to be stored on every computer you use for SSH.

This is not a correct way to use SSH. Copying the private key between computers is a weak point that can/should be avoided. The correct way is to generate a keypair at each computer and add all of the public keys to the authorized keys file. You can copy a new public key to another computer you already have access from, and use ssh to update the authorized keys file with the new public key.

Therefore if you want the ability to SSH into a server from any computer you should stick with username and password.

This is kind of true, but your security will suck because you're starting from the premise that you want to access your account from "any computer" (which may have a rootkit, keylogger and/or fake ssh installed).

  • 1
    He didn't say he would copy a private key. He said as you quoted that a private key needs to be stored on every computer, which is correct. Anyway, using password login is not per say insecure. It all depends on the setup. If you for instance have access to hundreds of servers or more, with ldap authentication, it might be quicker to change the password than to invalidate a public key in case of known risk of intrusion. – Johan Apr 8 '15 at 8:01
  • 1
    @Johan Interpreted literally, that's true. But I doubt that was what was meant. OP is concerned about the inconvenience of public key cryptography. In this context, chances are that what was meant is the inconvenience of copying the private key around. There is no implied burden on the user in merely "storing" something on a computer, lots of stuff is stored without the user even being aware. – Atsby Apr 8 '15 at 8:09
  • @Johan Yes, as I pointed out in the answer, what's insecure is accessing your account from a system you don't control. The authentication method matters less. But password authentication facilitates access from just about anywhere, when maybe that isn't the policy you want. – Atsby Apr 8 '15 at 8:12
4

I am just trying to see if I am missing something here

Something that you may take into account is that usually, as a sysadmin, you will have your own workstation and, in this workstation, you will have your user profile with your identity (i.e. your private key). And, if you are using several workstations, ideally, your user environment files will be replicated. Also, if for any reason you cannot be in front of your workstation, you will SSH your workstation with your credentials and, from there, you will ssh the server you want to connect to.

It seems like using a username and password to use the SSH because the username and password can be typed in from any computer whereas a private key needs to be stored on every computer you use for SSH.

If you can remember the passwords for all your servers, then your passwords are bad. If you need to access a document where the passwords are stored in order to remember them, then you can also retrieve your private key.

1

Using password authentication on your systems is bad practice for multiple reasons:

  • As Atsby said, being able to connect from any computer also enables any computer to potentially connect to your systems, even compromised ones. Sticking to trusted machines is in your best interests.

  • With password authentication enabled, a remote attacker can always bypass public key authentication and log in with your password. You are now 100% vulnerable if one of your machines is compromised with a keylogger.

  • Furthermore, if you encourage the behavior of logging in from random remote machines, you will eventually stop checking the remote server's fingerprint is ok and you will be exposed to all sorts of MITM attacks! This means you believe you are connecting to the server you wish to join, but in reality you are connecting to a different server, or your connection is decrypted by an intermediary then re-encrypted and sent to the real server.

0

a private key needs to be stored on every computer you use for SSH.

The second paragraph (specifically, I'm focusing on this part, that I quoted above) is correct: if you log in from multiple machines, you'll need to have the private key accessible from multiple machines. This means a few things. First, each machine that you log in from will need to be trusted to not do terrible things with your private key. Malicious machines cannot be trusted. Second, you'll need to figure out a way to get your private key onto those machines. That may be inconvenient.

There are a couple of ways around this, if you want to be able to log in from multiple machines. One way is to log in from a less secure machine to a secure machine, and have the secure machine store the key(s) that work with various other systems. This still leaves a weak link in the security chain, because then an attacker could try to get your password to the middle machine. Once that is obtained, the attacker could probably access the keys that get you into other systems. However, the good news is that you're not needing to place your private key on every computer you go to, so this does offer a convenience factor.

Another way is to use one-time credentials. (More commonly known as: one-time passwords.) With this method, you can use a trusted device to generate a passphrase. I know some people have used their smart phones. Then, you really don't care if your key is compromised (stolen/copied) after you have successfully used the passphrase, because the passphrase isn't any good after that anyway.

Working with one-time passphrases may be slightly more convenient if you typically log into the same system, as some software might remember some details (like a sequence number) which would require less manual work on your part. You could combine these methods: use a one-time passphrase at the start of your SSH activity, and log into a trusted system. Then reference the key files on that system to log into other systems.

Therefore if you want the ability to SSH into a server from any computer you should stick with username and password.

Therefore, the third paragraph is a part of your premise that I'm not agreeing with, because I interpret your question as meaning that you should stick with the way you've been doing things, using a standard password. Instead, use the passphrases that are part of the "one-time password" methods. This way, you use a more complex security method (providing better security, like what key files do), but use one that doesn't require untrusted machines to use key files.

To point you in a right direction, OpenSSH supports one-time passwords via the skey method, using a program called skeyinit. Then, to generate the passphrases on a mobile device, OTPdroid for Android also supports this. There may be other workable solutions, but this is simply describing some resources that are known to work well with each other.

On a side note: with the situation you're describing (multiple systems), I highly recommend that you get familiar with terminal multiplexers (tmux or screen). It will let you do some work (for instance, logging in from the middle system into other systems), and then detach a session. Then, after you perform the initial login from another machine, you can resume a detached session, and some of your mundane work (like logging into other machines) might not need to be done again.

Not the answer you're looking for? Browse other questions tagged or ask your own question.