ssh1 password-less RSA login - how secure is that? better ways?

ssh1 password-less RSA login - how secure is that? better ways?

Post by Vincent Zweij » Thu, 04 Nov 1999 04:00:00





||  I am getting our external web server to synchronize with a different
||  external backup web server using rsync over ssh 1.2.27 (Sun Solaris
||  2.6 to an identical 2.6 box).  In researching my options it seems that
||  everyone posts "oh just use RSA only and no password."
||
||  This seems less than ideal to me because it seems to be based on the
||  assumption that the server where the public key is stored (the main
||  web server in our case) is secure.  That is, if it is compromised,
||  wouldn't anyone be able to use that key to connect to the server?
||  Doesn't it make it too easy for someone to just use the key, at least
||  a password requires more effort - or is this faulty reasoning?

It's faulty reasoning.

[Launching into generic public key (RSA) encryption scheme explanation]

In a two key system, you have a private key and a public key.  You can
encrypt information with one key, and you will only be able to decrypt
it with the other.  You cannot derive one key from the other, even when
given some plain and encrypted text with it.

You hand out the public key to whoever you want to hand it out to.
It's public.  You keep the private key to yourself and tell no one
about it.  It's private.

Someone else can allow access to you based on your public key.
They encrypt some random information with it.  You must decrypt the
encrypted information.  Only the owner of the private key can do this,
which is you.  When you have done this, you have proved your identity,
and you're allowed access.

Basically, in this scheme, posession of a public key only means that
you can challenge someone to prove that he knows the corresponding
private key.  Posession of someone else's public key does not allow you
access to where they have access.  You need their private key for that.

The private key should be kept secure.  For good security, you protect
it with a passphrase, to prevent it from being readable when stolen by
a cracker.

Unfortunately, in automatic/batch usage, you cannot ask a user
to enter the passphrase, so you must do without the passphrase
[complicated/debatable setup with ssh-agent left alone].  This means
that you must store it on a well secured computer to prevent it from
being stolen, and limit its use to prevent damage when it *is* stolen.

The fun thing is, you can store the private key *away* from either
webserver A or B, on a third computer C.  When you want to synchronise the
web sites, initiate this from C.  Have it connect to A, using the public
key on A.  Then have A connect to B, using the public key on B.  Sshd on
A can forward the authentication challenge by B back to C.  This way,
you keep the private key secure on C at all times, and don't run the
risk of having it captured when either webserver A or B is cracked.

Ciao.                                                             Vincent.
--

<http://www.xs4all.nl/~zweije/>      | don't read, does anybody get burnt?"
[Xhost should be taken out and shot] |            -- Paul Tomblin on a.s.r.

 
 
 

ssh1 password-less RSA login - how secure is that? better ways?

Post by Jeffrey Altm » Fri, 05 Nov 1999 04:00:00


: Hello,
:
: I am getting our external web server to synchronize with a different
: external backup web server using rsync over ssh 1.2.27 (Sun Solaris
: 2.6 to an identical 2.6 box).  In researching my options it seems that
: everyone posts "oh just use RSA only and no password."  
:
: This seems less than ideal to me because it seems to be based on the
: assumption that the server where the public key is stored (the main
: web server in our case) is secure.  That is, if it is compromised,
: wouldn't anyone be able to use that key to connect to the server?
: Doesn't it make it too easy for someone to just use the key, at least
: a password requires more effort - or is this faulty reasoning?

In my opinion, that is 100% correct.  

    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
                 The Kermit Project * Columbia University
              612 West 115th St #716 * New York, NY * 10025


 
 
 

ssh1 password-less RSA login - how secure is that? better ways?

Post by Vincent Zweij » Sat, 06 Nov 1999 04:00:00





