ssh - password control or key control? - Security

This is a discussion on ssh - password control or key control? - Security ; I've been studying up on how to secure ssh. It seems there are two general ways... each user has his/her login account with password, or each user's computer has a key file that's matched up with key files stored on ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: ssh - password control or key control?

  1. ssh - password control or key control?


    I've been studying up on how to secure ssh.

    It seems there are two general ways... each user has his/her login account
    with password, or each user's computer has a key file that's matched up
    with key files stored on the host.

    In the latter case, no login or password is necessary, apparently ... the
    computer connects, the host and the computer exchange keys, and if
    everything matches up, the user is presented with a shell prompt (or other
    access e.g. svn+ssh, etc.).

    My question is, if you practice proper password discipline (big "if", I
    know...), what do you gain by establishing key files rather than just
    depending on the username/password exchange?

    Using key files would restrict access to specific client computers, not
    just specific users, and that's the only advantage I can see. We are not
    sure at this point whether that will work. There will be times when
    employees have to visit customer sites and access our server via the
    customer's computers (for one thing, not many of our customers would allow
    "foreign" laptops to connect to their networks).

    So, even if we used key files for access, we'd have to allow ssh to fall
    back to userid/password if the key files don't match.

    Yes, I'm aware of the existence of keystroke loggers and other spyware
    that can run in the background and collect all sorts of information on
    what a user is doing, and we would have no way of knowing if any of that
    stuff is running on our customers' computers.

    I guess we can require employees to change their passwords whenever they
    return from a customer's site using the customer's computers. Fortunately
    we are small enough that that's {barely} a viable option.



  2. Re: ssh - password control or key control?

    In comp.os.linux.security C. J. Clegg :

    > I've been studying up on how to secure ssh.


    > It seems there are two general ways... each user has his/her login account
    > with password, or each user's computer has a key file that's matched up
    > with key files stored on the host.


    > In the latter case, no login or password is necessary, apparently ... the


    You still have a passphrase on your key and want to use ssh-agent
    to keep it in memory.

    > computer connects, the host and the computer exchange keys, and if
    > everything matches up, the user is presented with a shell prompt (or other
    > access e.g. svn+ssh, etc.).


    > My question is, if you practice proper password discipline (big "if", I
    > know...), what do you gain by establishing key files rather than just
    > depending on the username/password exchange?


    Try to login through a bunch of systems to get to the one you
    really want, afterwards we check the time difference between 2-n
    times entering your password and the time it took with ssh agent
    forwarding requested to login to all of them with one command.

    It can be a very big time saver if you happen to work with a
    couple of systems.

    [..]

    > Yes, I'm aware of the existence of keystroke loggers and other spyware
    > that can run in the background and collect all sorts of information on
    > what a user is doing, and we would have no way of knowing if any of that
    > stuff is running on our customers' computers.


    > I guess we can require employees to change their passwords whenever they
    > return from a customer's site using the customer's computers. Fortunately
    > we are small enough that that's {barely} a viable option.


    Sounds like a pita and is prone to be abused quite fast. If you
    are serious about login from remote systems over the internet you
    might not even control, you want to look into TACAS/ACE/SecurID.

    Even if there is a key logger, the token changes once a minute.

    Good luck

    --
    Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
    mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
    #bofh excuse 50: Change in Earth's rotational speed

  3. Re: ssh - password control or key control?

    C. J. Clegg :
    >
    >
    > Using key files would restrict access to specific client computers, not
    > just specific users, and that's the only advantage I can see. We are not
    > sure at this point whether that will work. There will be times when
    > employees have to visit customer sites and access our server via the
    > customer's computers (for one thing, not many of our customers would allow
    > "foreign" laptops to connect to their networks).


    That sounds like the perfect time to reboot into something like Grml
    (grml.org) installed on a USB key, with your rsa/dsa keys on a
    floppy. Any key loggers on their network will just see encrypted
    packets flying about.


    --
    Any technology distinguishable from magic is insufficiently advanced.
    (*) http://www.spots.ab.ca/~keeling Linux Counter #80292
    - - http://www.faqs.org/rfcs/rfc1855.html Please, don't Cc: me.
    Spammers! http://www.spots.ab.ca/~keeling/emails.html

  4. Re: ssh - password control or key control?

    On Thu, 02 Nov 2006 16:08:42 +0000, s. keeling wrote:

    > That sounds like the perfect time to reboot into something like Grml
    > (grml.org) installed on a USB key, with your rsa/dsa keys on a
    > floppy. Any key loggers on their network will just see encrypted
    > packets flying about.


    Excellent idea. Thank you. I'll look into that.


  5. Re: ssh - password control or key control?

    "C. J. Clegg" (06-11-01 09:44:43):

    > It seems there are two general ways... each user has his/her login
    > account with password, or each user's computer has a key file that's
    > matched up with key files stored on the host.
    >
    > In the latter case, no login or password is necessary, apparently
    > ... the computer connects, the host and the computer exchange keys,
    > and if everything matches up, the user is presented with a shell
    > prompt (or other access e.g. svn+ssh, etc.).


    You have a wrong concept of a key. Don't think of files, rather think
    of keys like in your pocket. In general, you would copy the (encrypted)
    key file onto a USB stick or a floppy disk and take it with you. You
    will still require to enter a passphrase then, but read on.


    > My question is, if you practice proper password discipline (big "if",
    > I know...), what do you gain by establishing key files rather than
    > just depending on the username/password exchange?


    The advantage lies in the cryptographic technique used to establish such
    a cryptosystem. Normal password-based systems are still attackable.
    Using the MITM (Man In The Middle) attack, you can fully compromise a
    password-based system. Using keys makes this attack impossible.

    From an administrative perspective it's also much easier to use, because
    you would create one 'general key' for all things you need SSH access
    to, not necessarily only your server. You can safely access even
    hostile systems with your key. The advantage is obvious: one key for
    everything.

    Last but not least, using authentication for both sides, you can be
    assured that you're talking to the server you were expecting to talk to,
    so it's good not to just take your id_rsa with you, but also the
    known_hosts file.


    > Using key files would restrict access to specific client computers,
    > not just specific users, and that's the only advantage I can see. We
    > are not sure at this point whether that will work. There will be
    > times when employees have to visit customer sites and access our
    > server via the customer's computers (for one thing, not many of our
    > customers would allow "foreign" laptops to connect to their networks).


    That's not true, and it wouldn't be anything of an advantage. As said
    above, just take your key with you, because ...


    > So, even if we used key files for access, we'd have to allow ssh to
    > fall back to userid/password if the key files don't match.


    .... password authentication would totally destroy the security of the
    key-based system. You also shouldn't connect from hosts you don't
    trust, as this is always a security hazard. Somebody willing to hurt
    you just needs to become your customer in that case.

    One very good solution to that problem is using an S/Key system, which
    enables you to use one-time-passwords. Generate a list of passwords,
    print it out and take it with you.


    > Yes, I'm aware of the existence of keystroke loggers and other spyware
    > that can run in the background and collect all sorts of information on
    > what a user is doing, and we would have no way of knowing if any of
    > that stuff is running on our customers' computers.


    With S/Key you wouldn't care, although one possible attack is that the
    user hijacks your connection in the background. Probably the most
    secure method is still not to login from an untrusted host.


    > I guess we can require employees to change their passwords whenever
    > they return from a customer's site using the customer's computers.
    > Fortunately we are small enough that that's {barely} a viable option.


    S/Key. =)


    Regards,
    E.S.

  6. Re: ssh - password control or key control?

    C. J. Clegg wrote:
    >
    >
    > I've been studying up on how to secure ssh.
    >
    > It seems there are two general ways... each user has his/her login account
    > with password, or each user's computer has a key file that's matched up
    > with key files stored on the host.
    >
    > In the latter case, no login or password is necessary, apparently ... the
    > computer connects, the host and the computer exchange keys, and if
    > everything matches up, the user is presented with a shell prompt (or other
    > access e.g. svn+ssh, etc.).
    >
    > My question is, if you practice proper password discipline (big "if", I
    > know...), what do you gain by establishing key files rather than just
    > depending on the username/password exchange?
    >
    > Using key files would restrict access to specific client computers, not
    > just specific users, and that's the only advantage I can see. We are not
    > sure at this point whether that will work. There will be times when
    > employees have to visit customer sites and access our server via the
    > customer's computers (for one thing, not many of our customers would allow
    > "foreign" laptops to connect to their networks).
    >
    > So, even if we used key files for access, we'd have to allow ssh to fall
    > back to userid/password if the key files don't match.
    >
    > Yes, I'm aware of the existence of keystroke loggers and other spyware
    > that can run in the background and collect all sorts of information on
    > what a user is doing, and we would have no way of knowing if any of that
    > stuff is running on our customers' computers.
    >
    > I guess we can require employees to change their passwords whenever they
    > return from a customer's site using the customer's computers. Fortunately
    > we are small enough that that's {barely} a viable option.
    >
    >


    I have a simple solution that I use. Since I am mostly at a Windows
    machine if I don't have my own, I keep a copy of Putty with my key on a
    credit card size CDROM in my wallet.

    --
    "Now are you talking about what it is you know
    or just repeating what it was you heard."
    Grace Slick
    To E-mail use: rpiotro(at)wi(dot)rr(dot)com

  7. Re: ssh - password control or key control?

    Ertugrul Soeylemez writes:
    > With S/Key you wouldn't care, although one possible attack is that the
    > user hijacks your connection in the background. Probably the most
    > secure method is still not to login from an untrusted host.


    but one of the prime scenario justifications for s/key is where you
    aren't carrying anything with you and still supposedly resilient to
    replay attacks and man-in-the-middle attacks. however, one mitm-attack
    is to inject a number that is much lower than current number of rounds
    on file. countermeasure is to validate the server you are talking to
    before starting s/key (but again that invalidates one of the major
    scenario justifications for using s/key).

    standard shared-secret/password requires every use of a unique
    password for every unique/different security domain. another scenario
    for s/key is that a common pass phrase could be used for all security
    domains ... if different servers used different salts. however any
    single server that you deal with could evesdrop and impersonate other
    servers, acquire salts used by other servers and then use a much lower
    number of rounds in a s/key impersonation (but that invalidates the
    assumption that different security domains are secure from each other
    using s/key ... but still being able to use the same passphrase).
    countermeasure is that the client retain a lot more state information
    about previous s/key operations and who they are dealing with. again
    that invalidates scenario justifications for using s/key.

    by the time you have finished with all the countermeasures ... you
    have pretty much invalidated the scenario justifications for s/key (as
    opposed to other solutions).

    past posts discussion s/key, s/key attacks, and countermeasures
    http://www.garlic.com/~lynn/2004b.html#45 Foiling Replay Attacks
    http://www.garlic.com/~lynn/2003m.html#50 public key vs passwd authentication
    http://www.garlic.com/~lynn/2003m.html#51 public key vs passwd authentication
    http://www.garlic.com/~lynn/2003m.html#52 public key vs passwd authentication

  8. Re: ssh - password control or key control?

    Anne & Lynn Wheeler (06-11-02 13:56:55):

    > > With S/Key you wouldn't care, although one possible attack is that
    > > the user hijacks your connection in the background. Probably the
    > > most secure method is still not to login from an untrusted host.

    >
    > by the time you have finished with all the countermeasures ... you
    > have pretty much invalidated the scenario justifications for s/key (as
    > opposed to other solutions).


    Well, this proves that English text has only 1.3 bits per byte of
    valuable information for large numbers of characters. The main
    scenario, where S/Key is useful, is not invalidated:

    You use public key authentication for both sides of the channel, and add
    an additional client authentication step utilizing S/Key. It's enough
    for the server to authenticate itself using its key, but the client must
    authenticate with both its public key and an S/Key hash.

    The whole sense is that you can login safely from an untrusted host,
    such that it can possibly get access to your private key (since you need
    a clear-text version of it to authenticate), but they still wouldn't be
    able to authenticate fully, because they don't know the next (actually
    previous) S/Key hash.

    Since, like with TAN, those hashes are not saved anywhere, but written
    or printed on a paper sheet, the only possible attack is rubberhose
    cryptanalysis.


    Regards,
    E.S.

  9. Re: ssh - password control or key control?

    Ertugrul Soeylemez writes:
    > The whole sense is that you can login safely from an untrusted host,
    > such that it can possibly get access to your private key (since you need
    > a clear-text version of it to authenticate), but they still wouldn't be
    > able to authenticate fully, because they don't know the next (actually
    > previous) S/Key hash.


    registering shared-secret/password with a host (easily vulnerable to
    replay attacks) ... and as countermeasure to hosts in different
    security domains impersonating you to hosts in other security domains
    .... every password has to be unique.

    so instead the host gives you a salt and some registration iteration
    count ... say 1000. you take you pass phrase and the host specific
    salt ... and you repeatedly hash it the number of iteration. that
    gets registered (in lieu of shared-secret).

    next time you are at some random place ... you contact the
    host ... the send back their salt and one less than the current
    on-file iteration count ... you repeat the process used for
    registration ... except one less this time. the host gets the
    iterated hash value and hash it one more time and compare it
    to the registered value. if it matches ... it is you, they
    store the latest value you calculated and decrement the iteration
    count.

    this is countermeasure to replay attack ... since the same value is
    never used twice ... and an evesdropping can't predict the next value
    .... since hashes don't work (easily) in reverse.

    now s/key is supposed to be resistant to both man-in-the-middle attacks
    as well as replay attacks.

    however, i'm playing man-in-the-middle, i intercept the host's
    transmission of the salt aned the interation count and replace
    the count with ONE (instead of 999). you iterate only once,
    and transmit the single iteration. i intercept the response and
    repeat the iteration the original number of times and send it
    on. i now leave you alone.

    later i impersonate you ... the host is going to transmit the salt and
    some iteration count ... typically some value much larger than one. I
    don't have your original pass phrase ... but I can still impersonate
    you. All i need is the repeated hash iteration value for some
    iteration much less than what the host is currently using. effectively
    i have an intermediate hash value interaction ... and all I have to do
    it resume the hash iteration at the iteration count I intercepted to
    generate the iterated hash value specified by the host.

    the original claim for s/key justification was that it was resistant
    to both passive evesdropping (and replay attacks) as well as
    (non-passive) man-in-the-middle attacks. however, a (non-passive)
    man-in-the-middle attack can substituted a lower iteration count
    .... as decribed in the previous post
    http://www.garlic.com/~lynn/2006u.html#3 ssh - password control or key control?

    and the other posts:
    http://www.garlic.com/~lynn/2004b.html#45 Foiling Replay Attacks
    http://www.garlic.com/~lynn/2003m.html#50 public key vs passwd authentication
    http://www.garlic.com/~lynn/2003m.html#51 public key vs passwd authentication
    http://www.garlic.com/~lynn/2003m.html#52 public key vs passwd authentication

    so the countermeasure is to carry around a lot more than memory of
    single passphrase ... some sort of hardware dongle that keeps track of
    various state ... like the last iteration count that I saw ... and the
    next iteration count I'm expecting.

    however, that invalidates the original justification assumptions
    for s/key. futhermore, if i'm going to be carrying around a hardware
    dongle ... why can't it include more than simple memory ... but actually
    some processing ... like being able to do a digital signature w/o
    exposing the private key.

    then you could do ssh digital signature authentication ... w/o
    needing digital certificates. misc. past post mentioning certificateless
    operation.
    http://www.garlic.com/~lynn/subpubkey.html#certless

    you could also have radius authentication environment upgraded to do
    digital signature authentication. you register a public key (in place
    of an iterated hash) ... and then do digital signature verification
    (instead of iterated hash verification). again w/o needing digital
    certificates. misc. past posts mentioning radius
    http://www.garlic.com/~lynn/subpubkey.html#radius

    you could also do certificateless kerberos digital signature
    authentication. the original kerberos pk-init draft for digital
    signature started out being certificateless ... just recording
    puhlic key (in lieu of password) and doing public key authentication
    very much like ssh does its operation. it was only later that
    certificate mode of operation was added to the kerberos pk-init
    draft. misc. past posts mentioning kerberos and/or pk-init
    http://www.garlic.com/~lynn/subpubkey.html#kerberos

    as mentioned in some of the original referenced posts on s/key attacks,
    my rfc index:
    http://www.garlic.com/~lynn/rfcietff.htm

    and select "Term (term->RFC#)" in the "RFCs listed by" section. then
    select "OTP" in the "Acronym Fastpath" section. this brings up

    one-time password (OTP)
    see also password
    4226 2444 2289 2243 1938 1760

    selecting any one of the RFC numbers, brings up that RFC's summary
    in the lower frame. exp:

    2289 S
    A One-Time Password System, Haller N., Metz C., Nesser P., Straw M.,
    1998/02/26 (25pp) (.txt=56495) (STD-61) (Obsoletes 1938) (Refs 1320,
    1321, 1704, 1760, 1825, 1826, 1827) (Ref'ed By 2444, 2808, 3552,
    3631, 3748, 3888) (ONE-PASS)

    clicking on the ".txt=nnn" field in the RFC summary retrieves that
    actual RFC.

    See 1.0 Abstract, 2.0 Overview, and 3.0 Introduction in the above RFC
    for a more detailed description of the operation. However, the
    overview does say that it protects against external passive attacks and
    eavesdropper (i.e. replay attacks) ... but does not protect against
    "active attacks" (i.e. the man-in-the-middle attack I described)

  10. Re: ssh - password control or key control?

    Anne & Lynn Wheeler (06-11-02 18:11:43):

    > > The whole sense is that you can login safely from an untrusted host,
    > > such that it can possibly get access to your private key (since you
    > > need a clear-text version of it to authenticate), but they still
    > > wouldn't be able to authenticate fully, because they don't know the
    > > next (actually previous) S/Key hash.

    >
    > [...]


    Yet another big post that essentially repeats what has already been
    said.

    I didn't understand your MITM approach against plain S/Key yet, because
    currently I don't have the time to read through it carefully, but I'll
    give it a shot later.

    But anyway, you again misunderstood my concept. You generate the keys
    locally and take them with you, such that no such computation is done
    anywhere outside your own host. Like with transaction numbers (TANs)
    for internet banking, you just print those keys on a piece of paper.
    That should be secure.


    Regards,
    E.S.

+ Reply to Thread