ssh - password control or key control?

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

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 a viable option.

Re: ssh - password control or key control?

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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

Re: ssh - password control or key control?

Quoted text here. Click to load it

That sounds like the perfect time to reboot into something like Grml
( 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.
(*) Linux Counter #80292
- - Please, don't Cc: me.

Re: ssh - password control or key control?

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

Quoted text here. Click to load it

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

Re: ssh - password control or key control?

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

=46rom 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

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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

S/Key.  =)


Re: ssh - password control or key control?

Quoted text here. Click to load it

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 Foiling Replay Attacks public key vs passwd authentication public key vs passwd authentication public key vs passwd authentication

Re: ssh - password control or key control?

Quoted text here. Click to load it

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


Re: ssh - password control or key control?

Quoted text here. Click to load it

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

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 ssh - password control or key control?

and the other posts: Foiling Replay Attacks public key vs passwd authentication public key vs passwd authentication 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

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

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

as mentioned in some of the original referenced posts on s/key attacks,
my rfc index:

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)

Re: ssh - password control or key control?

Quoted text here. Click to load it

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.


Re: ssh - password control or key control?

C. J. Clegg wrote:
Quoted text here. Click to load it

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

Site Timeline