Safer Access without Passwords

How do you make sure that your passwords are safe? You can make them longer, complicate them by adding odd characters, making sure to use different passwords for each user account that you have. Or, you can simply skip them all together.

The secure shell, ssh, is a key tool in any Linux user's toolbox. As soon as you have more than one machine to interact with, ssh is the obvious choice.

When logging into a remote machine through ssh, you are usually prompted with the remote user's password. An alternative to this is to use an asymmetric key pair.

An asymmetric key pair consists of a private and public key. These are generated from an algorithm - either RSA or DSA. RSA has been around for a long time and is widely supported, even by old legacy implementations. DSA is safer, but requires v2 of the ssh protocol. This is not much of an issue in an open source world - keeping the ssh daemon implementation up to date is not a problem, but rather a requirement. Thus, DSA is the recommended choice, unless you have any specific reason to pick RSA.

The generated keys are larger than a common user password. RSA keys are at least 768 bits, default 2048 bits. DSA keys are 1024, as the standard specifies this.

To generate a DSA key, use the following command:

$ ssh-keygen -t dsa

This generates the files ~/.ssh/id_dsa and ~/.ssh/id_dsa.pub. You can specify a passphrase in the key generation process. This means that they key only can be used in combination with a passphrase, adding to the security.

The generated file ending with pub is the public half of the pair. This can be shared with remote hosts that you want to ssh to. The other file, id_dsa, is the private half of the pair. This must be protected just as you password. I.e. do not mail this, do not store it on untrusted machines, etc.

Having a 1024 bits long key can be thought of as having a 128 characters long password. This means that the key pair method is safer than most passwords that you can remember. Keys are also completely random, so they cannot be cracked using dictionary attacks. This means that you can increase the safety of your remote host by disabling logins using passwords, thus forcing all users to use key pairs.

Having generated your key pair, all that is left is copying the public half of the key to the remote machine. You do that using the ssh-copy-id command.

$ ssh-copy-id -i ~/.ssh/id_dsa.pub user@remote

This adds your key to the remote machine's list of authorized keys. Just to be on the safe side, it is also good to ensure that the ~/.ssh and ~/.ssh/authorized_keys aren't writable by any other user than you. You might have to fix this using chmod.

Having added the key to the remote machine, you should now be able to ssh to it without using a password.

$ ssh user@remote

This applies to all sshd-based mechanisms. So you can scp freely, as well as mount parts of the remote file system using sshfs.

One potential catch twenty two issue here is if the remote machine does not allow password-based logins. Then the ssh-copy-id command will not work. Instead you will have to take the contents of the public key half and manually add it as a new line to the ~/.ssh/authorized_keys file on the remote machine. This is what the ssh-copy-id command does for you.

This also tells you what to do if a key is compromised, or simply falls into disuse. Simply remove the corresponding line from the remote's list of authorized keys. You can usually recognize the key in question from the end of the line where it reads username@hostname.

So, until next time, no more passwords!

______________________

Johan Thelin is a consultant working with Qt, embedded and free
software. On-line, he is known as e8johan.

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Congrtulations Johan! ;)

Wavebourn's picture

Well written article, but suppose now some nasty people know your habits, and they may assume that you have some site called admin.t[*]s.s[?] that has password-less access to all your servers list of which can be obtained from bash history. However, despite ssh is run on the host, it refuses connection from unknown addresses. But it is not a big deal: you are running Apache there. However, no starting page exists, and it is unknown which modules it runs, but if that person is really nasty and he/she knows that there is some host in your network that has access to all other hosts, the solution can be found..

I don't want to frighten you, I'm just a bit paranoid myself last time. :)))

Best regards!
Anatoliy

Ezeelogin

bastian's picture

Hi all,

We have a ssh gateway tool with which we can add the server from webpanel and access the list of servers passwordless we have used key based authenication here. Ezeelogin have may features like mas password change in all servers, Parallel shell and MCopy shells are it great advantages

Kerberos

On Lawn's picture

For passwordless entry, I'd recommend looking into true single sign on solutions. Kerberos, for instance, has done a great job with creating a secure key management, as well as addressing the concerns noted above.

It also integrates cleaner (IMHO, though not completely) with Windows logins.

Just two cents to through out there in the discussion.

I too was hoping to see more discussion of passwordless as in smartcards, or biometrics, etc...

Remote login via synchronous

Lesserdevil's picture

Remote login via synchronous machines opens up the key generator to derandomization. SSH is a sucker's bet for anyone with real commerce linked into their web system. A coordinated attack will simply bypass the authentication procedure of SSH, as has been witnessed. Nothing beats analog.

