SSH login with other user's keys
rahul
password. It's a headless account. I have ssh public and private keys
for the account. The public keys are already there on the machine I
want to log on to.
But the problem is the remote machine is not accepting my private keys
as they were generated on a different machine.
Say keys were generated on saturn and public keys copied to venus. My
mars machine has the private keys but venus won't accept it as it has
public keys generated on saturn. Is there any way I can login on venus
with the keys
I have got? mdmbuild does not have a password. The only way to login
is with the keys.
rahul
debug1: Trying RSA authentication with key
'/home/mdmbuild/.ssh/vault-identity'
debug1: Remote: Your host 'hostname.com' is not
permitted to use this key for login.
debug1: Server refused our key.
Per Hedeland
<399796c1-7ee7-4705...@a9g2000prl.googlegroups.com> rahul
This is not due to where the keys were generated (the user@host at the
end of the key line is just a comment), but due to having specified
restricted usage with a from="..." option at the beginning of the line
in the authorized_keys file. If you have the privilege to do so, you can
just change that option as needed.
Aside, should the server really report this detail to the client? Seems
like a security leak akin to revealing whether a potential attacker has
the wrong password or is a tryning a non-existent username in
traditional user/passwd authentication (any sane system just says "login
failed" or equivalent of course). I just tried this against an
OpenSSH_4.3p2 server, with the same result as above.
--Per Hedeland
p...@hedeland.org
rahul
> In article
> <399796c1-7ee7-4705-ae9a-2fe7578fd...@a9g2000prl.googlegroups.com> rahul
Hey Per,
The server should not report the details but I forgot to mention that
I used ssh -v hostname to figure out the reason:-).....
Thanks for your suggestion but I only have ssh access on the server
and hence can not modify authorized_keys as of now.
Further, I don't see any from= fields in my local authorized_keys and
the headless account I am talking about is
a generic shared account. So I can't edit the from= field to my
hostname as it would block the privilege for other users.
Is deleting the from line from authroized_keys going to help?
rahul
Just to make myself clear, I am talking about deleting the from= field
from the server's authorizes_keys file. Does it take multiple values?
If the from= field is not there
does that mean that any host with the proper keys can login
irrespective of the host on which the keys were generated?
rahul
I found the information about from= field in sshd documentation.
Per Hedeland
<d29ab99a-3bb7-466e...@q24g2000prf.googlegroups.com>
rahul <rahul...@gmail.com> writes:
>On May 17, 3:24 pm, p...@hedeland.org (Per Hedeland) wrote:
>> In article
>> <399796c1-7ee7-4705-ae9a-2fe7578fd...@a9g2000prl.googlegroups.com> rahul
>>
>> <rahulsin...@gmail.com> writes:
>> >Below is the excerpt I am getting.
>>
>> >debug1: Trying RSA authentication with key
>> >'/home/mdmbuild/.ssh/vault-identity'
>> >debug1: Remote: Your host 'hostname.com' is not
>> >permitted to use this key for login.
>> >debug1: Server refused our key.
>> Aside, should the server really report this detail to the client? Seems
>> like a security leak akin to revealing whether a potential attacker has
>> the wrong password or is a tryning a non-existent username in
>> traditional user/passwd authentication (any sane system just says "login
>> failed" or equivalent of course). I just tried this against an
>> OpenSSH_4.3p2 server, with the same result as above.
>The server should not report the details but I forgot to mention that
>I used ssh -v hostname to figure out the reason:-).....
That was obvious, and doesn't change the fact that the server is
reporting it to the client. Though the question wasn't really directed
at you, but rather at the OpenSSH developers that occasionally visit the
group, and/or the user community. I consider it a security deficiency if
not a hole.
>Is deleting the from line from authroized_keys going to help?
It seems you found the info you needed in the documentation - always a
good idea to look there...:-)
--Per Hedeland
p...@hedeland.org