Adding here my thoughts I also explained on IRC. I appreciate very much we allow only ssh write access, and we should not copy https access from github at all (one of the many things I really don't like of github).

When you say password access without compromising security...that's just not true. no password is more secure than an ssh key, actually. So let's keep it as it is. I understand there might be some difficulties for some people, but I cannot push either @dayjob but have to use a personal laptop.
Authentication with a token is possible, but actually probably more difficult as we do on infrastructure.

Anyway, I wanted to add just my two cents here, security should remain a priority for pagure.

Note that online editing is an option, so as ugly as it is, a person could change the file locally, test them and then do the commits online by copy/pasting the changes.

As for https push I do not know. I read a bit of the gitolite code the other day and saw some pieces about pushing via https so gitolite might allow it, but I don't know how much work it would need.

If we can't make gitolite work, then I'm not sure we'll be able to support pushing via https.

Is there any port that person could use? Maybe tunnel through another server with ssh listening on a non-standard port? (Or maybe even listening on port 80 or 443 which are very rarely blocked :))

So then that leaves me with the question, what do we do for future contributors down the line who wish to contribute (or are contributing) but are unable to bypass limitations in their own firewalls?

I think it's worth looking into seeing if gitolite makes this possible. If not, we should have a hard look at our documentation for finding ways for people to either get around this or submit contributions in some other form (maybe an easy way to add patch files or something?).

As for another port to try, they might be able to use port 443, but having some good docs to link to (even if they're not our own) might be something to find or put together.

Have we considered the option of ssh over http such as corkscrew?

I still don't see a real issue here. You can file easily patches and apply them later or do pull requests when you aren't anymore behind a ssh blocking firewall. Fedorahosted.org had the same behaviour and it was always fine.

I think it's worth looking into seeing if gitolite makes this possible. If not, we should have a hard look at our documentation for finding ways for people to either get around this or submit contributions in some other form (maybe an easy way to add patch files or something?).

Adding a file to a ticket should be an easy drag and drop :)

Firewalls blocking outbound ssh from student desktops are just plain broken. These people should be going back to their network administrators and complain.
Work places are different. If they are trying to prevent exfiltration of data, there may be legitimate reasons for the block. In this case the people should follow the normal company process for getting an exception to be able to do their job.

I didn't see this issue before. I am one of them who is suffering from this. ssh to external server is blocked in our network.

Coming to the point mentioned by @bruno, sometimes it doesn't work. I don't know about your country, but in India, more often than not, you will find wrong people with too much power. The situation in my college is, The head of the network committee deserves every word in this list. (I know because i am part of the student body in the tech club of our college and have interacted with him a lot many time, each one equally painful.). The only person who is above him is the director of our college who seems to nod to everything this guy says. We did try to complain to the director but nothing helped. Since, the number of people using ssh to external server is very very less (probably single digit in our college), our matter was considered "not strong enough".

I am fully in support of providing access via HTTPS. Besides the reason mentioned by @jflory7, it also lowers the barrier to contribute for the beginners. If you see from the beginners point of view, what extra efforts they need to do besides their academics: let's say they were taught python in classes, still they have to learn a web framework (flask here), git, the work flow pull-request/merging and then understand the code of the project they want to contribute. As i think, ssh thing may not be a big deal when you have everything set up but sure is when you have to learn these things to get at that point and it's the first time you are dealing with it. (they teach networking in 3rd year, not that it should prevent them from learning about it before they teach. but still you never actually use in daily life)

If the security reasons are somehow taken care of, then i think this is a must have. If approved, i will be happy to work on this issue.

Unless the underlying access method is changed, git over https would be a very big change. I think providing some way to tunnel traffic would be a better approach for the short term.

Quoting @bruno.

Restricting push to ssh prevents the contributions to pagure hosted projects of anyone that works from a secure network where external ssh is forbidden for the usual reasons