some comments...

Cristian's picture

Hi, nice post but I feel the tile is a bit misleading... I really thought there won't be any password at all, not even RSA or DSA (which are password-like and even you mentioned that "Having a 1024 bits long key can be thought of as having a 128 characters long password"). Thus, an option for the tile of this article could also have been "safe access without typing passwords". Don't get me wrong, I just gave the reason why I was expecting to read something else in this post.

Now, the content is correct and I'd like to add here (as it might be the right spot) the way in which a key could be copied from the local machine's .ssh/id_rsa.pub into the server's .ssh/authorized_keys:

$ cat .ssh/id_rsa.pub | ssh user@server 'cat >>/home/user/.ssh/authorized_keys'

Of course one needs to know the exact location of the authorized_keys file and to have rights to write it.

I personally like using these rsa or dsa keys but the drawback of the method is that one might forget the actual password because of its highly decreased usage. :-)

Using One Time Passwords with SSH

Andrew Stringer's picture

I agree with many of the points above, passwords on their own can be sniffed if a keylogger is on the machine you are attempting access from. Having and ssl key with a passphrase is an improvement, but the key has to be processed on the potentially compromised computer and the passphrase can be recorded just as easily as a password by a keylogger.

I have started to us one time paswords with a pam module called Barada. This uses your android phone as a passphrase generator, secured with a PIN.
Your login application, either ssh or other needs to support pam of course, on the target machine, you register users and create a seed which is copied to the phone app. To log in, you enter a PIN in to the phone app which creates a 6digit passphrase which is entered in place of your password. This is time limited to approx a 2 minute window.
If this passphrase is logged, it is of no consequence as it is not valid for reuse.
As far as I can see, this represents the best combination of security.

yubikey

asdmin's picture

I can recommend yubikey for OTP purposes.

false sense of improved security

Mozai's picture

Using keyfiles for access does not improve security -- it only changes it from "what you know" to "what you have." People who believe that using keyfiles is "better" than passwords get careless, and make the same mistakes that password-users are chastised for.

I've had sysadmins arrogantly tell me that they are "more secure" for using ssh keys on all their machines. One of these sysadmins had every machine in his care compromised when one machine holding his keys was broken into. It was a mess.

Losing a key is bad, yes.

Johan Thelin's picture

Losing a key is bad, yes. However, from a brute force attack perspective, it is safer.

Johan Thelin is a consultant working with Qt, embedded and free
software. On-line, he is known as e8johan.

No, loosing a *password-less* key is *extremely* bad

Clif Bratcher's picture

What's worse, someone beating on your door until it opens, or someone entering your home with the keys you left on the doorstep?

From a brute-force, zero-knowledge perspective, yes, PKE is considered more secure than a complex password. That said, you can generally assume an attacker has some knowledge of their target.

Lets assume an attacker has somehow discovered your password on some remote system. They log into this system and check the history for juicy bits. Hmmm, someone is using ssh. Oh look, they have keys in .ssh. Let's try running that ssh command with those keys. Jackpot! No password!

In this sense, they're far worse than simply using complex passwords. It's akin to leaving your complex passwords in a text file in your home directory. It's immediately attributable to you, and extremely simple to see which host(s) they might apply to.

Password-protected keys protect you in two ways:

1) If you should ever "lose" or a private key, you can be reasonably confident that the system the public key resides on has not been compromised. Delete the public key, and regenerate.
2) If and when quantum computing reaches the expectations of Shor's factorization, you're not immediately susceptible.

I'd also like to mention that DSA is a bad choice without even delving into the technical aspects. It was designed without crypto community peer review, and has very little positive or negative public commentary.

-Clif

How do you know DSA is safer?

Merlin's picture

How do you know DSA is safer than RSA? I've looked for this online and I cannot find any references.

re: How do you know DSA is safer?

Anders Lugnér's picture

In the PuTTY User Manual, section 8.2.2, it's argued that RSA is more safe. I'm not an expert on this, just noticed it.

passphrase

Bersam's picture

but your private ssh key needed passphrase at all, but it really safer than using simple password.

Mix standard password and file password

enzo's picture

Is it possible to enable the access to ssh through password only from the computers of some networks, ie. secure or local network, and require only access throught ida or rsa authotization files from others ?

[quote]This is what the

gt's picture

[quote]This is what the ssd-copy-id command does for you.[/qoute]

There's a typo here, ssd-copy-id should be ssh-copy-id.

Thanks. I fixed this.

Johan Thelin's picture

Thanks. I fixed this.

