[asterisk-dev] Problems authenticating to gerrit.asterisk.org via ssh

Thu Aug 24 09:29:50 CDT 2017

Hey guys!

Since I already have a signed contributor license agreement, I wanted to submit a patch for ASTERISK-27168 to gerrit.
I proceeded as described in https://wiki.asterisk.org/wiki/display/AST/Gerrit+Usage including signing in and adding my public key for SSH.
However I am getting a „Permission denied (publickey)“ error.

Using ssh –v –p 29418 f.floimair at gerrit.asterisk.org

I am getting the following output:

OpenSSH_7.5p1, OpenSSL 1.0.2k  26 Jan 2017
debug1: Connecting to gerrit.asterisk.org [76.164.171.232] port 29418.
debug1: Connection established.
debug1: identity file /home/f.floimair/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/f.floimair/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/f.floimair/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/f.floimair/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/f.floimair/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/f.floimair/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/f.floimair/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/f.floimair/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.5
debug1: Remote protocol version 2.0, remote software version GerritCodeReview_2.14.1 (SSHD-CORE-1.4.0)
debug1: no match: GerritCodeReview_2.14.1 (SSHD-CORE-1.4.0)
debug1: Authenticating to gerrit.asterisk.org:29418 as 'f.floimair'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: ecdh-sha2-nistp256
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ssh-rsa SHA256:pK8Lib9M6vzy49IUucoMkd3KNnsXIidqC0KN4v9aFuE
debug1: Host '[gerrit.asterisk.org]:29418' is known and matches the RSA host key.
debug1: Found key in /home/f.floimair/.ssh/known_hosts:6
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/f.floimair/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/f.floimair/.ssh/id_dsa
debug1: Trying private key: /home/f.floimair/.ssh/id_ecdsa
debug1: Trying private key: /home/f.floimair/.ssh/id_ed25519
debug1: No more authentication methods to try.
Permission denied (publickey).

Any ideas what the problem with this might be?

With best regards

Florian Floimair

COMMEND INTERNATIONAL GMBH
A-5020 Salzburg, Saalachstraße 51

Security and Communication by Commend

FN 178618z | LG Salzburg

Von: asterisk-dev-bounces at lists.digium.com [mailto:asterisk-dev-bounces at lists.digium.com] Im Auftrag von Seán C. McCord
Gesendet: Mittwoch, 23. August 2017 19:47
An: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
Betreff: Re: [asterisk-dev] Asterisk 15 Beta Released

I just wanted to know if it was an out-of-hand distaste or some more fundamental complication.  Not enough timeshare is a perfectly acceptable reason.  It's not like I have a whole bunch of free time to do release engineering, after all, either!

Thanks

On Wed, Aug 23, 2017 at 9:59 AM Matt Fredrickson <creslin at digium.com<mailto:creslin at digium.com>> wrote:
On Fri, Aug 18, 2017 at 8:03 AM, Seán C. McCord <ulexus at gmail.com<mailto:ulexus at gmail.com>> wrote:
> Matt,
>
>  would you care to expound on your reasons against 14.6 -> LTS?  I don't
> have all the data, so I certainly don't discount the possibility that there
> are compelling "reasons," but those that you gave, such as they are, are too
> vague to form an argument against.

Hey Sean,

I think that Sidney hit the nail on the head.  Trying to go through
that kind of change right now would be challenging, a lot of it due to
preparations in getting 15 tested, released, and out there, Astricon
preparations, and more importantly, AstriDevCon preparations and other
things of that nature that are happening right now.  You'd never
believe how much time it takes to make all of that come together
(never mind all of the day to day demands).

It's a non insignificant amount of work from just a project policy
perspective to make a change like you and Dan are proposing.  I'm not
completely opposed to the proposal, but my fallback preference is to
just keep current policy and wait until 16 is released to cut a new
LTS.  Or at the very least discuss this more after 15 is released.

Matthew Fredrickson