||  >The fun thing is, you can store the private key *away* from either
||  >webserver A or B, on a third computer C.  When you want to synchronise the
||  >web sites, initiate this from C.  Have it connect to A, using the public
||  >key on A.  Then have A connect to B, using the public key on B.  Sshd on
||  >A can forward the authentication challenge by B back to C.  This way,
||  >you keep the private key secure on C at all times, and don't run the
||  >risk of having it captured when either webserver A or B is cracked.
||
||  Very cool idea - thanks Vincent.  Would I use "ssh port forwarding" to
||  get A and B talking with C as the intermediary or whould I connect via
||  ssh to A from C, *copy* up the private key, then initiate a new ssh
||  connection from A to B, and delete the key when done.  Or use some
||  kind of pipe where the key never gets written to disk, but the idea
||  remains the same: ssh twice once from C then from A or is some kind of
||  seemless circuit of C A B posible?  I ask because for things like X
||  windows I know you can do portforwarding and it takes care of the
||  authentication, but this is a case of running the rsync remote copy
||  program so I am unclear on how I would implement that.  Still your
||  idea is only just sinking in so I will have to give it some thought.

Alright, I'll go on a little.

First of all, C is not an intermediary, it's an initiator.  A is
connecting directly to B.  If there's any intermediary in the picture,
it's A forwarding authentication requests.

Ssh has an authentication forwarding option.  When A wants to connect to
B, B sends a challenge to A.  A forwards *the challenge* to C.  C uses the
private key to decrypt the challenge, and sends the solution back to A.
A forwards the solution back to B, and B is satisfied.  The private key
*never* leaves C.

Authentication forwarding is a bit like port forwarding, but it's a
separate feature.  There's also separate support for X forwarding,
though you could manage that using ordinary port forwarding.

Now, this system is no guaranteed protection when A is compromised,
but it's much better.  If A is compromised, the attacker could use the
authentication forwarding system to get challenges resolved just like
any other forwarded challenge.  Of course, this is only possible when
C happens to connect to A and enables this forwarding.  Moreover, the
private key on C is still not compromised.

Ciao.                                                             Vincent.
--

<http://www.xs4all.nl/~zweije/>      | don't read, does anybody get burnt?"
[Xhost should be taken out and shot] |            -- Paul Tomblin on a.s.r.

 
 
 

ssh1 password-less RSA login - how secure is that? better ways?

Post by Dmitry Sazon » Wed, 10 Nov 1999 04:00:00



: Ssh has an authentication forwarding option.  When A wants to connect to
: B, B sends a challenge to A.  A forwards *the challenge* to C.  C uses the
: private key to decrypt the challenge, and sends the solution back to A.
: A forwards the solution back to B, and B is satisfied.  The private key
: *never* leaves C.

: Authentication forwarding is a bit like port forwarding, but it's a
: separate feature.  There's also separate support for X forwarding,
: though you could manage that using ordinary port forwarding.

: Now, this system is no guaranteed protection when A is compromised,
: but it's much better.  If A is compromised, the attacker could use the
: authentication forwarding system to get challenges resolved just like
: any other forwarded challenge.  Of course, this is only possible when
: C happens to connect to A and enables this forwarding.  Moreover, the
: private key on C is still not compromised.

if A can steal the session key that C is supposed to get and then hijack the session with B,
then B is compromised.

is that how it works?

: Ciao.                                                             Vincent.
: --

: <http://www.xs4all.nl/~zweije/>      | don't read, does anybody get burnt?"
: [Xhost should be taken out and shot] |            -- Paul Tomblin on a.s.r.

 
 
 

1. Password-less logins with SSH 1.2.27?

I think you need to compile with RSA. Unfortunately, there is a patent on this
in the US. Fortunately, the patent expires next year.

I would *NEVER* suggest that someone ignore the patent issues, compile and
install the software, and send RSA an anonymous check since they refuse (by
ignoring requests and questions) to deal with small licenses for small sites.

You *HAVE* generated a local identity key, used SSH to log into the remote
site to establish the key in "~/.ssh/known_hosts", and put an entry in
~/.shosts for

        localhostname   username

Right?

--

                        Nico Kadel-Garcia

2. serial port access with read() delays

3. AIX 3.2 routing problem...

4. Long shadow passwords less secure than normal ones?

5. Terminal on serial line accepts input, no output

6. any way of making login have less or more bad password attempts?

7. Samba + DHCP

8. How to better secure password?

9. Suggest ways to install Linux on 486 CDROM-less system

10. Q: SRP - Secure Remote Passwords w/ native FBSD login/telnet/ftp...?

11. secure/ssh1/telnet

12. Search Beta Test :secure login without Password