modern https crypto should be as secure as ssh, without the risks associated to a too powerful protocol like ssh/scp (ssh/scp permits the target to inject commands to the source under certain circumstances, that's why the security guys block it. https is nicely unidirectional)

corkscrew is just a way to hole firewalls, it will get blocked if security notices it (with heavy sanctions)

Online editing is not an option for anything but the most trivial contributions. So that's ok if you don't want contributions to happen.

So that's ok if you don't want contributions to happen.

Sounds like the best way to ask someone to do work for you :)

Suggesting the work of others is so simple, and their time so worthless, that cut and pasting changes in the web interface is a solution, is not nice or friendly.

I regret that I do not have better words to explain this.

@nim

Online editing is not an option for anything but the most trivial contributions. So that's ok if you don't want contributions to happen.

He was suggesting something that people might forget (i do many times). Here is an idea, why don't you make a contribution to pagure and add the feature you so badly want that you couldn't discuss nicely.

Suggesting the work of others is so simple, and their time so worthless

Is it just me or you find this ironical as well?

It's only ironical if you assume that people asking for this enhancement are not doing anything for you outside of this RFE.

Anyway, I think my answer to https://pagure.io/pagure/issue/811#comment-1882 still stands.
I remember gitolite seems to have some support for this but it needs more time to investigate especially how the authentication works since we're using openid for the UI and ssh keys for the shell access.
This RFE is still valid, its use-case is known, it just needs time to investigate if we can do it or not.

Is there any news here? I'm supposed to rehost some Fedora projects on pagure, but every time the subject comes up I remember how this issue and https://pagure.io/pagure/issue/861 would make my maintainer workflow hell when not on my home system, so I procastinate and do other non pagure-related tasks instead.

There is support for HTTPS pushing in Pagure, but it requires switching the auth backend for pagure.io. I don't know what the plans are for this. @pingou, what are we planning to do here?

@nim

corkscrew is just a way to hole firewalls, it will get blocked if security notices it (with heavy sanctions)

It's not possible to tell corkscrew apart from other HTTPS traffic. The only thing that'd be suspicious would be the long connection times, but even that is fairly common these days. Modern browsers keep connections to servers open and just make new requests with the old connection.

Even if not, I don't believe pagure.io blocks Tor, and it certainly doesn't block random VPNs. You have many options to set up your own bypass method, from an SSH daemon on port 443 to VPNs.

I’ll put it another way then: not interested in rewarding my employer, which is nice enough to allow me to contribute to Fedora during my paid time, by poking holes in its firewall, just because pagure.io does not want to allow a push mode which is available by default on all other git hosting systems.

That would be unethical and would most likely result in the rescinding of this paid Fedora contribution time.

The use of corkscrew does not "poke holes in [your employer's] firewall", i=
t simply allows you to tunnel SSH over HTTPS=2E

On November 10, 2018 7:10:27 AM EST, Nicolas Mailhot pagure@pagure=2Eio =
wrote:

nim added a new comment to an issue you are following:
``
I=E2=80=99ll put it another way then: not interested in rewarding my empl=
oyer,
which is nice enough to allow me to contribute to Fedora during my paid
time, by poking holes in its firewall, just because pagure=2Eio does not
want to allow a push mode which is available by default on all other
git hosting systems=2E

That would be unethical and would most likely result in the rescinding
of thee paid Fedora contribution time=2E
``

To reply, visit the link below or just reply to this email
https://pagure=2Eio/pagure/issue/811

--=20
Sent from my mobile device=2E Please excuse my brevity=2E

The use of corkscrew does not "poke holes in [your employer's] firewall", i=
t simply allows you to tunnel SSH over HTTPS=

That’s just playing with words and you know it perfectly. You knew it perfectly when you wrote “It's not possible to tell corkscrew apart from other HTTPS traffic.” That’s the kind of weaselling guilty children routinely try, that only fools themselves, and that never impressed authorities, be it parents, employers or judges. I can tell you the usual childish “but blocking ssh is so unfair” follow-up argument does not cut it either so don’t bother.

Let’s all be adults here and state things as they are.

