[SOLVED ]Re: Issues with SSH pubkey authentication at remote server

[Stephan Beck]

Hi,

to...@tuxteam.de:
> On Wed, Sep 28, 2016 at 08:36:00AM +, Stephan Beck wrote:
>> Hi Lars,
> 
>> Lars Noodén:
>>> On 09/27/2016 06:07 PM, Stephan Beck wrote:
 Lars Noodén:
> On 09/27/2016 02:02 PM, Stephan Beck wrote:
> Can you tell more about how your login session is started?

 I connect to the "local ssh account" by ssh from my other user account.
>>>
>> [...]
[...]
> Yes. It depends. If you're typically using X as your environment
> (perhaps via some desktop thing: in your case it seems to be LXDE),
> then the first go to is your desktop thing's session management.
> 
> This way all consoles you start will inherit the "coordinates" of
> the agent (in the form of the shell variables SSH_AGEN_PID,
> SSH_AUTH_SOCK and perhaps others I forget). With no desktop environ
> (plain X), X session management (see /etc/X11/XSession.d for
> Debian; there is a 90x11-common_ssh-agent for that). Otherwise
> you have to cook up something in your ~/.profile which looks
> whether there's an agent around and set it up when no. In a nutshell
> 
> 
>   - using a DE: your DE's session management
>   - X without DE: X session management
>   - naked console: .login, .profile (or .bash_profile, .bash_login)

Thanks, Tomás. I'll think about what might be the best solution for me.
Configuring LXDE-Startup applications is maybe the best (and easiest)
solution, whereas adapting ~/.profile I'd be forced to train my console
skills, although that would mean that it only affects this specific user
account.

Cheers,

Stephan


I put SOLVED in the subject line, because the "real" issue, the pubkey
authentication at the remote server is working fine now.

Re: Issues with SSH pubkey authentication at remote server

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Sep 28, 2016 at 08:36:00AM +, Stephan Beck wrote:
> Hi Lars,
> 
> Lars Noodén:
> > On 09/27/2016 06:07 PM, Stephan Beck wrote:
> >> Lars Noodén:
> >>> On 09/27/2016 02:02 PM, Stephan Beck wrote:
> >>> Can you tell more about how your login session is started?
> >>
> >> I connect to the "local ssh account" by ssh from my other user account.
> > 
> [...]
> > You need a way for your "local ssh account" to start and use an agent.
> > I'm not sure of the optimal way for you.  Perhaps something in .bashrc?
> > Others here know more about the shells than I.
> 
> Or in .profile. But I am not really sure about the exact syntax to use
> (this if/then "thing"). I still have to get familiar with that.
> 
> I just checked in LX Session Configuration that the ssh-agent is
> configured as -->Core applications but disabled in --> Autostart. So
> there is another program/process/script that has to be launching the
> ssh-agent, because I find it twice in the process list when I login to
> my "normal" user account. I'm shivering :-)

Yes. It depends. If you're typically using X as your environment
(perhaps via some desktop thing: in your case it seems to be LXDE),
then the first go to is your desktop thing's session management.

This way all consoles you start will inherit the "coordinates" of
the agent (in the form of the shell variables SSH_AGEN_PID,
SSH_AUTH_SOCK and perhaps others I forget). With no desktop environ
(plain X), X session management (see /etc/X11/XSession.d for
Debian; there is a 90x11-common_ssh-agent for that). Otherwise
you have to cook up something in your ~/.profile which looks
whether there's an agent around and set it up when no. In a nutshell


  - using a DE: your DE's session management
  - X without DE: X session management
  - naked console: .login, .profile (or .bash_profile, .bash_login)

Have fun
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlfrikAACgkQBcgs9XrR2kbyVwCcDqnECoJHdevg6AXn4Va6TcZO
J4YAnR8vi2TEcBsPNJrm9V2S/TVM6hhz
=wPAD
-END PGP SIGNATURE-

Re: Issues with SSH pubkey authentication at remote server

[Stephan Beck]

Hi Lars,

Lars Noodén:
> On 09/27/2016 06:07 PM, Stephan Beck wrote:
>> Lars Noodén:
>>> On 09/27/2016 02:02 PM, Stephan Beck wrote:
>>> Can you tell more about how your login session is started?
>>
>> I connect to the "local ssh account" by ssh from my other user account.
> 
[...]
> You need a way for your "local ssh account" to start and use an agent.
> I'm not sure of the optimal way for you.  Perhaps something in .bashrc?
> Others here know more about the shells than I.