>
>
> On Fri, Aug 18, 2017 at 5:07 AM Dan Jenkins <dan.jenkins88 at gmail.com<mailto:dan.jenkins88 at gmail.com>> wrote:
>>
>>
>>
>> On Thu, Aug 17, 2017 at 11:11 PM, Matt Fredrickson <creslin at digium.com<mailto:creslin at digium.com>>
>> wrote:
>>>
>>> On Tue, Aug 15, 2017 at 1:15 PM, Dan Jenkins <dan.jenkins88 at gmail.com<mailto:dan.jenkins88 at gmail.com>>
>>> wrote:
>>> >
>>> >
>>> > On Wed, Aug 2, 2017 at 10:57 PM, Matt Fredrickson <creslin at digium.com<mailto:creslin at digium.com>>
>>> > wrote:
>>> >>
>>> >> It is with great pleasure I wish to inform you of the first beta
>>> >> release of the new Asterisk 15 branch. It's a very exciting time to be
>>> >> a user of Asterisk! Asterisk 15 is arguably the biggest release of
>>> >> Asterisk that has happened in the last 10 or so years. There has been
>>> >> a lot of work done in the Asterisk core to better support newer
>>> >> multi-stream video and WebRTC related technologies.  For those who are
>>> >> interested, much of this will be covered in blog posts at
>>> >> http://blogs.asterisk.org/ over the next month or two.
>>> >>
>>> >> Typically, when a new major branch of Asterisk is created (13, 14,
>>> >> 15...), there are a few months of testing on the new branch that
>>> >> occurs prior to release in order to find regressions and other issues
>>> >> that may cause a first official release from the branch to be dead on
>>> >> arrival for a significant number of users. With today's release of
>>> >> 15.0.0-beta1, this process has begun. Please feel free to start
>>> >> testing this version of Asterisk in as many adverse environments as
>>> >> possible. Any bugs should be reported on the Asterisk issue tracker at
>>> >> https://issues.asterisk.org/
>>> >>
>>> >> As a side note, due to many of the core changes in the 15 branch that
>>> >> have been made since Asterisk 14 was released, it has been decided
>>> >> that Asterisk 15 will not be an LTS release. For those of you who are
>>> >> not familiar with the differences between LTS versus standard
>>> >> releases, you can find more information here [1].
>>> >>
>>> >> Thanks to all the many Asterisk community members for providing so
>>> >> much help and support to make Asterisk the great open source project
>>> >> that it is.
>>> >>
>>> >> P.S. Binary codecs and other modules distributed by Digium are not
>>> >> immediately available for 15.0.0-beta1, but should be shortly.
>>> >>
>>> >> Best wishes to all, and happy testing!
>>> >>
>>> >> [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions
>>> >>
>>> >> --
>>> >> Matthew Fredrickson
>>> >> Digium, Inc. | Engineering Manager
>>> >> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
>>> >>
>>> >> --
>>> >> _____________________________________________________________________
>>> >> -- Bandwidth and Colocation Provided by http://www.api-digital.com<https://linkprotect.cudasvc.com/url?a=http://www.api-digital.com&c=E,1,7wDaYRtWYviW4WXIOsh7fNkYd0uUySx5vCpCzK9UGhYi040N8I4sVHgNUxHFBGnCSx0QmrovFDD0O39zR6UuWASlblEWzrpGwXmd13Ehhz-JnAuNNVr9z1uj&typo=1> --
>>> >>
>>> >> asterisk-dev mailing list
>>> >> To UNSUBSCRIBE or update options visit:
>>> >>    http://lists.digium.com/mailman/listinfo/asterisk-dev<https://linkprotect.cudasvc.com/url?a=http://lists.digium.com/mailman/listinfo/asterisk-dev&c=E,1,eaQK9k4stxDTVzAMlQpMrLkxamIl9naJ8s5AIfMIdvrixO7sYZlaSRcWd9xh64seVbbNnlCpZ7QSzDXzlYbqnaI8cEuCwXHB78-yqaM6vgdgnhMsDw,,&typo=1>
>>> >
>>> >
>>> > After talking to Sean McCord about this, I realised you didn't say
>>> > anything
>>> > about releasing a new LTS; which you don't _have_ to do but personally
>>> > I
>>> > have clients who are looking to use new features in 14 under an LTS and
>>> > that's what we were expecting - I'm sure there are businesses out there
>>> > that
>>> > still want an LTS to move to.
>>> >
>>> > The reason we are all expecting an LTS is because of this line in the
>>> > wiki
>>> > on the page you linked to "New releases of Asterisk will be made
>>> > roughly
>>> > once a year, alternating between standard and LTS releases."
>>> > (https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions)
>>>
>>> First off, thanks for expressing your sincere concerns with not making
>>> 15 an LTS release :-)
>>>
>>> I know that this change will cause some difficulty for certain members
>>> of the community, particularly with those that were expecting 14
>>> related features to be in an LTS sometime soon.  This discussion is
>>> something that has been on my mind for a while and the decision was
>>> not made lightly.
>>>
>>> The major reason that it was decided to break convention and to not
>>> make 15 an LTS is that there were some fairly considerable core
>>> changes to Asterisk necessary to make the multi-stream work come
>>> together to build an MVP video SFU out of Asterisk, which was our
>>> goal.  Bearing that in mind, we did not feel comfortable building an
>>> LTS release fresh off of those considerable core changes.
>>>
>>> We also anticipate a number of other considerable changes going into
>>> the 15 branch as people start to play with the new SFU support.  Since
>>> our proof of concept client is so bare bones (doesn't use Asterisk ARI
>>> APIs yet) we expect there to be many of ARI API enrichments that are
>>> likely to happen as people start to play with the new SFU support in
>>> app_confbridge.  There are also potentially more fundamental changes
>>> that could break clients if some of our initial behavioral assumptions
>>> are incorrect, such as how app_confbridge reuses negotiated streams on
>>> peerconnections or how new streams are negotiated and in what order.
>>>
>>> I know this places great difficulty on those who are using 14 features
>>> counting on 15 being an LTS, but to be honest, I don't think that you
>>> would want to use those features in a 15 LTS if you were concerned
>>> about potential stability changes.  While we earnestly hope that 15
>>> will continue 13 and 14's trend of being some of most solid stable
>>> releases that have been cut, in an abundance of caution we decided to
>>> break convention and make it non-LTS.
>>>
>>> > I'd like to propose that we make 14.6 (or later) the LTS in a similar
>>> > fashion to how other communities are now promoting versions to LTS mid
>>> > cycle
>>> > (https://github.com/nodejs/LTS). That way you get to release all the
>>> > exciting things that are in 15 but as a community we get LTS support on
>>> > everything thats now in 14 - as we know, some businesses will not move
>>> > to a
>>> > non LTS and I think it would be a real shame to not get particular
>>> > organisations moved over to using some of the great things that have
>>> > been
>>> > added in 14.
>>> >
>>> > What are everyone's thoughts?
>>>
>>> So from a project policy perspective, and due to the many other
>>> burdens we have right now, I don't feel comfortable making this change
>>> at this time.  I'm not saying it's never going to happen, just that I
>>> can't imagine going forward with everything else going on right now.
>>>
>>> From a compromise position perspective, if your customers really would
>>> like to get on an LTS with particular features that they're enjoying
>>> in 14 (such as newer ARI changes, etc), there is a potential pathway
>>> forward that might allow this sooner rather than later.  As long as
>>> the changes they want are not of the nature to destabilize the
>>> codebase (such as the DNS changes and a few others) or breaking API
>>> changes, they can find a software developer to backport them into the
>>> 13 branch.  Obviously, this requires submitting tests for features
>>> that didn't have tests originally submitted.  But this would allow the
>>> customer to have some of the new feature functionality of 14 in the 13
>>> branch.
>>>
>>> I know that isn't exactly what you were asking, but perhaps it might
>>> be another possibility for those who really want to remain on an LTS.
>>>
>>> Sorry to be the bearer of bad news on this :-(
>>>
>>> --
>>> Matthew Fredrickson
>>> Digium, Inc. | Engineering Manager
>>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
>>>
>>> --
>>> _____________________________________________________________________
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com<https://linkprotect.cudasvc.com/url?a=http://www.api-digital.com&c=E,1,SPzf5t79nJWeXteZxnrEGsAiy4CV5LAPdXPtEKEGleAqNyeyXTSTo0GNhxDIFwLk4PbKF2TQdKjrt-JXkpTM201Fth0bvc8n5Turkxfx4tP8&typo=1> --
>>>
>>> asterisk-dev mailing list
>>> To UNSUBSCRIBE or update options visit:
>>>    http://lists.digium.com/mailman/listinfo/asterisk-dev<https://linkprotect.cudasvc.com/url?a=http://lists.digium.com/mailman/listinfo/asterisk-dev&c=E,1,qje5VBLPMhAReXLkIylXwUSDIWbDQcF4NZcOfmRUy_ePMHOIclwXR5noykxkncOUgwoRQs1kotKTtH9zcWY0_LoMIfkqITl1-ODx2lF48jw_DrmbeQ,,&typo=1>
>>
>>
>>
>> So a compromise is having clients pay a developer to try and get those
>> changes into 13? I don't really see that as a compromise personally. When
>> those features were written, why weren't they written with tests and
>> backported into 13? Because its more difficult and time consuming.
>>
>> Its all semantics at the end of the day - whether you release 14 as 15 and
>> then have 15 be a LTS and then release what is 15 beta to be 16 - its all
>> just numbers. I don't want you to change your general policy on LTS version
>> numbers specifically - I just want an LTS as described in the same wiki
>> document you linked to - releasing 14.6 as an LTS is the way to do that.
>>
>> I don't really understand how as an open source project you can have a
>> public policy and then change that policy _just_ when people are expecting
>> that policy to come into force - if 6 months ago you had said "15 has a load
>> of changes in it and we want to break our LTS policy" then I'm sure people
>> would have thought and planned a bit more - but at this time we're just over
>> a month until Astricon where typically, the new version of Asterisk is
>> released, where we were expecting an LTS. This really leaves a bitter taste
>> in the mouth.
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com<https://linkprotect.cudasvc.com/url?a=http://www.api-digital.com&c=E,1,BbD26fNphCcmzTS_NDlXSeW-2_XRWGZO8H4lFJAIiZ2TKP9WU0SGjC2gGH8BBP7wnaoHQ4gi4XdWsuZqximajwQGcN8PtqX2XG5-wd3knci1G6jiNEKa&typo=1> --
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-dev<https://linkprotect.cudasvc.com/url?a=http://lists.digium.com/mailman/listinfo/asterisk-dev&c=E,1,kLaQGLikR5IUCe5rHy5ZdxnUJJ2O53JAesxc0M92W78kN0IIKwaFok5a4IO8raUScoidVG-77txEyYNWiAZj59XRq2DduzvO8ApestTiVw,,&typo=1>
>
> --
> Seán C McCord
> CyCore Systems, Inc
> +1 888 240 0308<tel:(888)%20240-0308>
> PGP/GPG: http://cycoresys.com/scm.asc<https://linkprotect.cudasvc.com/url?a=http://cycoresys.com/scm.asc&c=E,1,WyAjFGZJGeGgLzsPLZPwzccN4ln_563vwXtmYv2HOs4qjcBtHzmYkUjk8JQSTMnXzUpBI-DAFH8dByhdP2Vbo33ASwIVHel8V2FoiS5ZPA,,&typo=1>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com<https://linkprotect.cudasvc.com/url?a=http://www.api-digital.com&c=E,1,AqU2VNS9DYktKghFaO8NjsVIJDfmGHb6MS7cmC4Um2RQ6EkEoL4i-dUEhIGCa8UvDGbF6f4UakKEtD7ybh51cbZh8eI5pakLOB-nFc2b-N8vxg,,&typo=1> --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev<https://linkprotect.cudasvc.com/url?a=http://lists.digium.com/mailman/listinfo/asterisk-dev&c=E,1,LxE9RqSIctyQIf3fiCn6F3EFSW3BRoXYZIocERG-Q9D9trk97-0aaHu4-C_-OyTcp9IOBfbklae6Pmh82mwAxdrKHro5SVsD8Sb3tU0,&typo=1>

--
Matthew Fredrickson
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA

--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com<https://linkprotect.cudasvc.com/url?a=http://www.api-digital.com&c=E,1,4atMbryes_E1HzYL9HJ9Ui_KCuACjJ4a1UQT5Yn8qnUq3Ge2dBmadp6m8sCZhx7VCyvaZcwPo4BydMVUqaBlyLsmhJ1s5iWioipHwoM,&typo=1> --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev<https://linkprotect.cudasvc.com/url?a=http://lists.digium.com/mailman/listinfo/asterisk-dev&c=E,1,LNnRhfuzf-vE5S1suzJhSVhRp-5_ND12cdA0dM_yahdo7t9lJ_HgfWCdL6tJdr-t8s3kMlkvHvUlTPSzwCnWmLZM1BfMOVqJYWk0_fzG&typo=1>
--
Seán C McCord
CyCore Systems, Inc
+1 888 240 0308
PGP/GPG: http://cycoresys.com/scm.asc<https://linkprotect.cudasvc.com/url?a=http://cycoresys.com/scm.asc&c=E,1,XONKPwjC2f5pPviyGwJ0YFOcXcswcYpHgeJNK7U8PLoaJOYkD817S5eRvLSorY9r25gmZpRASsIbeBW3m44CzDXzPwwnQ_fv2FXuzvlRaLSI3_aAjSLlBiA,&typo=1>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20170824/7cfda09b/attachment-0001.html>