Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Encryption Security

OpenSSH Management - Understanding RSA/DSA Authent 95

Posted by Hemos from the from-the-ground-up dept.
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."
This discussion has been archived. No new comments can be posted.

OpenSSH Management - Understanding RSA/DSA Authent More

OpenSSH Management - Understanding RSA/DSA Authent

Comments Filter:

  • Re:Decrypt This (Score:1)

    by Anonymous Coward
    I can't. ROT13 decryption of copyrighted work (your message) is illegal under the DMCA.

  • Re:lucky for you foreigners ... (Score:2)

    by Anonymous Coward
    Lies, lies and lies.

    OpenBSD and OpenSSH are both all-American products. Canada is, after all, a renegade 51st State we just have not bothered to annex yet.

  • You are describing what they call a "Man in the Middle Attack" in cryptography books.

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

    --
  • In the article is the following:

    To do this, we simply type ssh drobbins@remotebox at localbox's console, as we always have. However, this time, ssh lets remotebox's sshd know that it would like to use the RSA authentication protocol. What happens next is rather interesting. Remotebox's sshd generates a random number, and encrypts it using our public key that we copied over earlier. Then, it sends this encrypted random number back to the ssh running on localbox. In turn, our ssh uses our private key to decrypt this random number, and then sends it back to remotebox, saying in effect "See, I really do hold the matching private key; I was able to successfully decrypt your message!" Finally, sshd concludes that we should be allowed to log in, since we hold a matching private key. Thus, the fact that we hold a matching private key grants us access to remotebox.

    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?

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

    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)

    from="mybox.domain.org",command="ls",no-port-forwa rding,no-X11-forwarding,no-agent-forwarding,no-pty the usual stuff here

    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!
  • 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?
  • So you mean that with Debian, you just have to enter one password (your ssh passphrase) and it logs you in based on that alone?

    Or perhaps you just mean that Debian automatically starts ssh-agent for you on login (which other distributions, eg Mandrake, do as well).
  • Another Source:
    http://www.perfsci.com/free/giantint/freesoftwar e. html

    Found it when researching the Pi topic. I'm a Richard Crandal fan since he developed FEE (Fast Elliptic Encryption) while at NeXT.
  • 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.
    --
  • /.
    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.
    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 /. 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?).
    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:

    exec ssh-agent sh -c 'ssh-add < /dev/null & sleep 5 ; exec wmaker'

    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 :) 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.
    --
  • Actually, it can also be used by non-child processes as long as they have permission to search for the socket and pid. There's a script at http://www.ucolick.org/~sla/ssh/fsa [ucolick.org] that does just that (drop the trailing /fsa for more hints). This allows you to launch an agent and provide an identity at boot and make that identity available to cron jobs for scp or other secure remote functions. Very useful.
  • Yes, they left out the wonderful world of ssh-agent, whereby one-time logons permit a memory resident ssh key to decrypt any further ssh challenges. If you have to type in your ssh private key password every time, then what's the real point? It doesn't speed things up or make the more usable. If your private key is not encyrpted with a private key password it can be used by anyone in the world to spoof your identity once compromised. Ssh-agent is a nice compromise; a "hot" terminal where ssh-agent has an activated key can be compromised, and at worst memory can be compromised to root out the decrypted private key (perhaps). But "hot" terminals are far less likely to be compromised. (Note that page files might be an issue here, I guess)

    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
    1st Generation AI: 'cat /dev/random > /dev/kmem'

  • Actually, if you're talking about what I think you're talking about, the phrase is used to generate entropy by using the millisecond (ignoring the significant part of the timing) and more precise parts of the timing between keystrokes, possibly and probably ignoring the actual keystrokes themselves (since if the keystroke is a factor the entropy is limited by the probability of the keystrokes times the timing factor, but the probability of random keystrokes isn't really random ... any key usually means space, for example.)

    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".
  • 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 [openssh.org] for some more info, specifically their history [openssh.org] page.

    "Intelligence is the ability to avoid doing work, yet getting the work done".
  • 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".
  • I think that GMP is what you're looking for.

    It's an arbritrary-length math library, allowing for (more or less) unlimited length numbers. From the webpage:

    GMP is a free library for arbitrary precision arithmetic, operating on signed integers, rational numbers, and floating point numbers. There is no limit to the precision except the ones implied by the available memory in the machine GMP runs on.


    More info is available at http://www.swox.com/gmp/ [swox.com]

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

  • 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?
  • 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.
  • This applies to openssh 2.5.2p2 which is what I'm running. YMMV....

    For Version 1:

    ssh-keygen
    [return]
    [return]
    [return]
    scp .ssh/identity.pub targethost:fooid
    [type password]
    ssh targethost
    [type password]
    mkdir .ssh
    cat fooid >> .ssh/authorized_keys

    Done. Now, if you want version 2 (DSA-based):

    ssh-keygen -t dsa
    [return]
    [return]
    [return]
    scp .ssh/id_dsa.pub targethost:fooid2
    [type password]
    ssh targethost
    [type password]
    mkdir .ssh
    cat fooid2 >> .ssh/authorized_keys2

    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.
  • How do you negotiate the symmetric key without encryption, though? Transfering the key in 'plaintext' would be kind of useless, authorized or not.

    Someone please explain.

  • Bwa Ha Ha Ha Ha! I see a mod war in the making on this one....

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


  • 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
  • Cool idea. I never thought of it. I Googled for pam-ssh and got a hit on this [sourceforge.net] project at SourceForge.
    --
    Steve Jackson

  • 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?

  • the thing i wonder though, is couldn't you still sniff the packet just like you would a password, except rather than "mypassword6" you get "23857723984...653765846358" or something?

    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 encryption itself isn't quite a problem - you can use faster secret key algorithms for the actual transfer (randomly generate secret key and encrypt that using public key)

    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/ [sourceforge.net])might interest you, as it's trying to do distributed sharing with privacy / anonymity.

  • Re:passwordless authentication (Score:3)

    by Bullschmidt ( 69408 ) on Friday July 27, 2001 @10:28AM (#2188533)
    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.
  • 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 [openssl.org].
  • 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 [rsasecurity.com] 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".

  • I wonder if /. editors read the links... (Score:4)

    by pongo000 ( 97357 ) on Friday July 27, 2001 @10:15AM (#2188537)
    It covers what you need to get passwordless authentication implemented using RSA and DSA authentication protocols."
    Well, not exactly...passphraseless authentication is in part 2, which doesn't appear to have been published yet.
  • How about a little wrap up:

    Part I - Using ssh [linuxgazette.com]

    Part II - ssh suite: Sftp, scp and ssh-agent [linuxgazette.com]

    Part III - Using ssh-agent for SSH1 and OpenSSH [linuxgazette.com]

    Abbreviated Version [securityportal.com]

    The authoritative source [openssh.org]

    Mmmnnkay? Mnnnkay.

  • 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 [securityportal.com]
  • You're missing part of the point - it's easy to set up ssh to use DSA or RSA authentication to allow you access without your password (you put your public key that you've made with ssh-keygen - ~/.ssh/identity.pub or ~/.ssh/id_dsa.pub - in ~/.ssh/authorized_keys or authorized_keys2) - and you can also use ssh-agent to keep your ssh key accessible after only putting in your passphrase once.

    Personally I appreciate Debian's approach to this - when you log in, you are doing so indirectly through ssh-agent, which keeps your ssh key available during your session.

    Anyone, feel free to correct me on this stuff.

  • I'm fairly sure that it just starts ssh-agent for you on login, as does Mandrake (a fact which I was not aware of).
  • 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.
  • 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.
  • 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.. ).

  • No, passwordless private keys are in part 2, passwordless authentication is indeed covered. (Yes, you use a password for the private key, but the actual authorization is by RSA/DSA).
  • If you really want that then you can change your passphrase to empty, i.e. just hit 'enter' when asked, with 'ssh-keygen -p -f /path/to/private_key'. You'll not be asked for a passphrase to use your private key. The downside is you've lost a layer of defense to your private key.
  • 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.
  • 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...

    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":

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

    2. rhosts/shosts authentication
    You can enable rhost and/or shost authentication, which then allows a user to create a .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.

    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 .xsession. Mine looks like this:
    exec echo "ssh-add ~/.ssh/id_dsa< /dev/null; exec fvwm2" | exec ssh-agent sh
    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.
    --
  • 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.

    Correct me if I'm wrong... but it doesn't get transmitted as plaintext, the communication between the two machines is encrypted with blowfish or 3des.
    --

  • You get a challenge sent to you, and if you can use your private key to sign the challenge, you are allowed access.

    the thing i wonder though, is couldn't you still sniff the packet just like you would a password, except rather than "mypassword6" you get "23857723984...653765846358" or something?

    then use that to connect initially?

    (except you'd still need to know how to decrypt the bash prompt, etc. but it wouldn't be entirely useless, i suppose, if you could capture certain actions somehow)
  • 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?
  • 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).
  • 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 [slashdot.org] contest, but it seems excessive to have to write sqrt, division, and multiplication functions for huge integers. Thx.
  • RSA encrypts a number, you decrypt it and send it back to the server. The only attack that I can think of here is sending a number. Say the server server sends '39'. Well if you make a ssh client that sends '39' back every time, you're in. I guess using big numbers makes this unfesable?

    DSA sends a number, you sign it and send it back to the server. This is the same as signing a message with GPG. DSA is considered more secure (the algorithm is better), bacause you'd have to guess the entire key rather than just a number.

    Now I have a question: What if some evil user decided to put his key in some user's home directory (maybe they left it writable?) ? Seems like a great way to steal accounts :-(
  • that's the RSA algorithm

  • Re:passwordless authentication (Score:4)

    by hillct ( 230132 ) on Friday July 27, 2001 @10:18AM (#2188563) Homepage Journal
    No. Public Key authentication is exactly that. The authentication is done using a public and private key set.

    The text - or mouse movement - you (probably) entered when the key was generated was intended as a source of unique input, hopefully containing enough entropic characteristics to create a secure non-pattern based key set.

    The then probably had the option to encrypt the key using a passphrase which you'd then have to use when authenticating using that key set.

    The main difference here is that the passphrase is not a required part of a key set, and it is not the main cryptographic mechanism of the authentication process.

    --CTH
  • 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.

    This has always been my (naive? correct me please) concern about this.. could a ssh client be hacked to fake a 'signed challenge' since this is all at the client? Or am I missing something (e.g. returned signed key still has to be authenticated at host).

    Inquiring minds want to know :)

  • Ok, so based on the public key I send, I receive a 'challenge' which I decrypt with my private key and send back to the server to authenticate?

    Just trying to truly understand this.

  • 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.
  • Develop a file-sharing network where data is encrypted using PGP's style of encryption.



    Perfectly possible. You don't even need to worry about how it'd happen -- just use a cryptographic library. There's something along these lines using GPG (IIRC, it's called GPGme.) If properly implemented in C++, you could seamlessly switch between secure and unsecure mode, without having to rewrite any functions! (Of course, once we start stripping off any application-specific aspects, we'd eventually arrive at some sort of Secure Sockets Layer, with public-key emphasis and tight integration with the application.)

  • ood thing the U.S. modified it's policy on exporting encryption technologies (a.k.a. munitions).

    The US modified their export regulations back in 1996 transferring cryptographic export to the US Department of Commerce Bureau of Export Administration (BXA [doc.gov]), and not relating it under ITAR [pmdtc.org] (Department of State I believe) which was what classified it as Dual-Use Technologies, which also includes nuclear material, weapons, supercomputers, etc.

  • Re:Question (Score:3)

    by plcurechax ( 247883 ) on Friday July 27, 2001 @11:00AM (#2188569) Homepage
    article treats RSA and DSA as one entity

    RSA and DSA are two algorithms which are used in a similar (interchanagable for our purposes) fashion.

    The article says that SSH1 used the patented RSA key

    The RSA patent in the US (# 4,405,829) expired in September 2000.

    How is it that SSH2 can use a signature algorithm to do real encryption?

    The actual transport encryption is done via a symmetric cipher algorithm such as Triple-DES (3DES), Blowfish, or IDEA (patented in US, Europe) which are much faster (~ 1000-1500 times) than public key algorithms. The RSA or DSA is used to negotiate the key to be used by the symmetric cipher (which uses the same key to encrypt and decrypt, hence "symmetric").

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

  • There's another good article... (Score:4)

    by Lobsang ( 255003 ) on Friday July 27, 2001 @10:56AM (#2188571) Homepage
    This article [linuxgazette.com] on Linux-Gazette is also very good, focusing on the usage of ssh-agent.

    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!
  • Finally a good informative discussion on real, useful encryption! Death to ROT-13!
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  • lucky for you foreigners ... (Score:4)

    by beanerspace ( 443710 ) on Friday July 27, 2001 @10:16AM (#2188575) Homepage
    Good thing the U.S. modified [epic.org] it's policy on exporting encryption technologies (a.k.a. munitions).

    Otherwise we'd have to ask those of you reading the featured article [ibm.com] 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.

  • 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
  • Any similar documentation for OPENSSL??? Anyone??
  • A clever first post indeed...
  • I was referring to the content of the "encrypted" text not to the time at which the post was made. Me thinks you may be taking this a bit seriously. :-)

    Justin Dubs

  • Re:Cryptography awareness (Score:3)

    by jeffy124 ( 453342 ) on Friday July 27, 2001 @10:29AM (#2188580) Homepage Journal
    SSH and PGP are but small examples of what can be done.

    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.

  • 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. ;)
  • Idea like that, is there a timeout for the listening of the server?

    Just wondering if you intercept the communication from the client, let him ask for the random number to the server, wait for the server to send him the challenge, and then, when the client sends bask the unencrympted random number, you block it, then send it yourself. Would the server still be waiting for it? Is there a client recognition system (ip adress, mac adress...)?

    I guess the only way this would work would be to control a gateway or any transition point.

    Or could the fact of intercepting the encrypted challenge, and the unencrypted one lead to the discovery of the private key....?

    I'm not a pro in this, that's why i ask these questions...
  • Keep your private key on a floppy! See.. problem solved.

    Uhhh.. they still make floppies right??
  • Correct me if I'm wrong... but it doesn't get transmitted as plaintext, the communication between the two machines is encrypted with blowfish or 3des.

    The actual session would be encrypted, yes. After all, that's part of the point. But the initial phase isn't part of the session. That's when they have to do things like set up the shared key the two systems will use for the session, stuff like that.

  • Public key systems like RSA and DSA use a key pair generated randomly. In order to get entropy for the randomness, they often have the user do things like wiggle the mouse about or hit keys. When they use entropy from key typing, it's usually got more to do with the timing of the keystrokes than which keys were actually pressed. Anyway, even if it was like a password, you (as the user) would never need to enter it again, so in that sense it's different from a password. Also, most implementations make you have a password you have to use to get your computer to use your private key. This is actually a password and could be guessed or something similar, but it is never sent over a network, it's just something internal to your computer.

Slashdot Top Deals

Love makes the world go 'round, with a little help from intrinsic angular momentum.

Close