Or in .profile. But I am not really sure about the exact syntax to use
(this if/then "thing"). I still have to get familiar with that.

I just checked in LX Session Configuration that the ssh-agent is
configured as -->Core applications but disabled in --> Autostart. So
there is another program/process/script that has to be launching the
ssh-agent, because I find it twice in the process list when I login to
my "normal" user account. I'm shivering :-)

I'll keep you informed.

Thanks again.

Stephan

Re: Issues with SSH pubkey authentication at remote server

[Lars Noodén]

On 09/27/2016 06:07 PM, Stephan Beck wrote:
> Lars Noodén:
>> On 09/27/2016 02:02 PM, Stephan Beck wrote:
>> Can you tell more about how your login session is started?
> 
> I connect to the "local ssh account" by ssh from my other user account.

Ok.  Now I see the arrangement.  You are missing a way for "local ssh
account" to receive information about any agent(s) it should have.
If you use ps you can probably see your main account running ssh-agent,
the system having launched it for you and managing the setting of the
appropriate environment variables.

> Now I've tried it several times always repeating this
> eval $(ssh-agent)
> ssh-add /path/to/key
> ssh-add -L (for checking)
> procedure and I do not have to enter the passphrase for this session.

You need a way for your "local ssh account" to start and use an agent.
I'm not sure of the optimal way for you.  Perhaps something in .bashrc?
Others here know more about the shells than I.

>From my point of view I do not need to have the same env in the "local
> ssh account" as I have in the other account.

No, but the "local ssh account" instances need to share the ssh-agent
variables.  If you are logging in multiple times at the same time, you'd
want to share the same agent for that account until the last one logs out.

Regards,
Lars

Re: Issues with SSH pubkey authentication at remote server

[Stephan Beck]

Hi Lars,

Lars Noodén:
> 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:
[sorry for trimming]

>> 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?
[...]

>Can you tell more about how your login session is started?

I connect to the "local ssh account" by ssh from my other user account.
Now I've tried it several times always repeating this
eval $(ssh-agent)
ssh-add /path/to/key
ssh-add -L (for checking)
procedure and I do not have to enter the passphrase for this session.
>From my point of view I do not need to have the same env in the "local
ssh account" as I have in the other account.

Thanks
Stephan

Re: Issues with SSH pubkey authentication at remote server

[Lars Noodén]

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

Re: Issues with SSH pubkey authentication at remote server

[Stephan Beck]

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

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

[Stephan Beck]

Hi,

[UPDATE]
Stephan Beck:
> Hi Mark,
> 
> Mark Fletcher:
>> On Mon, Sep 26, 2016 at 02:52:00PM +, 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

Re: Issues with SSH pubkey authentication at remote server

[Stephan Beck]

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

Re: Issues with SSH pubkey authentication at remote server

[Stephan Beck]

Hi Mark,

Mark Fletcher:
> On Mon, Sep 26, 2016 at 02:52:00PM +, 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

Re: Issues with SSH pubkey authentication at remote server

[Mark Fletcher]

On Mon, Sep 26, 2016 at 02:52:00PM +, 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

Re: Issues with SSH pubkey authentication at remote server

[Stephan Beck]

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

Re: Issues with SSH pubkey authentication at remote server

[Dan Purgert]

-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

Re: Issues with SSH pubkey authentication at remote server

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

Regards,
Lars

Re: Issues with SSH pubkey authentication at remote server

[Stephan Beck]

Hi Mark,

Mark Fletcher:
> On Mon, 26 Sep 2016 at 19:22, Stephan Beck  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

Re: Issues with SSH pubkey authentication at remote server

[Stephan Beck]

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

Re: Issues with SSH pubkey authentication at remote server

[Stephan Beck]

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

Re: Issues with SSH pubkey authentication at remote server

[Stephan Beck]

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

Re: Issues with SSH pubkey authentication at remote server

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

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...@master.debian.org
>
> Cheers,
>
> Stephan

Re: Issues with SSH pubkey authentication at remote server

[Dan Purgert]

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

Re: Issues with SSH pubkey authentication at remote server

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

Re: Issues with SSH pubkey authentication at remote server

[Stephan Beck]

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...@master.debian.org

Cheers,

Stephan

Re: Issues with SSH pubkey authentication at remote server

[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...@master.debian.org

Lisi

Re: Issues with SSH pubkey authentication at remote server

[Mark Fletcher]

On Mon, 26 Sep 2016 at 19:22, Stephan Beck  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 
> 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 0x0400
> 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

Issues with SSH pubkey authentication at remote server

[Stephan Beck]

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 
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 0x0400
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!