You want me do do things employer does not want to be done. Employer will object. I’d like to promote Fedora and Pagure use, but not at the cost of endangering employer support. There are only so many hours at night to contribute on personal time.

And, btw, a tunnel never secured anything, the tunnelled protocol keeps its security properties, good or (in the ssh case) bad.

@nim I doubt your employer would have any issue with the use tunnelled SSH. You should probably ask.

This method does not require any changes to the firewall, and while it certainly does bypass a misguided "security" configuration, it's perfectly harmless.

@nim I doubt your employer would have any issue with the use tunnelled SSH. You should probably ask.

Already done. The answer was no (for good security reasons, by people who actually looked at how ssh can be used to run commands from the destination to the origin).

This method does not require any changes to the firewall, and while it certainly does bypass

That’s weaseling. It does not do x, except effectively it does.

a misguided "security" configuration,

That’s the “but blocking ssh is so unfair” defense. It does not work in the real world.

Now you've got it out of your system, can you take 5s to realise yes, requiring ssh use in pagure.io is a problem for a class of pagure.io users.

it's perfectly harmless.

employer disagree. Paid time belongs to employer. Game over.

@nim

Already done. The answer was no

You've asked your employer if you can tunnel SSH over HTTPS?

for good security reasons, by people who actually looked at how ssh can be used to run commands from the destination to the origin

SSH indeed does allow you to run commands on the remote host. That's one of the ways to send data to the remote server, and is necessary for git over ssh.

That’s weaseling. It does not do x, except effectively it does.

No, it's a fact. You're not modifying the firewall rules, you're bypassing them by using a protocol that is allowed. You are legitimately making an HTTPS request, to provide a SSH connection.

That’s the “but blocking ssh is so unfair” defense. It does not work in the real world.
Now you've got it out of your system, can you take 5s to realise yes, requiring ssh use in pagure.io is a problem for a class of pagure.io users.

I have no qualms with the decision to block all ports but 443 and 80. It's a really stupid thing to do, but I have no issues with it. It's their network, they can do what they like with it. It gives them control over the network, as they can block protocols they're not familiar with, such as SSH, for users with little or no experience.

Most users I know of that encounter this just bypass it and move on.

For what it's worth, there's no reason that people should have to work around their network to contribute. It makes it so there's a higher barrier to contribution, and not everyone has the knowledge necessary to pull it off in a way that won't get them in trouble.

Ergo, we should implement HTTPS authentication for git push on pagure.io.

@ngompa HTTPS authentication would be fine for pagure.io, but only if it used client certificate based authentication rather than key based.

SSH indeed does allow you to run commands on the remote host. That's one of the ways to send data to the remote server, and is necessary for git over ssh.

ssh also allows tunnelling commands the other way.

That’s weaseling. It does not do x, except effectively it does.

No, it's a fact. You're not modifying the firewall rules, you're bypassing them by using a protocol that is allowed. You are legitimately making an HTTPS request, to provide a SSH connection.

And security objects to ssh connections in any form. For legitimate security reasons. Because ssh can establish bi-directional tunnels so any idiot within the network can easily be convinced to establish a bridge that voids the firewall protection. Can you understand that? employer objects to ssh connections, whether they are on port 22, 2222, 443, tunnelled over https, over TOR, whether you rename the ssh binary to notssh and whatever childish rule avoidance excuse you can invent next. Not everyone has the money or lack of legacy assets that allows redesigning internal networks in “no computer is trusted” mode.

And sure you could setup tunnels over https like corkscrew does that also void firewall protection, but that takes more work and you can’t argue you were not doing that deliberately when you get sacked. Or rather you can as you’re attempting to but it will impress no one.

Most users I know of that encounter this just bypass it and move on.

Most users are idiots that think problems happen to others, rules only apply to those others, and everyone but them will be caught. News at 11. One reason I am trusted to do free software at work is that I do not exhibit urges to do whatever is convenient rules be damned.

.

@nim If the client requests it, and the server supports it and has the options enabled, you can indeed tunnel over SSH. However, you seem to have some misunderstandings on the purpose of a firewall.

