openssh unix dev - Oct 2000 - having some trouble using another user's RSA/DSA keys

Debian GNU/Linux 2.2 (potato), openssh-2.2.0p1
Configured with: --prefix=/usr/local/openssh --enable-gnome-askpass
--with-tcp-wrappers --with-ipv4-default --with-ipaddr-display

My goal here is to, as root, forward a local privileged port over an
ssh tunnel to another host using a normal user's login, i.e.:

root:# ssh -2 -l jamesb -i ~jamesb/.ssh/id_dsa -L 26:localhost:25 remotehost

So far, I am finding it impossible or impractical to do this.  Am I doing
something wrong?  Here's a description of my experiences:

1) First I tried it as shown above, specifying the unprivileged user's
key on the command line with the -i switch.  But for some reason I was
still prompted for the password.  So, then I try it with the -v option
and observe this:

# ssh -v -2 -l jamesb -i ~jamesb/.ssh/id_dsa <remotehost>
::snip::
debug: key does not exist: /root/.ssh/id_dsa

Note that it is _still_ trying to use root's id_dsa key (root does not
actually have one) despite my -i argument on the command line.


2) Next I tried specifying jamesb's dsa key in ~root/.ssh/config:

IdentityFile2	~jamesb/.ssh/id_dsa

Then I got the following output:

debug: try pubkey: /home/jamesb/.ssh/id_dsa
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Bad ownership or mode(0600) for '/home/jamesb/.ssh/id_dsa'.
It is recommended that your private key files are NOT accessible by
others.
Enter passphrase for DSA key '/home/jamesb/.ssh/id_dsa': 

I believe those warnings about invalid permissions on the key file to
be in err, considering I can read everything as root anyway.  Also, I
was forced to supply the passphrase for the key.  The passphrase in this
case is blank, and after hitting Enter, I was told that this is invalid
and then was prompted for the login password (which succeeded).


3) The last thing I have tried is to make a copy of jamesb's dsa key and
put it in ~root/.ssh/id_dsa.  This works, but it is not reasonable to have
to do this for my needs.


I should also note that on a friend's machine, using the Debian package
of OpenSSH version/build 1.2.3-9, I do not have this problem.  I can
connect to that same remote host as root, using another user's key login,
without all this hassle.

Thanks for any help!

jamesb-lists at alongtheway.com said:
> root:# ssh -2 -l jamesb -i ~jamesb/.ssh/id_dsa -L 26:localhost:25
> remotehost 
Port forwarding is not implemented in the mainstream release for ssh2 
protocol.


jamesb-lists at alongtheway.com said:
> I should also note that on a friend's machine, using the Debian
> package of OpenSSH version/build 1.2.3-9, I do not have this problem.
> I can connect to that same remote host as root, using another user's
> key login, without all this hassle. 
Thats ssh protocol 1 - use that for now and it will all work.  There 
seems to be some work needed on both key handling and functionality for 
ssh2

	Nigel.
-- 
[ - Opinions expressed are personal and may not be shared by VData - ]
[ Nigel Metheringham                  Nigel.Metheringham at VData.co.uk ]
[ Phone: +44 1423 850000                         Fax +44 1423 858866 ]

Do you use the from="hostname" clause in your keys?
I have seen this error between different versions of ssh where the public
key had the from clause.




-----Original Message-----
From: Jim Breton [mailto:jamesb-lists at alongtheway.com]
Sent: Wednesday, October 25, 2000 8:22 AM
To: openssh-unix-dev at mindrot.org
Subject: Re: having some trouble using another user's RSA/DSA keys


Hi Nigel, thanks for responding.

On Wed, Oct 25, 2000 at 09:45:36AM +0100, Nigel Metheringham
wrote:
> Port forwarding is not implemented in the mainstream release for ssh2 
> protocol.
OK, thanks.
> Thats ssh protocol 1 - use that for now and it will all work.  There 
> seems to be some work needed on both key handling and functionality for 
> ssh2
OK.  However, using ssh1 with OpenSSH-2.2.0p1, I have two remaining
issues:

