I just got the following result for a package push:
cppad>fedpkg push The authenticity of host 'pkgs.fedoraproject.org (38.145.60.17)' can't be established. RSA key fingerprint is SHA256:Q12OTyTeOHWlS54dTzy2BNu7wB8UKNf18+7WHIDsORc. Are you sure you want to continue connecting (yes/no/[fingerprint])?
Did something change recently ?
On Wed, Jan 06, 2021 at 03:19:13AM -0700, Brad Bell wrote:
I just got the following result for a package push:
cppad>fedpkg push The authenticity of host 'pkgs.fedoraproject.org (38.145.60.17)' can't be established. RSA key fingerprint is SHA256:Q12OTyTeOHWlS54dTzy2BNu7wB8UKNf18+7WHIDsORc. Are you sure you want to continue connecting (yes/no/[fingerprint])?
I can see the same fingerprint both on the server and in my ~/.ssh/known_hosts. I'm not aware of any change.
-- Petr
On Wed, Jan 06, 2021 at 03:19:13AM -0700, Brad Bell wrote:
I just got the following result for a package push:
cppad>fedpkg push The authenticity of host 'pkgs.fedoraproject.org (38.145.60.17)' can't be established. RSA key fingerprint is SHA256:Q12OTyTeOHWlS54dTzy2BNu7wB8UKNf18+7WHIDsORc. Are you sure you want to continue connecting (yes/no/[fingerprint])?
Did something change recently ?
No, nothing has changed recently on the server. Perhaps your ~/.ssh/known_hosts changed/was deleted?
If you add the contents of: https://admin.fedoraproject.org/ssh_known_hosts to your ~/.ssh/known_hosts it will verify it based on our CA.
If you enable 'VerifyHostKeyDNS' ssh option (in ~/.ssh/config or /etc/ssh/ssh_config) it will verify the host key based on the SSHFP dns record (and if you use this you likely want to use dnssec too).
kevin
1. Does this mean that 38.145.60.17 is the correct host address and I do not have to worry adding it to ~/.ssh/known_hosts ?
If so, I will get reply yes and continue with my push.
2. If I add the contents of https://admin.fedoraproject.org/ssh_known_hosts starting with a new line and at the end of my ~/.ssh/known_hosts and try 'fedpkg push` I get:
cppad>fedpkg push check_host_cert: certificate signature algorithm ssh-rsa: signature algorithm not supported The authenticity of host 'pkgs.fedoraproject.org (38.145.60.17)' can't be established. RSA key fingerprint is SHA256:Q12OTyTeOHWlS54dTzy2BNu7wB8UKNf18+7WHIDsORc. Are you sure you want to continue connecting (yes/no/[fingerprint])?
3. If I execute `dnf info openssh' I get
Name : openssh Version : 8.4p1 Release : 4.fc33
On Wed, Jan 06, 2021 at 03:19:13AM -0700, Brad Bell wrote:
I just got the following result for a package push:
cppad>fedpkg push The authenticity of host 'pkgs.fedoraproject.org (38.145.60.17)' can't be established. RSA key fingerprint is SHA256:Q12OTyTeOHWlS54dTzy2BNu7wB8UKNf18+7WHIDsORc. Are you sure you want to continue connecting (yes/no/[fingerprint])?
Did something change recently ?
On 1/6/21 10:52 AM, Kevin Fenzi wrote:
No, nothing has changed recently on the server. Perhaps your ~/.ssh/known_hosts changed/was deleted?
If you add the contents of: https://admin.fedoraproject.org/ssh_known_hosts to your ~/.ssh/known_hosts it will verify it based on our CA.
On Fri, Jan 08, 2021 at 05:03:34AM -0700, Brad Bell wrote:
- Does this mean that 38.145.60.17 is the correct host address and I do not
have to worry adding it to ~/.ssh/known_hosts ?
Yes.
- If I add the contents of https://admin.fedoraproject.org/ssh_known_hosts
starting with a new line and at the end of my ~/.ssh/known_hosts and try 'fedpkg push` I get:
cppad>fedpkg push check_host_cert: certificate signature algorithm ssh-rsa: signature algorithm not supported The authenticity of host 'pkgs.fedoraproject.org (38.145.60.17)' can't be established. RSA key fingerprint is SHA256:Q12OTyTeOHWlS54dTzy2BNu7wB8UKNf18+7WHIDsORc. Are you sure you want to continue connecting (yes/no/[fingerprint])?
It seems the certificate is signed with ssh-rsa SSH alghoritm which uses SHA-1 underneath and
- If I execute `dnf info openssh' I get
Name : openssh Version : 8.4p1 Release : 4.fc33
which is not supported by openssh-8.4p1 and Fedora 33 system-wide cryptopolicy.
I believe Fedora infrastrucure maintainers should create a new certificate with SHA-2 instead of SHA-1.
-- Petr
On Fri, Jan 08, 2021 at 03:29:01PM +0100, Petr Pisar wrote:
On Fri, Jan 08, 2021 at 05:03:34AM -0700, Brad Bell wrote:
- Does this mean that 38.145.60.17 is the correct host address and I do not
have to worry adding it to ~/.ssh/known_hosts ?
Yes.
Yep. Thats the correct ip.
- If I add the contents of https://admin.fedoraproject.org/ssh_known_hosts
starting with a new line and at the end of my ~/.ssh/known_hosts and try 'fedpkg push` I get:
cppad>fedpkg push check_host_cert: certificate signature algorithm ssh-rsa: signature algorithm not supported The authenticity of host 'pkgs.fedoraproject.org (38.145.60.17)' can't be established. RSA key fingerprint is SHA256:Q12OTyTeOHWlS54dTzy2BNu7wB8UKNf18+7WHIDsORc. Are you sure you want to continue connecting (yes/no/[fingerprint])?
It seems the certificate is signed with ssh-rsa SSH alghoritm which uses SHA-1 underneath and
- If I execute `dnf info openssh' I get
Name : openssh Version : 8.4p1 Release : 4.fc33
which is not supported by openssh-8.4p1 and Fedora 33 system-wide cryptopolicy.
I believe Fedora infrastrucure maintainers should create a new certificate with SHA-2 instead of SHA-1.
Well, it's sadly a bit more complex, but yes, I can resign the existing rsa host key with sha-2.
We want to at some point:
* move the last few hosts using rsa host keys to ed25519 (all but pkgs and bastion host are already moved), but we are waiting for openssh to implement a host key migration step so it will be transparent to users. * drop ssh commits entirely sometime and move to https / token.
pkgs didn't get signed with the new sha-2 key because we didn't move it to the new ed25519 host key. I'll try and fix it later today.
kevin
On Fri, Jan 08, 2021 at 09:34:02AM -0800, Kevin Fenzi wrote:
- drop ssh commits entirely sometime and move to https / token.
Token - Do you mean a pregenerated password which users store on their file system and which expires after three monts and the users needs to fiddle with some web pages to generate a new one? As Pagure does? In my opinion it is a terrible user experience and it's less safe. I recommend Kerberos.
-- Petr
On Mon, Jan 11, 2021 at 07:59:55AM +0100, Petr Pisar wrote:
On Fri, Jan 08, 2021 at 09:34:02AM -0800, Kevin Fenzi wrote:
- drop ssh commits entirely sometime and move to https / token.
Token - Do you mean a pregenerated password which users store on their file system and which expires after three monts and the users needs to fiddle with some web pages to generate a new one? As Pagure does? In my opinion it is a terrible user experience and it's less safe. I recommend Kerberos.
Yes, tokens. Kerberos is not very feasable due to various constraints.
But nothing is set yet, we are still exploring the best options.
kevin
On Wed, Jan 13, 2021 at 02:12:30PM -0800, Kevin Fenzi wrote:
Yes, tokens. Kerberos is not very feasable due to various constraints.
I'm curious what the constraints are.
On Wed, Jan 13, 2021 at 05:20:16PM -0500, Matthew Miller wrote:
On Wed, Jan 13, 2021 at 02:12:30PM -0800, Kevin Fenzi wrote:
Yes, tokens. Kerberos is not very feasable due to various constraints.
I'm curious what the constraints are.
Currently the reason ssh works is because users in the packager group have actual, real, full accounts on the server. We then override the command(s) they can run to the pagure wrapper. We want to move away from any users have any kind of 'real' accounts there.
So, then it becomes what pagure can support, and it has no Kerberos support. It could be added I suppose, but it doesn't exist at all currently.
kevin
On Wed, Jan 13, 2021 at 03:18:55PM -0800, Kevin Fenzi wrote:
On Wed, Jan 13, 2021 at 05:20:16PM -0500, Matthew Miller wrote:
On Wed, Jan 13, 2021 at 02:12:30PM -0800, Kevin Fenzi wrote:
Yes, tokens. Kerberos is not very feasable due to various constraints.
I'm curious what the constraints are.
Currently the reason ssh works is because users in the packager group have actual, real, full accounts on the server.
I'm not sure why it is a problem. I would even call it more secure because an operating system checking the file permissions will prevent a nefarious user from touching other's repositories.
So, then it becomes what pagure can support, and it has no Kerberos support. It could be added I suppose, but it doesn't exist at all currently.
I would not target to be-decommisioned Pagure.
-- Petr
* Petr Pisar:
I'm not sure why it is a problem. I would even call it more secure because an operating system checking the file permissions will prevent a nefarious user from touching other's repositories.
The way Git works is that if you can push to a local shared repository, you can very likely trigger code execution under other accounts that use the same repository locally.
So even with separate accounts, commands need to be filtered, and there is no immediate benefit to such separation.
Thanks, Florian
On Thu, Jan 14, 2021 at 09:06:46AM +0100, Petr Pisar wrote:
On Wed, Jan 13, 2021 at 03:18:55PM -0800, Kevin Fenzi wrote:
On Wed, Jan 13, 2021 at 05:20:16PM -0500, Matthew Miller wrote:
On Wed, Jan 13, 2021 at 02:12:30PM -0800, Kevin Fenzi wrote:
So, then it becomes what pagure can support, and it has no Kerberos support. It could be added I suppose, but it doesn't exist at all currently.
It is on the todo though. It should be trivial to do with mod_gssapi but I've been wondering if we could find a way to do it directly on pagure.
I would not target to be-decommisioned Pagure.
Well, I don't know that github supports kerberos and it doesn't support the FLOSS requirement and github doesn't support kerberos in its community edition. Do you have a better target?
Pierre
On Thu, Jan 14, 2021 at 11:29:08AM +0100, Pierre-Yves Chibon wrote:
On Thu, Jan 14, 2021 at 09:06:46AM +0100, Petr Pisar wrote:
On Wed, Jan 13, 2021 at 03:18:55PM -0800, Kevin Fenzi wrote:
On Wed, Jan 13, 2021 at 05:20:16PM -0500, Matthew Miller wrote:
On Wed, Jan 13, 2021 at 02:12:30PM -0800, Kevin Fenzi wrote:
So, then it becomes what pagure can support, and it has no Kerberos support. It could be added I suppose, but it doesn't exist at all currently.
It is on the todo though. It should be trivial to do with mod_gssapi but I've been wondering if we could find a way to do it directly on pagure.
Great.
I would not target to be-decommisioned Pagure.
Well, I don't know that github supports kerberos and it doesn't support the FLOSS requirement and github doesn't support kerberos in its community edition. Do you have a better target?
My impression from the public discussions is that the new target is GitLab.
-- Petr
On Thu, Jan 14, 2021 at 12:07:37PM +0100, Petr Pisar wrote:
On Thu, Jan 14, 2021 at 11:29:08AM +0100, Pierre-Yves Chibon wrote:
On Thu, Jan 14, 2021 at 09:06:46AM +0100, Petr Pisar wrote:
On Wed, Jan 13, 2021 at 03:18:55PM -0800, Kevin Fenzi wrote:
On Wed, Jan 13, 2021 at 05:20:16PM -0500, Matthew Miller wrote:
On Wed, Jan 13, 2021 at 02:12:30PM -0800, Kevin Fenzi wrote:
So, then it becomes what pagure can support, and it has no Kerberos support. It could be added I suppose, but it doesn't exist at all currently.
It is on the todo though. It should be trivial to do with mod_gssapi but I've been wondering if we could find a way to do it directly on pagure.
Great.
I would not target to be-decommisioned Pagure.
Well, I don't know that github supports kerberos and it doesn't support the FLOSS requirement and github doesn't support kerberos in its community edition. Do you have a better target?
My impression from the public discussions is that the new target is GitLab.
Which doesn't support kerberos in its community edition, so we're back to square one.
Pierre
On Mon, Jan 11, 2021 at 07:59:55AM +0100, Petr Pisar wrote:
On Fri, Jan 08, 2021 at 09:34:02AM -0800, Kevin Fenzi wrote:
- drop ssh commits entirely sometime and move to https / token.
Token - Do you mean a pregenerated password which users store on their file system and which expires after three monts and the users needs to fiddle with
Just a reminder that the expiration date can now be set to up to two years.
Pierre
packaging@lists.fedoraproject.org
-
Brad Bell -
Florian Weimer -
Kevin Fenzi -
Matthew Miller -
Petr Pisar -
Pierre-Yves Chibon