Johan Thelin is a consultant working with Qt, embedded and free
software. On-line, he is known as e8johan.

Generally agree to this article

nefutpowers's picture

Yeah, after we used keys in our enviroment instead of passwords, that worked wonders in memorizing stuff. One sure way to amplify the security is to block off root from remote access/SSH and just make sure that the remote user is just a plain user (potentially in the sudoers list). Elevating the permissions once you have remote access to the box is another thing to be considered aside from shell accesss.
While physical security is another aspect of the overall security recommendation, loosing (or leaking) your keys represents a bigger problem than just loosing that. It begs the question: what else are you loosing?
Ah, but yes, going back to using keys instead of passphrases, and the other bigger implementation of having transparent authenticationvia keys to log on multiple hosts via SSH (after taking care of both perimeter and physical securiity) is a beauty.

Passwordless key not necessarily safer

AnilG's picture

As others have commented it is an important point that using a passwordless key only moves the security to the key file. On a windows machine, for instance, that key file may not be very safe at all. Users also need to be aware to keep their workstation physically secure.

To genuinely increase security use the key with a pass phrase, there are applications which will assist the user to manage pass phrase caching as well. The article could have at least indicated that these systems exist, even if the actual use was out of scope.

agreed - the pragmatic view

Andrew Rimmer's picture

agreed - the pragmatic view would be to use a key management agent / keychain type system for the times when repeatedly typing in a passphrase becomes too onerous.

Even with keychain type management implemented on Ubuntu etc. you are only as as safe as the master passphrase for either the key or the key manager - possibly think about using a smartcard to hold the keys and certificates. Fiddly to set up but pretty robust once set up.

agents

bitlord's picture

Nice job but you forgot a step or maybe you should add this feature. There is not mention of the agent. You need to do script or run the following commands.

ssh-agent
ssh-add

If you don't do this the remote server will ask you for your passphrase.
You do this then you just type user@server and your in, no intervention needed. If you don't want to use password then you would you want to type in a passphrase?

You need a script if you don't want a lot of agents running.

agent

bitlord's picture

Nice job but you forgot a step or maybe you should add this feature. There is not mention of the agent. You need to do script or run the following commands.

ssh-agent
ssh-add

If you don't do this the remote server will ask you for your passphrase.
You do this then you just type user@server and your in, no intervention needed.

You need a script if you don't want a lot of agents running.

agent

bitlord's picture

Nice job but you forgot a step or maybe you should add this feature. There is not mention of the agent. You need to do script or run the following commands.

ssh-agent
ssh-add

If you don't do this the remote server will ask you for your passphrase.
You do this then you just type user@server and your in, no intervention needed.

You need a script if you don't want a lot of agents running.

Promoting Bad Security

Anonymous's picture

I’m amazed this article does not put more emphasis on entering a passphrase, in fact it almost suggests that it is optional. Creating a private key that is not encrypted is a major security risk, especially if your computer is compromised and your private key is stolen.

Actually, using a passphrase

Johan Thelin's picture

Actually, using a passphrase key can be argued to be more safe than a 1234 life time password. But, yes, a passphrase is recommended and I could have pushed that point.

Johan Thelin is a consultant working with Qt, embedded and free
software. On-line, he is known as e8johan.

All that glitters is not gold

sorrillo's picture

I don't like writing my passwords into a text file or an excel. If someone gets access to this file he will have access to all my accounts and servers.

I prefer to memorize the password, or better yet the formula, so no one can steal it from me.

The private key is not so different than a plain text file with the passwords. If your computer gets compromised your password can be stolen simply by copying a file.

Of course if your computer gets compromised you have to face the risk of a keylogger as well, which is effective against any password.

Then there's the mobility as well. If you use a memorized password you will not have to worry about carrying a USB drive with your private key in a truecrypt container or whatever way you protect the data from losing it or being stolen. And you will not have to worry about securely deleting the private key from whatever computer you decide to use it. Just, again, only about the keyloggers.

I suppose what I am saying is that there is no magic solution for security, everything has it's risks and it's benefits. Just use whatever method fits better in your case.

Of course there's always the option to use a public/private key and a password if you are paranoid enough ;-)

I was meaning to say what you

Johan Thelin's picture

I was meaning to say what you finish your reply with. You can combine a key with a passphrase of choice, thus increasing security.

And you are right. In a mobile world, key files are harder to manage.

But under ordinary circumstances (nothing stolen) keys add to security and convenience, and you can revoke a key. That might be harder to do if someone takes over your password.

Johan Thelin is a consultant working with Qt, embedded and free
software. On-line, he is known as e8johan.

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState