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."
I can't. ROT13 decryption of copyrighted work (your message) is illegal under the DMCA.
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/ .
Simple: use an empty passphrase.
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.
Why use Putty when you have Cygwin?
Cygwin has all the SSH utilities, as well as the daemon. And if someone can't figure out how to invoke them from Cygwin, a shell script link could easily be put on their desktop.
That being said, we also use Cygwin to tie together the windows and nix machines.
-- perl -e'print pack"H*","6e656d6f406d38792e6f7267"'
> RSA and DSA are two algorithms which are used in a similar fashion.
You're missing his point. RSA can be used for encryption (and therefore key exchange), but DSA is signature only and can't (on its own).
Looking at an ssl man page, the answer is in version 2 of the protocol they are both used for signature only because the actual session key is derived using Diffie-Hellman.
--
rant
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).
Not using a null passphrase is exactly what the article at IBM warns you about!
-- Ed Avis ed@membled.com
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
Another Source:r e. html
http://www.perfsci.com/free/giantint/freesoftwa
Found it when researching the Pi topic. I'm a Richard Crandal fan since he developed FEE (Fast Elliptic Encryption) while at NeXT.
Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.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.
The upside is that it probably wouldn't take much encryption in order to fool any filters that would be looking for specific file types, ie. MP3, so encryption wouldn't have to be all that processor intensive. The funny side would be if someone (RIAA/MPAA) decrypts the stream and accuses you of copyright violation, you can site them for violation of the DMCA for breaking your encryption.
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
--
Something else omitted was the wonderful world of Putty, a MIT-licensed (~BSD) Windows set of SSH utilities, including scp and sftp. Without these tools (and cygwin/XFree86), management of our very heterogenous environment would be untenable!
Brian /dev/random > /dev/kmem'
1st Generation AI: 'cat
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!
It's an arbritrary-length math library, allowing for (more or less) unlimited length numbers. From the webpage:
More info is available at http://www.swox.com/gmp/
RTFA! Apparently on each connect the server picks a number. It encrypts this number using your public key and sends it to your box. Your private key decrypts it (after entering your passphrase locally if you set it up to do so) and sends the number back to the server. If the correct number is sent back, then it assumes that you had the real private key.
I'm sure that getting that number wouldn't do you any good because surely it's not going to challenge you with the same number each time.
Your private key is never sent to the server.
load "linux",8,1
Exactly. Like, just how much more secure is this then just sending a password? Your password is encrypted, right?
Using their logic where the main reason to do this is so you don't have to enter a password is just crazy.
If you don't use passphrase protection on your private key, it's just as risky as creating a shell script that sends your password automatically or entering into a program like SecureCRT and having it remember it.
In fact, since SecureCRT encrypts the saved password, this seems like it's more secure than having a non-passphrase protected private key hanging around.
After you set this up, can you still log in via remotely using your password?
load "linux",8,1
look at the protocol 2 information in the ssh man pages, I think there it describes the DSA authentication you'll also find at the bottom of the article linked to in the headline blurb.
mefus
In Open Society, GPL Software frees YOU!
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
Someone please explain.
bla
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.
1. Hostbased Authentication
2. rhosts/shosts authentication
3. ssh-agent
4. Kerberos
If you're looking for passphraseless-entry for interactive use, this is the right answer, IMHO. You kinit to get a TGT. Then you can ssh into any host in the kerberos realm "for free". And using ssh ticket-forwarding you can even chain the ssh sessions from host to host. That allows you to do something cool like:
ssh -t foo.bar.com ssh -t guinness.bar.com ssh -t iron.bar.com xemacs -nw
without having to type a passphrase. Or say that your desktop is sand, and you've ssh'd into law, and then you decide you want to ssh into upc. You don't have to pop a new Eterm on sand to ssh to upc. You can just ssh from law to upc without a passphrase. This doesn't require home directory sharing across the machines (which you might not want on a server, say). And it doesn't require the maintenance of host keys, because it's still user authentication.
Of course, it does require the mantenance of a kerberos realm, but that's the right thing to do anyway. (krb5 patches for openssh are available)
it's the best way...bar none,
Michael
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?
Well, that's the point of SSH, you can't sniff a password.
You can spend a lot of time studying secure interaction, but in a nutshell, here's how it works with (I'm not intimantely familiar with SSH, so I'm making some assumptions):
You have your account on localhost and remotehost (To use the same terminology as the article).
REMOTEHOST generates a public key, which is widely published. You get a copy of this key on localhost (SSH does this automagically, but not technically securely the first time you connect).
When you SSH from localhost, it asks for remotehosts public key. SSH compares it to the cached, verified (hopefully this has been done in some degree) key.
Information is then encrypted before being sent over the link. (Most protocols use public key methods for negotiation, and then a faster algorithm such as RC4 for data transfer).
Your password is never sent in the clear, and therefore can't be sniffed. The only way to obtain it is to compromise one of the hosts.
The difficult part is more how you do distributed file sharing well. The Napster model still provides a central point to DoS / Sue, and gnapster doesn't scale... The freenet project ( http://freenet.sourceforge.net/ )might interest you, as it's trying to do distributed sharing with privacy / anonymity.
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".
How about a little wrap up:
Part I - Using ssh
Part II - ssh suite: Sftp, scp and ssh-agent
Part III - Using ssh-agent for SSH1 and OpenSSH
Abbreviated Version
The authoritative source
Mmmnnkay? Mnnnkay.
~Religion is O.K., as long as it gets you laid.
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.
Has anyone been able to use ange-ftp with sftp or some other openssh ftp program? I tried setting ange-ftp-ftp-program-name to sftp but sftp does not recognize the -i option.
Test 1 2 3 4
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.
The author seems to think that an ``advantage'' of using ssh-agent (unencrypted private keys in memory) vs. unencrypted private keys on disk is that somehow stuff in memory is harder to get to.
For starters, you'd better turn off /proc:
anybody with a fractional brain
who gets root can surely dig the password out
of there. Oh, and turn off /dev/mem. Oh, and make
sure that nobody can install a trojan ssh-agent...
Look, the only real advantage of the ssh-agent approach (or for that matter, typing a passphrase every time your key is used) that I'm aware of is not that it helps against being broken into. It does help when your machine is confiscated. Because it is difficult (though not in principle impossible) to tell what was in RAM once it is powered down, if you pull the plug when the bad guys come bursting in (and if you are running without swap space, so that your bits don't end up on disk anyhow :-) your
accounts on other machines should be safe from
exploration (up to rubber hoses).
This scenario doesn't apply to you? You're not willing to run without swap? Then for pity's sake, just use an unencrypted private key on disk.
To put it another way: what SSH acknowledges is the reality that if someone breaks into your system, they have to be really dumb not to be able to get into all the systems you can get into. ssh-agent is a tool for special-case situations.
I guess the only benefit is convenience. You would only need to remember one passphrase for multiple machines, each (potentially) having different public/private key pairs. Or secure rsh style access. Conveeeenient.
--
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.
One possibility other than the ones already mentioned is to use libcrypto.a from the OpenSSL library (www.openssl.org). There is a part of that called 'bn' that is used for arbitrarily large integers (like in RSA keys).
Sweet! Thanks.
std::disclaimer<std::legalese> sig=new std::disclaimer; sig->dump(); delete sig;
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;
Cryptography is a great field. It enables never-thought-before stuff in the fields of privacy, authentication, data integrity and non-repudiation. SSH and PGP are but small examples of what can be done.
That's why we need to develop cryptographic awareness in the general public. If everyone was informed about the benefits of cryptography, there'd be pressure against export restrictions and the like. Even more important is the question of key management -- it might be worth implementing many of the marvelous ideas enabled by cryptography, if only people managed to understand how important a private key is, and started seriously protecting them.
Join the NFSNET. Our prime goal is making little numbers out of big ones. http://www.nfsnet.org/
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.
Almost. Not only does someone need to get the passphrase protecting the key, he/she needs to get the key itself. The passphrase is useless without the actual key. If you wanted to be paranoid, you could keep your private key on an unmounted medium, and mount it only when you wanted to use it. Not to say that this couldn't be done, but it makes things more interesting for the attacker.
Have phun.
This is a good article that describes the "passwordless" mechanics of SSH1 very well but what about SSH2? It's my understanding that SSH2 is quite different than SSH1..... has anyone run across a similar article describing SSH2?
Svefg Cbfg!
Follow me
Finally a good informative discussion on real, useful encryption! Death to ROT-13!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ now you know
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
Any similar documentation for OPENSSL??? Anyone??
IBM said, "lame"! Huh huh.
;)
Anyway, when using the ssh-agent for no-password-required logons, you can STILL have a security issue if someone compromises your account (or your machine!). They may not know what your private key is, but they can use it just like you do. Just to be safe, pick and use a good password.
Keep your private key on a floppy! See.. problem solved.
Uhhh.. they still make floppies right??