It's not about "getting caught". It's about a mistake on the part of your network administrators. By your logic, if HTTPS git transactions were to be enabled on this instance of Pagure, you would be working around your firewall, doing what is explicitly disallowed!

@nim If the client requests it, and the server supports it and has the options enabled, you can indeed tunnel over SSH.

And no one has the time or resources to check no client is configured this way on the internal network.

However, you seem to have some misunderstandings on the purpose of a firewall.
It's not about "getting caught". It's about a mistake on the part of your network administrators.

I could enlighten you on what network and network administrator means for us, and why I understand firewalls and their purpose thank you very much, and why you are being a total idiot here, but that would be a breach of employer confidence, so I’ll resist even though you tempt me a lot.

By your logic, if HTTPS git transactions were to be enabled on this instance of Pagure, you
would be working around your firewall, doing what is explicitly disallowed!

Did I say anything about git transactions? Nope. I wrote about ssh as a protocol that makes it trivial to create firewall-bypassing tunnels. git over https is perfectly fine. You visibly have never participated in any serious form of security risk assessment.

@nim

And no one has the time or resources to check no client is configured this way on the internal network.

It's not about client configuration, you can only get a channel back to the client side if you pass the -R flag.

I'm not going to participate in the poo flinging that came after that, I'd appreciate it if you'd keep ad hominem out of this discussion.

@nim

And no one has the time or resources to check no client is configured this way on the internal network.

It's not about client configuration, you can only get a channel back to the client side if you pass the -R flag.

And that makes it better how exactly from a security perspective? That makes it worse and impossible to secure, anyone who pastes a ssh cli line from an APT mail or a fake internet support site effectively voids the network protection. That’s exactly why ssh as a protocol is banned at employer.

I'm not going to participate in the poo flinging that came after that, I'd appreciate it if you'd keep ad hominem out of this discussion.

Please refrain from teaching lessons on network configs you know or understand nothing about then.

@nim The server you're connecting to must allow network tunnelling for -R to do anything. That said, if you find an OpenSSH server that allows open authentication (no authentication) and also allows tunnelling, please let me know! I'd have infinite uses for that.

I have not called you ignorant, I would certainly appreciate it if you would also refrain from doing so.

@nim The server you're connecting to must allow network tunnelling for -R to do anything.

So what? Think the people who bother with APT attacks of fake support sites won't enable it their side?

I have not called you ignorant,

Really? “You seem to have some misunderstandings on the purpose of a firewall”. “It's about a mistake on the part of your network administrators”. And so on. While every message just confirms why the ssh protocol is unsafe to open in some configurations.

@nim

So what? Think the people who bother with APT attacks of fake support sites won't enable it their side?

I've yet to find more than a handful of people that even know how to disable authentication in OpenSSH.

Really? “You seem to have some misunderstandings on the purpose of a firewall”. “It's about a mistake on the part of your network administrators”. And so on. While every message just confirms why the ssh protocol is unsafe to open in some configurations.

I have not. There is a difference between statement of fact (i.e. correcting a statement on firewall behaviour) and calling the author of the original post ignorant.

I'm going to drop this thread, as you obviously will not take good advice and move on.

@ngompa HTTPS authentication would be fine for pagure.io, but only if it used client certificate based authentication rather than key based.

I would firmly reject that as the sole option for HTTPS auth. As a matter of course, I hate cert based auth. I'd rather have something like access tokens that I can generate to use for HTTPS auth instead.

@nim
I have not. There is a difference between statement of fact (i.e. correcting a statement on firewall behaviour) and calling the author of the original post ignorant.

Then I’ll just say you seem to be completely mistaken about how corporation networks are set up, how they are secured, why they are secured this way, what is the purpose of a corporate firewall, and what your legal obligations as employee are. Otherwise you would not advise people to deploy corkscrew to bypass their employer security systems. See, just a plain statement of fact. Not calling you ignorant or anything. Makes you feel any better? Word plays do not change the meaning of what you write, people understand them just fine.

