Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #172792 > unrolled thread

Issues with SSH pubkey authentication at remote server

Back to article view | Back to linux.debian.user

Contents

  Issues with SSH pubkey authentication at remote server Stephan Beck <sbeck@secure.mailbox.org> - 2016-09-26 12:30 +0200
    Re: Issues with SSH pubkey authentication at remote server Lisi Reisz <lisi.reisz@gmail.com> - 2016-09-26 13:30 +0200
      Re: Issues with SSH pubkey authentication at remote server Stephan Beck <sbeck@secure.mailbox.org> - 2016-09-26 13:50 +0200
        Re: Issues with SSH pubkey authentication at remote server Lisi Reisz <lisi.reisz@gmail.com> - 2016-09-26 14:10 +0200
          Re: Issues with SSH pubkey authentication at remote server Stephan Beck <sbeck@secure.mailbox.org> - 2016-09-26 17:20 +0200
            Re: Issues with SSH pubkey authentication at remote server Mark Fletcher <mark27q1@gmail.com> - 2016-09-27 01:00 +0200
              Re: Issues with SSH pubkey authentication at remote server Stephan Beck <sbeck@secure.mailbox.org> - 2016-09-27 10:00 +0200
                OpenSSH security update? was Re: Issues with SSH pubkey  authentication at remote server Stephan Beck <sbeck@secure.mailbox.org> - 2016-09-27 11:10 +0200
    Re: Issues with SSH pubkey authentication at remote server Mark Fletcher <mark27q1@gmail.com> - 2016-09-26 13:30 +0200
      Re: Issues with SSH pubkey authentication at remote server Dan Purgert <dan@djph.net> - 2016-09-26 14:10 +0200
        Re: Issues with SSH pubkey authentication at remote server Stephan Beck <sbeck@secure.mailbox.org> - 2016-09-26 17:10 +0200
          Re: Issues with SSH pubkey authentication at remote server Dan Purgert <dan@djph.net> - 2016-09-26 17:40 +0200
            Re: Issues with SSH pubkey authentication at remote server Stephan Beck <sbeck@secure.mailbox.org> - 2016-09-27 10:30 +0200
      Re: Issues with SSH pubkey authentication at remote server Stephan Beck <sbeck@secure.mailbox.org> - 2016-09-26 17:10 +0200
    Re: Issues with SSH pubkey authentication at remote server Lars Noodén <lars.nooden@gmail.com> - 2016-09-26 14:00 +0200
      Re: Issues with SSH pubkey authentication at remote server Stephan Beck <sbeck@secure.mailbox.org> - 2016-09-26 17:10 +0200
        Re: Issues with SSH pubkey authentication at remote server Lars Noodén <lars.nooden@gmail.com> - 2016-09-26 17:20 +0200
          Re: Issues with SSH pubkey authentication at remote server Stephan Beck <sbeck@secure.mailbox.org> - 2016-09-27 00:40 +0200
          Re: Issues with SSH pubkey authentication at remote server Stephan Beck <sbeck@secure.mailbox.org> - 2016-09-27 13:10 +0200
            Re: Issues with SSH pubkey authentication at remote server Lars Noodén <lars.nooden@gmail.com> - 2016-09-27 15:20 +0200
              Re: Issues with SSH pubkey authentication at remote server Stephan Beck <sbeck@secure.mailbox.org> - 2016-09-27 17:10 +0200
                Re: Issues with SSH pubkey authentication at remote server Lars Noodén <lars.nooden@gmail.com> - 2016-09-27 20:40 +0200
                  Re: Issues with SSH pubkey authentication at remote server Stephan Beck <sbeck@secure.mailbox.org> - 2016-09-28 10:50 +0200
                    Re: Issues with SSH pubkey authentication at remote server <tomas@tuxteam.de> - 2016-09-28 11:20 +0200
                      [SOLVED ]Re: Issues with SSH pubkey authentication at remote server Stephan Beck <sbeck@secure.mailbox.org> - 2016-09-28 17:20 +0200

