Slashdot Mirror
OpenSSH Management - Understanding RSA/DSA Authent
Paul writes "I found this useful article, over at developerWorks Linux Zone that clearly explains RSA/DSA authentication. It covers what you need to get passwordless authentication implemented using RSA and DSA authentication protocols."
OpenBSD and OpenSSH are both all-American products. Canada is, after all, a renegade 51st State we just have not bothered to annex yet.
There are ways of combatting this, but I haven't read the SSH protocol docs in detail, so I can't tell you what they do to deal with it. I can tell you that a Server fingerprinting mechanism exists which allows you to positively identify the server you are talking to if you already know what the fingerprint is supposed to be. Most SSH clients cache the fingerprint from each server you access the first time you connect. If it changes, you are warned. Of course, if the Man in the Middle attack occurs the first time you connect, you are screwed.
I also can tell you that the answer to the last question is "No, so far." The magic of the RSA algorithm is that you can give an attacker your public key (from which he can generate as many encrypted/unencrypted challenge pairs as he likes), and so far no one has a good (i.e. "fast") way to get the private key.
> My question is this: are there any standard free
> (as in GNU) C or C++ math libraries for handling
> massive bit-widths like you get in RSA keys?
You want gmp, the GNU Multiprecision Library. The latest release is 3.1.1, available from ftp://ftp.gnu.org/gnu/gmp/ .
They hook people with the convenience aspect, and they do explain how it's more secure (everything going over the wire is only good for a single connection; the remote machine never sees the password at all).
The convenience actually comes in the next part (or when you type "man ssh-agent"): you can have a local program remember your keys after you give it the passphrase once, and then you can authenticate multiple connections with a single use of the passphrase. Really nice for those cvs over ssh sessions (add, add, update, update, commit).
Also, it means you can have the authentication even closer than the local machine (an even more local machine, smart card, etc) without the remote machine having to know or do anything different.
This seems to me to say that when our client decrypts the servers random-number challenge, it sends back the decrypted random number in the clear. This is fine as long as the algorithm used is never compromised, but if it is, wouldn't the cleartext random number help an eavesdropper decrypt the session? Wouldn't it be better to re-encrypt the random number using the server's public key and send that?
-- Old Man Kensey
Actually, you can use another identity and restrict what it does. On the server machine you can put an entry for the second key on your .authorized_keys which reads like: (blame /-code for the ugly formatting)
And presto, you have a passphraseless passwordless authorization that can perform a specific action on the remote host only if the connection comes from a trusted box. There are other options, you can read it all in sshd(8).
It irks me that I have to log in with a password and then give another password for my ssh keypair. Someone started writing a PAM module that would let you log in if you could give the correct passphrase for your ssh key; have any Linux distributions started using it?
-- Ed Avis ed@membled.com
The two password problem is due to the fact that the solution being discussed is pretty adhoc -- Unix systems by in large rely on local authentication (/etc/passwd) and SSH is primarily designed to be a secure replacement for telnet. And as for "same user experience" -- having multiple passwords is usually a bad user experience and leads to all sorts of other security problems.
Now, if you substitute some form of directory system (Kerberos/LDAP/NDS/AD/NIS/whatever), you could have a system where you are externally authenticated as you login, and then you use that authentication to seemlessly get the proper level of access on remote machines through encrypted connections. Doesn't help you get a shell at your hosting company's webserver, but a better solution for institutional use than SSH.
--
Business. Numbers. Money. People. Computer World.
/.
I read the man pages for each release of OpenSSH as they came out. And eventually, with the help of several articles found on Google, I figured out how to do SSH V2 passwordless login and file transfer.
The most recent release of the OpenSSH docs is much better than previous, and I recommend everyone upgrade their packages. And much kudos to the OpenSSH team - they are fixing the docs, and the software is truly great.
But you won't understand everything you need to from the man pages unless you already grok rsh, rlogin, rcp, bind & name resolution, etc. The man pages are for people who are replacing insecure protocols, and who already understand them... not for people starting from a blank slate. Newbies should read this article, and the next one when it comes out, and Jay Beale's stuff too.
--Charlie
***note VERSION ONE of SSH is NO GOOD you may as well use RLOGIN. And you should not allow rhosts files on your systems for any reason.***
No, you are right, as far as you've gone. If you use a single password (or single key, or single passphrase) to secure multiple systems then you multiply the damage incurred if a that password (or whatever) is compromised. /. and my named user accounts don't have any fancified privileges. The boxes that share root passwords are physically set up so that anyone who gains root on one can easily do so on the others, anyway (NFS sucks, may I say here?).
There is no real way around this, but often this is an acceptable risk. For example, I use the same password on K5 and slashdot, a different one for all my named user accounts, and several machines at work share a root password. All my machines at home have the same root (not the same as any mentioned above, though) password.
This works because I don't care if anyone else pretends to be me on K5 or
So, manage your exposure as required by your circumstances. Remember keystroke loggers catch ALL passwords, and the only truly secure box is powered down in a locked room.
--Charlie
How is it that SSH2 can use a signature algorithm to do real encryption?
DSA is used for authentication only. All other communication is encrypted with a different cipher, like 3des or blowfish.
SSH2 works similarily to SSH1. The differences are:
1.) You need to use the -t option with ssh-keygen (i.e. ssh-keygen -t dsa) and
2.) The file names are different. For DSA, the file name is ~/.ssh/id_dsa instead of ~/.ssh/identity, and so forth.
Sorry about the somewhat off-topic post, but while we're on the subject, is there an equivalent to ssh-agent/ssh-add for gnupg?
--
Reading over the comments here, it seems that people don't seem to understand the benefits of using a passphrase to unlock your key over simply using a password. Well, as long as you trust that nobody but you is going to be using your workstation (from the console - other people logged in remotely is fine) until you log out, you can put something like this in your .xinitrc file:
/dev/null & sleep 5 ; exec wmaker'
:)
And since it works through environment variables, which are passed on to children but not to other processes, the only processes which will have access to the ssh-agent are wmaker (or whatever window manager you're using) and its children - namely, anything you're running in X. It's fairly secure.
exec ssh-agent sh -c 'ssh-add <
This pops up a window which asks for your passphrase, then ssh-agent stays resident with your unlocked secret key. After 5 seconds, it spawns windowmaker (obviously, replace this with your wm of choice).
It sets an environment variable (SSH_AGENT_PID) with the process ID of ssh-agent and another one (SSH_AUTH_SOCK) which is the socket to use to communicate with ssh-agent. So when you try to ssh to somewhere, ssh checks for these variables and gets your unlocked key from ssh-agent transparently, and you ssh with no password. But without your passphrase to unlock it at the beginning of your X session, nobody else can use it (don't forget to xlock if you go anywhere
--
But yes, if the keystrokes were the (only) relevent part of the generation of the key, it would be a non-random key that could be actively predicted by repeating the phrase. This can be modified by a proper random seed to mangle the phrase appropriately, but then everything depends on the randomness of that random seed. :)
The password never gets sent to the server, though. That's the key difference. You get a challenge sent to you, and if you can use your private key to sign the challenge, you are allowed access.
Hmmm... The way I understood the article, you're not signing; you're decrypting. The server that you are logging into sends you a random number which it has encrypted using your public key. Ssh on your end then decrypts that number using your private key and sends it back to the server. If it matches what the server originally generated, you're in.
"Intelligence is the ability to avoid doing work, yet getting the work done".
It's only software!
Actually OpenSSH wasn't developed in the U.S. As part of the OpenBSD project, it was developed internationally (much of it here in Canada) *because* of American restrictions on encryption exports. Take a look at openssh.org for some more info, specifically their history page.
"Intelligence is the ability to avoid doing work, yet getting the work done".
It's only software!
That's absolutely true, but using ssh-agent in this way, your actual account has to be compromised now; someone has to log in as you by getting your local password first.
Using only a private key with no passphrase for authentication is slightly less secure because in that case, someone would just need to *obtain* that key somehow. That could be accomplished by exploiting various bugs, using trojan scripts, or just plain old user stupidity (i.e. accidentally emailing it out to a mailing list-- worse things have happened!)
"Intelligence is the ability to avoid doing work, yet getting the work done".
It's only software!
For Version 1:
ssh-keygen .ssh/identity.pub targethost:fooid
.ssh
.ssh/authorized_keys
[return]
[return]
[return]
scp
[type password]
ssh targethost
[type password]
mkdir
cat fooid >>
Done. Now, if you want version 2 (DSA-based):
ssh-keygen -t dsa .ssh/id_dsa.pub targethost:fooid2
.ssh
.ssh/authorized_keys2
[return]
[return]
[return]
scp
[type password]
ssh targethost
[type password]
mkdir
cat fooid2 >>
The "cd" command may fail, if you already have a .ssh directory on your target system.
You probably want to have a look at your permissions as well. Homedir and .ssh should be world readable and executable. .ssh/* should be readable except for .identity, id_dsa and random_seed which should only be readable/writeable by owner. You should also own all of the above files.
--
Aaron Sherman (ajs@ajs.com)
The problem with passwords is that there are some legitimate uses for SSH even if you're not around.
The classic example is using a SSH tunnel to retrieve mail from an ISP that doesn't support encrypted POP/IMAP sessions. I've also seen it used to implement a secure alternative to NIS.
While you could, theoretically, specify a different "identity" file for automated scripts, it offers little benefit since SSH doesn't provide a way of restricting rights based on the public key.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
You know you're a hardcore slasdotter when:
17) You have two accounts with moderation points at the same time -- and you know about it.
--
Sometimes boldness is in fashion. Sometimes only the brave will be bold.
The password never gets sent to the server, though. That's the key difference. You get a challenge sent to you, and if you can use your private key to sign the challenge, you are allowed access.
You can copy your public key all over the place without compromising your password this way. Your password never leaves the local host.
Erm, I'm not entirely sure what you're asking -- your public key is already at the server, so your signing (or decryption, as someone else pointed out... I'm no expert so I am not sure which one...) is validated against the server's copy of your public key. Is that what you were wondering?
No.. see, the random number sent to you is encrypted... it can only be decrypted by your private key. By the time you send it back to the server, its of no use to the sniffer. The next time there will be a different number encrypted and sent, which they can't decrypt since they don't have your private key.
"Of all days, the day on which one has not laughed is the most surely the one wasted." -Sebastian Roch Nicol
OpenSSL is a library, not a set of programs like OpenSSH is. OpenSSH uses the OpenSSL library to do the encryption. You can find API documentation for OpenSSL here.
The article treats RSA and DSA as one entity, and doesn't explain how they differ. I did some research and found that RSA is a cryptographic algorithm based on public and private key pairs, which we already know. So far, so good. Then I searched for DSA and found that it stands for Digital Signature Algorithm. Furthermore, that page says that DSA is only usable for signing, and not actual encryption.
This leads on to my question: The article says that SSH1 used the patented RSA key, but SSH2 uses DSA keys to work around the patent. How is it that SSH2 can use a signature algorithm to do real encryption?
Ergo, my use of "passphraseless" instead of "passwordless".
This one is a little bit dated, but it is still pretty good. It is written by Jay Beale, from the Bastille Linux project.
Stupid, Stupid Protocols: Telnet, FTP, rsh/rcp/rlogin
~Religion is O.K., as long as it gets you laid.
No, the DMCA only applies to copy protection, and this encryption scheme is not designed to prevent copies from being made.
The only "intuitive" interface is the nipple. After that, it's all learned.
"The question of whether a computer can think is no more interesting than that of whether a submarine can swim" -EWD
Actually, you do have to use a passphrase once if you set things up right. By using ssh-agent and ssh-add you can store all your ssh identities with the agent and only enter the passphrase when the identities are added to the agent. If you're using Debian and OpenSSH this is already set up for you automatically under x-windows. Just add the identities with ssh-add and you're ready to go. Another useful thing is that if you've multiple identities with the same passphrase, you can add them all at once without typing the passphrase multiple times. This is particularly useful if your passphrase is an actual PHRASE (like mine) and tends to be a pain to type repeatedly (it often takes me two or three tries to get mine right.. ).
I've wrestled with reality for 35 years and I'm happy to say, I finally won out - Elwood P. Dowd
He said "article", not software. The article is written by a usan, published on usan servers. He might be sketchy about the applicability of 1992-era ITAR to web pages, but I wouldn't bet on it.
No, the DMCA applies to "access control mechanisms" which this scheme is. This scheme is flawed in a different way -- it's not for controlling access to materials copyrighted by the party in question. In other words, you can't argue that you're controlling access to material whose copyright you don't own.
If they've got root, they can just install a trojan ssh client as easily, and capture your pass(word|phrase|key) regardless of how you're storing it.
The man pages for ssh/sshd are excellent.
You'll get a lot more by just reading them than this article. (Especially since you can only see half of it.)
There are a number of different ways to get "Passwordless Authentication":
/etc/ssh/ssh_host_rsa_key.pub on the source machine to /etc/ssh/ssh_known_hosts2 on the destination machine for protocol 2. "HostbasedAuthentication yes" goes in both ssh_config and sshd_config.
.rhosts or .shosts file with the name of the machines that are to be given seamless access. This is useful along with Host based, because host based doesn't work for root.
.xsession. Mine looks like this: /dev/null; exec fvwm2" | exec ssh-agent sh
1. Hostbased Authentication
Host based Authentication can be done with both protocol 1 and 2. You use ssh-keyscan for protocol 1 from the destination machine, and copy the
2. rhosts/shosts authentication
You can enable rhost and/or shost authentication, which then allows a user to create a
3. ssh-agent
This isn't truly passwordless, but if you have your RSA/DSA keys set up, you can run the ssh-agent either in your xterm or through your
exec echo "ssh-add ~/.ssh/id_dsa<
So when I log into X, I'm prompted one time for my id_dsa key, and then everywhere where I've put my id_dsa.pub file, I get "passwordless" access.
Although RSA/DSA encryption doesn't use a "password", usually isn't it a key generated using a phrase?
so, in the end, it's still using a password of sorts?
when the rain comes, they run and hide their heads. they might as well be dead.
The best way to get passwordless authentication is to use Microsoft BOB.
I have a question for ./ers that is slightly off-topic, so mod away if you have to (I have karma to burn). My question is this: are there any standard free (as in GNU) C or C++ math libraries for handling massive bit-widths like you get in RSA keys? I've been trying to figure it out using google, et. al. but I always get a billion unrelated results. If you care, I am working on some code for this contest, but it seems excessive to have to write sqrt, division, and multiplication functions for huge integers. Thx.
std::disclaimer<std::legalese> sig=new std::disclaimer; sig->dump(); delete sig;
The US modified their export regulations back in 1996 transferring cryptographic export to the US Department of Commerce Bureau of Export Administration (BXA), and not relating it under ITAR (Department of State I believe) which was what classified it as Dual-Use Technologies, which also includes nuclear material, weapons, supercomputers, etc.
Have phun.
Svefg Cbfg!
Follow me
Otherwise we'd have to ask those of you reading the featured article apply some mental floss and forget what you've just read, shred any hard-copies you took to the bathroom with you, and format hard drive just to insure that you haven't accidentally cached it somewhere.
healyourchurchwebsite.com - WWJB?
When we specify a passphrase, it allows ssh-keygen to secure our private key against misuse, but it also creates a minor inconvenience. Now, every time we try to connect to our drobbins@remotebox account using ssh, ssh will prompt us to enter the passphrase so that it can decrypt our private key and use it for RSA authentication. Again, we won't be typing in our password for the drobbins account on remotebox, we'll be typing in the passphrase needed to locally decrypt our private key. Once our private key is decrypted, our ssh client will take care of the rest. While the mechanics of using our remote password and the RSA passphrase are completely different, in practice we're still prompted to type a "secret phrase" into ssh.
I get the feeling from reading this that they want to use RSA/DSA for convenience. It confuses me as to how it is more convenient to enter a passphrase rather than a password. I know that this has definite benefits, but I don't think that they covered them very well in their intro.
I think that there should be more information about the other benefits of using this encryvtion rather than "Wouldn't you rather just type: ssh myname@myhost instead of entering a username and password?"
DocWatson
MessEdUp
#/var/www/v
I thought of something regarding PGP earlier today in response to the file sharing story this morning:
Develop a file-sharing network where data is encrypted using PGP's style of encryption. Remote user generates a temporary symmetric key based on keystrokes, mouse movements, etc, encrypts the file you want using that temp key, then encrypts the temp using your public key, then transmit the pair to you. Decrypt the temp key using your private key, then decrypt the shared file. Use a similar scheme of things when searching for files and other data transmissions. Naturally we want all this to be transparent to the user and happen automatically. Only problem with this is it is processor intensive and may slow things down because of all the math work involved in encrpytion/decryption process.
The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
Keep your private key on a floppy! See.. problem solved.
Uhhh.. they still make floppies right??