I'm going to drop this thread, as you obviously will not take good advice and move on.

You seem to be mistaken in thinking this thread is about giving some advice to ignorant persons when it is about enabling https auth on pagure.io. Like github or gitlab manage to do just fine.

The obviously correct resolution is to support pushing with HTTPS, disable it by default, and add an option in user settings to enable it and configure the authentication method, whether client certificates, one-time passwords, or even FAS passwords. In general, users should have control of how they authenticate to servers. Adversarial design where you try to nudge users into using more secure authentication methods than they want to, and more generally where you try to lock down all the doors and block the idiots at all costs, is bad.

@ngompa
I would firmly reject that as the sole option for HTTPS auth. As a matter of course, I hate cert based auth. I'd rather have something like access tokens that I can generate to use for HTTPS auth instead.

I would suck sure but a lot less than forcing ssh on persons that have no ssh access at work. I did it for years here for taxes, lately the tax office reverted to plain passwords, the added security was not worth the management pain. And states are dead serious about their taxes, if there is one system they will secure to hell, that’s this one.

@ngompa

I would firmly reject that as the sole option for HTTPS auth. As a matter of course, I hate cert based auth. I'd rather have something like access tokens that I can generate to use for HTTPS auth instead.

It's just not possible for a token to be as secure as proper key based authentication, and the user doesn't have to remember anything.

@nim

Then I’ll just say you seem to be completely mistaken about how corporation networks are set up, how they are secured, why they are secured this way, and what your legal obligations as employee are. Otherwise you would not advise people to deploy corkscrew to bypass their employer security systems. See, just a plain statement of fact. Not calling you ignorant or anything. Makes you feel any better? Word plays do not change the meaning of what you write, people understand them just fine.

I'm a netadmin, and I currently maintain several large networks. Really, I wouldn't be talking about network security if I didn't know what I was talking about.

I'm not suggesting that you alter your company's firewall, I'm suggesting that you do not. I understand why some misguided netadmins block more than they need to, and I understand the flaws with common implementations. Corkscrew is only one option, you could also just run an SSH daemon on port 443 in most cases, and you have a handful of other options.

As an employee, who is not a netadmin, you have an obligation to abide by your company's firewall. Therefore, I would not suggest doing anything that would change the firewall.

Instead, I suggest abiding by the firewall, and connecting to a remote server on port 443. The purpose of a firewall is to keep remote systems from connecting in, and potentially to keep malicious software on the inside from phoning home. It is not meant to block legitimate use.

I'm a netadmin, and I currently maintain several large networks.

In my book a large network is something you do not have the time to maintain alone and even less maintain several at once. Networks spanning several countries and continents with hundreds of endpoints (not @home vpn users, actual physical endpoints with one or several connection links, potential local child networks, several layers of security systems, and security rules updated all day round to take into account business changes) . And yes I worked on those and I wouldn't dream about writing “I” maintained them.

As an employee, who is not a netadmin, you have an obligation to abide by your company's firewall.

You should really spend an evening with your best attorney friend, the law does not work that way, your legal advice is terrible. You can't bypass the law or your contract on technicalities. That's why they are called technicalities in the first place. The law learned aeons ago to ignore people who thought it clever to achieve the same result via different technical means, thinking it exonerated them from their obligations.

For further clarification, and perhaps my last comment on this thread, I am not not an attorney and I am not providing legal advice, but it is not illegal (at least in my country) to perform legitimate network connected transactions. I don't really care to help you any more, and I wish you luck with somebody else.

Linux Plumbers Conference 2018: migrating freedesktop.org to GitLab

GitLab turns a patch submission into a pull request through a web page. Pushing and pulling Git branches also works well through corporate firewalls using HTTPS, allowing a more familiar browser-based workflow to be used.

GitHub was not really considered, but there are others (e.g. pagure) that were looked at.

Any news about this?

This is done with Pagure 5.10. You can now push via HTTPS using a pagure token for auth.