Page 1 of 2  [1] 2  Next page →

#172792 — Issues with SSH pubkey authentication at remote server

Hi,

I have successfully uploaded my SSH public key to the authorized_keys
file in ~/.ssh on the remote server using ssh-copy-id. I connected using
password authentication to check whether it really is the correct key
there and it is. Permissions are ok.

Public key authentication is the first (in order and priority) of
several auth methods that the server offers. But as to the output below
something is not working with the submission of the secret part of the
key (well, the proof of being in possession of it) by the ssh-agent.
Before establishing connection for the first time I did

eval $(ssh-agent)
PID xxxx
ssh-add ~/.ssh/id_rsa

But it seems that the ssh-agent does not really authenticates to the
remote server and as a fallback password auth is selected. (I anonymized
the output below.) So, pubkey authentication is not working :-(

Can anyone tell me what's going wrong, especially this
debug1: Offering RSA public key: ~/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
...
debug2: we did not send a packet, disable method

Any hints welcome.


Stephan

-----------------------------------------------------------------------
me@mymachine:~/.ssh$ ssh -vv me@theremoteserver
OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t  3 May 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to theremoteserver [IPaddress_remoteserver] port 22.
debug1: Connection established.
[debug messages concerning type 1 keys, snipped]
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3
debug1: Remote protocol version 2.0, remote software version
OpenSSH_6.0p1 Debian-4+deb7u6
debug1: match: OpenSSH_6.0p1 Debian-4+deb7u6 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
[debug messages concerning ciphers, snipped]
debug1: Server host key: RSA [server_host_key]
debug1: Host 'theremoteserver' is known and matches the RSA host key.
debug1: Found key in ~/.ssh/known_hosts:4
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: ~/.ssh/id_rsa (0x1cpt789b66z1),
debug2: key: ~/.ssh/id_dsa ((nil)),
debug2: key: ~/.ssh/id_ecdsa ((nil)),
debug2: key: ~/.ssh/id_ed25519 ((nil)),
debug1: Authentications that can continue:
publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering RSA public key: ~/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue:
publickey,password,keyboard-interactive
debug1: Trying private key: ~/.ssh/id_dsa
debug1: Trying private key: ~/.ssh/id_ecdsa
debug1: Trying private key: ~/.ssh/id_ed25519
debug2: we did not send a packet, disable method
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password:
------------------------------------------------------------------------

NOTE: I pray for the OpenSSL version OpenSSH ships with being patched
soon in Jessie!

[toc] | [next] | [standalone]

#172794

On Monday 26 September 2016 11:18:00 Stephan Beck wrote:
[snip]
> NOTE: I pray for the OpenSSL version OpenSSH ships with being patched
> soon in Jessie!

Is this what you are meaning?
https://lists.debian.org/msgid-search/E1bnWuv-000727-Gd@master.debian.org

Lisi

[toc] | [prev] | [next] | [standalone]

#172796

Well, I better rephrase because that was a bit misleading!

I pray for the OpenSSH package being patched
soon in Jessie with respect to its OpenSSL component!


Lisi Reisz:
> On Monday 26 September 2016 11:18:00 Stephan Beck wrote:
> [snip]
>> NOTE: I pray for the OpenSSL version OpenSSH ships with being patched
>> soon in Jessie!
> 
> Is this what you are meaning?
> https://lists.debian.org/msgid-search/E1bnWuv-000727-Gd@master.debian.org

Cheers,

Stephan

[toc] | [prev] | [next] | [standalone]

#172798

On Monday 26 September 2016 12:48:00 Stephan Beck wrote:
> Well, I better rephrase because that was a bit misleading!
>
> I pray for the OpenSSH package being patched
> soon in Jessie with respect to its OpenSSL component!

Could you explain why "****openssl**** regression update" is not at least part 
of the OpenSSL component?  (Though I can see it might be the wrong bit of the 
component, and not what you were meaning.)

Lisi
> Lisi Reisz:
> > On Monday 26 September 2016 11:18:00 Stephan Beck wrote:
> > [snip]
> >
> >> NOTE: I pray for the OpenSSL version OpenSSH ships with being patched
> >> soon in Jessie!
> >
> > Is this what you are meaning?
> > https://lists.debian.org/msgid-search/E1bnWuv-000727-Gd@master.debian.org
>
> Cheers,
>
> Stephan

[toc] | [prev] | [next] | [standalone]

#172812

Hi Lisi,

Lisi Reisz:
> On Monday 26 September 2016 12:48:00 Stephan Beck wrote:
>> Well, I better rephrase because that was a bit misleading!
>>
>> I pray for the OpenSSH package being patched
>> soon in Jessie with respect to its OpenSSL component!
> 
> Could you explain why "****openssl**** regression update" is not at least part 
> of the OpenSSL component?  (Though I can see it might be the wrong bit of the 
> component, and not what you were meaning.)
> 

If you look at the second line of the terminal output I reproduced, you
find that the openssl component in use within the package openssh Debian
Jessie is one step behind. "Standalone" OpenSSL package is now at
version 1.0.1t-1+deb8u5 since September 23.

> me@mymachine:~/.ssh$ ssh -vv me@theremoteserver
> OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t  3 May 2016

Cheers,

Stephan

[toc] | [prev] | [next] | [standalone]

#172826

On Mon, Sep 26, 2016 at 02:52:00PM +0000, Stephan Beck wrote:
> Hi Lisi,

> If you look at the second line of the terminal output I reproduced, you
> find that the openssl component in use within the package openssh Debian
> Jessie is one step behind. "Standalone" OpenSSL package is now at
> version 1.0.1t-1+deb8u5 since September 23.
> 
> > me@mymachine:~/.ssh$ ssh -vv me@theremoteserver
> > OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t  3 May 2016
> 
Yeah there was a Debian security advisory last week with a security 
patch for OpenSSL. I thought the fix was already in place, certainly I 
got an update for OpenSSH when I updated on Sunday.

Does anyone know what upstream version contains the fixes natively? I'm 
wondering if my other non-Jessie (and non-Debian) systems need an update 
too...

Mark

[toc] | [prev] | [next] | [standalone]

#172836

Hi Mark,

Mark Fletcher:
> On Mon, Sep 26, 2016 at 02:52:00PM +0000, Stephan Beck wrote:
>> Hi Lisi,
> 
>> If you look at the second line of the terminal output I reproduced, you
>> find that the openssl component in use within the package openssh Debian
>> Jessie is one step behind. "Standalone" OpenSSL package is now at
>> version 1.0.1t-1+deb8u5 since September 23.
>>
>>> me@mymachine:~/.ssh$ ssh -vv me@theremoteserver
>>> OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t  3 May 2016
>>
> Yeah there was a Debian security advisory last week with a security 
> patch for OpenSSL. I thought the fix was already in place, certainly I 
> got an update for OpenSSH when I updated on Sunday.

I didn't receive any update of the OpenSSH package in the past days.
Such update would usually be communicated issuing a DSA urging people to
upgrade, wouldn't it? And I'm subscribed to the DSA.
Just checked and as latest I upgraded the libarchive package.

Cheers
Stephan

[toc] | [prev] | [next] | [standalone]

#172842 — OpenSSH security update? was Re: Issues with SSH pubkey authentication at remote server

Hi,

[UPDATE]
Stephan Beck:
> Hi Mark,
> 
> Mark Fletcher:
>> On Mon, Sep 26, 2016 at 02:52:00PM +0000, Stephan Beck wrote:
>>> Hi Lisi,
>>
>>> If you look at the second line of the terminal output I reproduced, you
>>> find that the openssl component in use within the package openssh Debian
>>> Jessie is one step behind. "Standalone" OpenSSL package is now at
>>> version 1.0.1t-1+deb8u5 since September 23.
>>>
>>>> me@mymachine:~/.ssh$ ssh -vv me@theremoteserver
>>>> OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t  3 May 2016
>>>
>> Yeah there was a Debian security advisory last week with a security 
>> patch for OpenSSL. I thought the fix was already in place, certainly I 
>> got an update for OpenSSH when I updated on Sunday.
> 
> I didn't receive any update of the OpenSSH package in the past days.
> Such update would usually be communicated issuing a DSA urging people to
> upgrade, wouldn't it? And I'm subscribed to the DSA.
> Just checked and as latest I upgraded the libarchive package.

not even activating deb-src (security) and deb-src (ftp.xx.debian.org)
Sources
apt-get update
apt-get upgrade

results in any OpenSSH package being updated.

In packages.debian.org I see a sources patch that can be manually
downloaded and applied. But nothing you "get", as you say.

So, am I right? It is not included in the .deb sources that are
accessible (provided there is the entry in apt-sources.list) using the
above apt commands.

Cheers

Stephan

[toc] | [prev] | [next] | [standalone]

#172795

[Multipart message — attachments visible in raw view] — view raw

On Mon, 26 Sep 2016 at 19:22, Stephan Beck <sbeck@secure.mailbox.org> wrote:

> Hi,
>
> I have successfully uploaded my SSH public key to the authorized_keys
> file in ~/.ssh on the remote server using ssh-copy-id. I connected using
> password authentication to check whether it really is the correct key
> there and it is. Permissions are ok.
>
> Public key authentication is the first (in order and priority) of
> several auth methods that the server offers. But as to the output below
> something is not working with the submission of the secret part of the
> key (well, the proof of being in possession of it) by the ssh-agent.
> Before establishing connection for the first time I did
>
> eval $(ssh-agent)
> PID xxxx
> ssh-add ~/.ssh/id_rsa
>
> But it seems that the ssh-agent does not really authenticates to the
> remote server and as a fallback password auth is selected. (I anonymized
> the output below.) So, pubkey authentication is not working :-(
>
> Can anyone tell me what's going wrong, especially this
> debug1: Offering RSA public key: ~/.ssh/id_rsa
> debug2: we sent a publickey packet, wait for reply
> ...
> debug2: we did not send a packet, disable method
>
> Any hints welcome.
>
>
> Stephan
>
> -----------------------------------------------------------------------
> me@mymachine:~/.ssh$ ssh -vv me@theremoteserver
> OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t  3 May 2016
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: /etc/ssh/ssh_config line 19: Applying options for *
> debug2: ssh_connect: needpriv 0
> debug1: Connecting to theremoteserver [IPaddress_remoteserver] port 22.
> debug1: Connection established.
> [debug messages concerning type 1 keys, snipped]
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3
> debug1: Remote protocol version 2.0, remote software version
> OpenSSH_6.0p1 Debian-4+deb7u6
> debug1: match: OpenSSH_6.0p1 Debian-4+deb7u6 pat OpenSSH* compat 0x04000000
> debug2: fd 3 setting O_NONBLOCK
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> [debug messages concerning ciphers, snipped]
> debug1: Server host key: RSA [server_host_key]
> debug1: Host 'theremoteserver' is known and matches the RSA host key.
> debug1: Found key in ~/.ssh/known_hosts:4
> debug2: kex_derive_keys
> debug2: set_newkeys: mode 1
> debug1: SSH2_MSG_NEWKEYS sent
> debug1: expecting SSH2_MSG_NEWKEYS
> debug2: set_newkeys: mode 0
> debug1: SSH2_MSG_NEWKEYS received
> debug1: SSH2_MSG_SERVICE_REQUEST sent
> debug2: service_accept: ssh-userauth
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug2: key: ~/.ssh/id_rsa (0x1cpt789b66z1),
> debug2: key: ~/.ssh/id_dsa ((nil)),
> debug2: key: ~/.ssh/id_ecdsa ((nil)),
> debug2: key: ~/.ssh/id_ed25519 ((nil)),
> debug1: Authentications that can continue:
> publickey,password,keyboard-interactive
> debug1: Next authentication method: publickey
> debug1: Offering RSA public key: ~/.ssh/id_rsa
> debug2: we sent a publickey packet, wait for reply
> debug1: Authentications that can continue:
> publickey,password,keyboard-interactive
> debug1: Trying private key: ~/.ssh/id_dsa
> debug1: Trying private key: ~/.ssh/id_ecdsa
> debug1: Trying private key: ~/.ssh/id_ed25519
> debug2: we did not send a packet, disable method
> debug1: Next authentication method: keyboard-interactive
> debug2: userauth_kbdint
> debug2: we sent a keyboard-interactive packet, wait for reply
> debug2: input_userauth_info_req
> debug2: input_userauth_info_req: num_prompts 1
> Password:
> ------------------------------------------------------------------------
>
> NOTE: I pray for the OpenSSL version OpenSSH ships with being patched
> soon in Jessie!
>
> If I'm reading the above right, it looks like the server is offering an
rsa key to authenticate itself, but won't accept rsa to authenticate the
client. Which is a bit cheeky.

You may need a key created with a stronger method, such as ecdsa or
ed25519.

Mark

[toc] | [prev] | [next] | [standalone]

#172799

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Fletcher wrote:
> If I'm reading the above right, it looks like the server is offering an
> rsa key to authenticate itself, but won't accept rsa to authenticate the
> client. Which is a bit cheeky.
>
> You may need a key created with a stronger method, such as ecdsa or
> ed25519.

Could even be as simple as he sent a /different/ key across (e.g. he
sent "home-key.pub", which corresponds to "home-key_rsa" rather than
"id_rsa").

- -- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJX6QzrAAoJEI4R3fMSeaKBxQIH/0OucqyF7cIbktL7yHTBdLxX
GL5QBqfQQJZWV+Edwn4bl4zQTTCUjaRQ9xSdLfEI7oBxlYcs1q8e1FrUiIpyEqb0
GUB8cBSl/XMcxyqsbK+RYWCo6a7Ep2IIKGlFc/l3VtHc+bhomLXkFCBqUwtTTTFB
E/LLaXGFlCMISlAp51hF4b2ZM9k6A82dLpZCtBbBkmhCM9d+b9x0MKoA3ErEuO1u
dEY61MRlb+edF+FnkA5nCI94wscYU6QHl6KQCCMyMGEmMclctbmTFAhVJOU5+Jz3
TRvlvob23l5x8AXX5rzpeZZR51ZA4XtmKXcYLRyLq/25CRm+ZxqvsvMdVobvD9g=
=3gWi
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#172810

Hi,

Dan Purgert:
> Mark Fletcher wrote:
>> If I'm reading the above right, it looks like the server is offering an
>> rsa key to authenticate itself, but won't accept rsa to authenticate the
>> client. Which is a bit cheeky.
> 
>> You may need a key created with a stronger method, such as ecdsa or
>> ed25519.
> 
> Could even be as simple as he sent a /different/ key across (e.g. he
> sent "home-key.pub", which corresponds to "home-key_rsa" rather than
> "id_rsa").
> 
No. I wrote that I /checked/ the public key copied to the server after
having copied it to the server's ~/.ssh directory. I edited it with a
text editor and compared it with the one I have in local ~/.ssh

Cheers,

Stephan

[toc] | [prev] | [next] | [standalone]

#172813

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Stephan Beck wrote:
> Dan Purgert:
>> Mark Fletcher wrote:
>>> If I'm reading the above right, it looks like the server is offering an
>>> rsa key to authenticate itself, but won't accept rsa to authenticate the
>>> client. Which is a bit cheeky.
>> 
>>> You may need a key created with a stronger method, such as ecdsa or
>>> ed25519.
>> 
>> Could even be as simple as he sent a /different/ key across (e.g. he
>> sent "home-key.pub", which corresponds to "home-key_rsa" rather than
>> "id_rsa").
>> 
> No. I wrote that I /checked/ the public key copied to the server after
> having copied it to the server's ~/.ssh directory. I edited it with a
> text editor and compared it with the one I have in local ~/.ssh
>

I think you misunderstood what I was saying.  I was supposing that you
copied a valid (yet "incorrect") key to the remote server, or tried to
authenticate with the wrong private key.

For example, I have in my user's .ssh/ directory:

id_rsa -> symlink to home_lan_rsa
VPS_id_rsa -> private key for uploading to a VPS
home_lan_rsa -> private key for use on my LAN.

Assuming that I copied the right public key to the VPS, if I run the
command "ssh me@vps", it'll fail, because ssh by default tries to
authenticate with "id_rsa". _FIX:_ change the ssh command to "ssh -i
.ssh/VPS_id_rsa me@vps"

Assuming that I copied the wrong public key to one of my "home" devices,
the command "ssh me@lan_host" would fail because "id_rsa" isn't the
proper private key for the VPS_id. _FIX:_ correct .ssh/authorized_keys
on the remote host.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJX6T3PAAoJEI4R3fMSeaKBDqQIAIkzsa0AGnbUre0ZD41rdxAX
Q7EmSG1IyTPwmU9OwNH7ol8ZlzUgEhroZQZCzYQYDNj1ojcjyzO1i85AfM5oHHME
bsCcjD/IEz1z4v/Os/6sx8jdJ46Oi/VBetdCY1sMjH1uICE2bWqR+R0D3rii9zUc
pF/R6H2obJYl+8fxha0yBcghgscaZNOLSq2mgON+Y1xkYJ7lHdqGajsN0BdRq/GG
XptMECk2k1M27BODAi1bov8YxQGYxNsVjsLCUxUPr5g5XuZYhWGWSteV5aO2Cz9H
v02g1Kg9LWslk0kX75BbKh8bBywGJ8c2MHnyodLDsIVWLseCekoChtmOj7XUFFI=
=m+bN
-----END PGP SIGNATURE-----

-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

[toc] | [prev] | [next] | [standalone]

#172839

Hi Dan,

Dan Purgert:
> Stephan Beck wrote:
>> Dan Purgert:
>>> Mark Fletcher wrote:
>>>> If I'm reading the above right, it looks like the server is offering an
>>>> rsa key to authenticate itself, but won't accept rsa to authenticate the
>>>> client. Which is a bit cheeky.
>>>
>>>> You may need a key created with a stronger method, such as ecdsa or
>>>> ed25519.
>>>
>>> Could even be as simple as he sent a /different/ key across (e.g. he
>>> sent "home-key.pub", which corresponds to "home-key_rsa" rather than
>>> "id_rsa").
>>>
>> No. I wrote that I /checked/ the public key copied to the server after
>> having copied it to the server's ~/.ssh directory. I edited it with a
>> text editor and compared it with the one I have in local ~/.ssh
> 
> 
> I think you misunderstood what I was saying.  I was supposing that you
> copied a valid (yet "incorrect") key to the remote server, or tried to
> authenticate with the wrong private key.

It was the correct and valid public key. It seems that the agent
actually is authenticating with the wrong private key. But, fair to say,
that's something you didn't mention in your first message.
> 
> For example, I have in my user's .ssh/ directory:
> 
> id_rsa -> symlink to home_lan_rsa
> VPS_id_rsa -> private key for uploading to a VPS
> home_lan_rsa -> private key for use on my LAN.
> 
> Assuming that I copied the right public key to the VPS, if I run the
> command "ssh me@vps", it'll fail, because ssh by default tries to
> authenticate with "id_rsa". _FIX:_ change the ssh command to "ssh -i
> .ssh/VPS_id_rsa me@vps"

Well, I only have one single pubkey on this local user "ssh" account I'm
talking about.

Cheers
Stephan

[toc] | [prev] | [next] | [standalone]

#172806

Hi Mark,

Mark Fletcher:
> On Mon, 26 Sep 2016 at 19:22, Stephan Beck <sbeck@secure.mailbox.org> wrote:
> 

>> If I'm reading the above right, it looks like the server is offering an
> rsa key to authenticate itself, but won't accept rsa to authenticate the
> client. Which is a bit cheeky.
> 
> You may need a key created with a stronger method, such as ecdsa or
> ed25519.

Thanks. You may be more experienced than me interpreting the ssh
communication.
Which are the signs/symbols that tell one that this line corresponds to
what the server says whereas that other line is the client's turn. Are
there any or is it just experience/contextual heuristics?

Thanks for the key cipher's advice. Maybe I should use that elliptic
curve one, as it is the latest on the scene and is stronger.

Cheers,

Stephan

[toc] | [prev] | [next] | [standalone]

#172797

On 09/26/2016 01:18 PM, Stephan Beck wrote:
> ...
> Before establishing connection for the first time I did
> 
> eval $(ssh-agent)
> PID xxxx
> ssh-add ~/.ssh/id_rsa
> 
> But it seems that the ssh-agent does not really authenticates to the
> remote server and as a fallback password auth is selected. (I anonymized
> the output below.) So, pubkey authentication is not working :-(

Are you running the SSH client in the same shell as you have run eval?
Also, the desktop environment is often set up so that it is launched
under an agent already.  So how many agents do you have running?

	pgrep -lf ssh-agent

Regards,
Lars

[toc] | [prev] | [next] | [standalone]

#172808

Hi Lars,

Lars Noodén:
> On 09/26/2016 01:18 PM, Stephan Beck wrote:
>> ...
>> Before establishing connection for the first time I did
>>
>> eval $(ssh-agent)
>> PID xxxx
>> ssh-add ~/.ssh/id_rsa
>>
>> But it seems that the ssh-agent does not really authenticates to the
>> remote server and as a fallback password auth is selected. (I anonymized
>> the output below.) So, pubkey authentication is not working :-(
> 
> Are you running the SSH client in the same shell as you have run eval?
> Also, the desktop environment is often set up so that it is launched
> under an agent already.  So how many agents do you have running?
> 
> 	pgrep -lf ssh-agent

I made sure that only one ssh-agent was running (under this user
account) by using top package and killing one more that ran with the
same account's user rights. So, I guess you were right, that it might
not be necessary to fire it up with eval $(ssh-agent).
Thanks for the command, makes it more easy.

Cheers,

Stephan

[toc] | [prev] | [next] | [standalone]

#172811

On 09/26/2016 05:46 PM, Stephan Beck wrote:
> ... it might
> not be necessary to fire it up with eval $(ssh-agent).
> Thanks for the command, makes it more easy.

No problem.  If you want to see which keys are available to ssh, you can
use ssh-add for that:

	ssh-add -L

It has to be run in the same shell as you would then run ssh.

That will list the public key matching the private key which has
actually been loaded into the available agent.  But that availability
might be the issue here, as with the earlier message, I am still
wondering if ssh is finding the "right" agent.

Regards,
Lars

[toc] | [prev] | [next] | [standalone]

#172825

Hi Lars,

Lars Noodén:
[...]
> 	ssh-add -L
> 
> It has to be run in the same shell as you would then run ssh.
> 
> That will list the public key matching the private key which has
> actually been loaded into the available agent.  But that availability
> might be the issue here, as with the earlier message, I am still
> wondering if ssh is finding the "right" agent.

OK. I've successfully established ssh connection via pubkey auth, which
did not work because I thought I had to ssh-copy-id it in ~/.ssh whereas
it has to be placed in /.ssh. BUT
----------------------------------------------------------------------
debug1: Offering [key_cipher_type] public key: ~/.ssh/[key_cipher_type]
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg [key_cipher_type] [...]
debug2: input_userauth_pk_ok: fp
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
debug1: key_load_private_type: incorrect passphrase supplied to decrypt
private key
Enter passphrase for key '~/.ssh/[key_cipher_type]':
debug1: Authentication succeeded (publickey).
----------------------------------------------------------------------
I had to type the correct passphrase. Something is going wrong, your
doubts are confirmed. I still have to check the fingerprint. There are
three agents running after logging into my "local ssh account" and
executing
pgrep -lf ssh-agent
Two running under another user account and the one running under my
"local ssh account" (i.e. from where I establish ssh connection to the
remote server)
*BUT*
me@localsshaccount:~$ ssh-add -L
Could not open a connection to your authentication agent


Well, it's late and I will further investigate it tomorrow, but any
comments on how to make sure that ssh-agent selects the correct
passphrase/private key (automatically) appreciated.

Cheers
Stephan

[toc] | [prev] | [next] | [standalone]

#172846

Hi Lars,

Lars Noodén:
> On 09/26/2016 05:46 PM, Stephan Beck wrote:
>> ... it might
>> not be necessary to fire it up with eval $(ssh-agent).
>> Thanks for the command, makes it more easy.
> 
> No problem.  If you want to see which keys are available to ssh, you can
> use ssh-add for that:
> 
> 	ssh-add -L
> 
> It has to be run in the same shell as you would then run ssh.
> 
> That will list the public key matching the private key which has
> actually been loaded into the available agent.  But that availability
> might be the issue here, as with the earlier message, I am still
> wondering if ssh is finding the "right" agent.

I've tried again and detected the following:
No agent is started when I login to the "local ssh user account".
I have to do
eval $(ssh-agent) --> for every single session
ssh-add /path/to/key
ssh-add -L
(outputs the key)
Then I connect to the remote server and it works without having to type
a passphrase. Gee!

The fact that there are two ssh-agents under my other user account,
one with the -s option, the other exits with LX session, is still under
investigation :-)

Thanks
Stephan

[toc] | [prev] | [next] | [standalone]

#172850

On 09/27/2016 02:02 PM, Stephan Beck wrote:
> Hi Lars,
> 
> Lars Noodén:
>> On 09/26/2016 05:46 PM, Stephan Beck wrote:
>>> ... it might
>>> not be necessary to fire it up with eval $(ssh-agent).
>>> Thanks for the command, makes it more easy.
>>
>> No problem.  If you want to see which keys are available to ssh, you can
>> use ssh-add for that:
>>
>> 	ssh-add -L
>>
>> It has to be run in the same shell as you would then run ssh.
>>
>> That will list the public key matching the private key which has
>> actually been loaded into the available agent.  But that availability
>> might be the issue here, as with the earlier message, I am still
>> wondering if ssh is finding the "right" agent.
> 
> I've tried again and detected the following:
> No agent is started when I login to the "local ssh user account".

It is the one that should be running under your local account that is of
relevance, or at least should be.  How are you logging in to your "local
ssh user account" there?

Your processes including the terminal need to be inheriting the
environment variables SSH_AGENT_PID and SSH_AUTH_SOCK.  If they are not
in the environment, then your processes need to be pointed to socket and
process id explicitly.

> I have to do
> eval $(ssh-agent) --> for every single session
> ssh-add /path/to/key
> ssh-add -L
> (outputs the key)
> Then I connect to the remote server and it works without having to type
> a passphrase. Gee!

Ok.  So the keys work and it is possible to add on an agent after
logging in.  Can you tell more about how your login session is started?

Regards,
Lars

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web