1) I am still warned about bad permissions on the key file even though I
am root (I guess this would be a "wishlist" item since I can suppress
these warnings with the -q option);

2) I am unable to log in using that key.  The passphrase is blank, but
key authentication fails and I am forced to enter a login password.

# ssh -v -l jamesb -i ~jamesb/.ssh/identity <remotehost>

SSH Version OpenSSH_2.2.0p1, protocol versions 1.5/2.0.
Compiled with SSL (0x0090581f).
debug: Reading configuration data /root/.ssh/config
debug: Reading configuration data /usr/local/openssh/etc/ssh_config
debug: Applying options for *
debug: Seeding random number generator
debug: ssh_connect: getuid 0 geteuid 0 anon 1
debug: Connecting to <remotehost> port 22.
debug: Connection established.
debug: Remote protocol version 1.99, remote software version 2.0.13
(non-commercial)
datafellows: 2.0.13 (non-commercial)
debug: Local version string SSH-1.5-OpenSSH_2.2.0p1
debug: Waiting for server public key.
debug: Received server public key (768 bits) and host key (1024 bits).
debug: Host '<remotehost>' is known and matches the RSA host key.
debug: Seeding random number generator
debug: Encryption type: 3des
debug: Sent encrypted session key.
debug: Installing crc compensation attack detector.
debug: Received encrypted confirmation.
debug: Trying RSA authentication with key 'jamesb at tarkin'
debug: Received RSA challenge from server.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Bad ownership or mode(0600) for '/home/jamesb/.ssh/identity'.
It is recommended that your private key files are NOT accessible by
others.
Enter passphrase for RSA key 'jamesb at tarkin': 
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Bad ownership or mode(0600) for '/home/jamesb/.ssh/identity'.
It is recommended that your private key files are NOT accessible by
others.
Bad passphrase.
debug: Remote: Wrong response to RSA authentication challenge.
debug: Doing password authentication.
jamesb@<remotehost>'s password:

Thank you.

On 2000-10-25, Jim Breton <jamesb-lists at alongtheway.com> wrote:
> 1) I am still warned about bad permissions on the key file even though
> I am root (I guess this would be a "wishlist" item since I can
suppress
> these warnings with the -q option);
Right.  The warning is not because you're unable to access the file, but
because OpenSSH thinks it is a bad thing to ever use a private key which is
readable or (worse) writable by any user other than the one running ssh. 
This is a feature ;)  And while you may have a legitimate case where this
feature isn't desired, it's generally the Right Thing To Do--the key is
essentially compromised, and root (or any user, in the generic case) should
not trust it.  The workaround would be to put this key in
~root/.ssh/jamesbiden or such, root.root mode 600.
> 2) I am unable to log in using that key.  The passphrase is blank, but
> key authentication fails and I am forced to enter a login password.
Right, because:
> # ssh -v -l jamesb -i ~jamesb/.ssh/identity <remotehost>
[snip]
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> Bad ownership or mode(0600) for '/home/jamesb/.ssh/identity'.
> It is recommended that your private key files are NOT accessible by
> others.
> Enter passphrase for RSA key 'jamesb at tarkin':
> debug: Remote: Wrong response to RSA authentication challenge.
> debug: Doing password authentication.
> jamesb@<remotehost>'s password:
[ Even though you've said this key has no passphrase. ]

I assume things are happy if you su - jamesb on the local host and then ssh
remotehost?  In that case I suspect this is a mildly buggy way of
expressing "Hey, I'm not willing to even try to use this key, since
it's
essentially been compromised."  Similar to how RSA authentication won't
be
tried if the remote host's key has changed.  Probably, the workaround above
will make this problem disappear.

--
Hank Leininger <hlein at progressive-comp.com>