Re: [aur-general] Git over HTTPS
The OP should use a proxy, VPN, or other methods to punch a hole through
Thanks for the replies. the corporate firewall for being able to access the aur host. Unfortunately, this is not an option by any means. With all due respect, requiring that a user punch holes in their security firewalls is not a proper or long term solution to the issue at hand. For home users, this might be a valid (although no less sane) solution, but in corporate networks where the firewall rules are crafted for a reason (e.g. to protect the rest of the devices on the network). As I mentioned in my original posting, (and as several other users mentioned) many of the solutions are server-side fixes. I firmly believe that restricting access to SSH, port 22 only, is something that will greatly hinder wide adoption. At the very least, it will prevent myself from uploading/updating my several AUR packages. Cheers, -- Thomas Swartz
Em 15-06-2015 16:26, Tom Swartz escreveu:
With all due respect, requiring that a user punch holes in their security firewalls is not a proper or long term solution to the issue at hand.
It is the only solution.
For home users, this might be a valid (although no less sane) solution, but in corporate networks where the firewall rules are crafted for a reason (e.g. to protect the rest of the devices on the network).
A rule that denies outgoing SSH access is a dumb one. It doesn't protect the rest of the devices on the network.
As I mentioned in my original posting, (and as several other users mentioned) many of the solutions are server-side fixes.
Which requires using software that, not only can introduce security issues, can decrease the performance. I've used sshlp on the past, although I don't think it has any exploitable bugs, it's not as widely used as nginx and openssh itself.
I firmly believe that restricting access to SSH, port 22 only, is something that will greatly hinder wide adoption. At the very least, it will prevent myself from uploading/updating my several AUR packages.
Instead of requiring others to solve your problem, you should explain to your network administrators that this rule is counterproductive. I don't really think that this will hinder adoption since port 22 is the default ssh port. Cheers,
2015-06-15 16:33 GMT-03:00 Giancarlo Razzolini <grazzolini@gmail.com>:
Em 15-06-2015 16:26, Tom Swartz escreveu:
With all due respect, requiring that a user punch holes in their security firewalls is not a proper or long term solution to the issue at hand.
It is the only solution.
Is not the only as pointer in this thread, also you not considered the idea that burocracy for somethink that simple as oppen a port could take months if not year or even coutless failed attempts?
For home users, this might be a valid (although no less sane) solution, but in corporate networks where the firewall rules are crafted for a reason (e.g. to protect the rest of the devices on the network).
A rule that denies outgoing SSH access is a dumb one. It doesn't protect the rest of the devices on the network.
In my school we get attempts to forcebrute into ouir server... this once was attempted throw port 22, that what I get in response for request open port 22 in my school firewal. Therefor they refuse to open 22 since that insident.
As I mentioned in my original posting, (and as several other users mentioned) many of the solutions are server-side fixes.
Which requires using software that, not only can introduce security issues, can decrease the performance. I've used sshlp on the past, although I don't think it has any exploitable bugs, it's not as widely used as nginx and openssh itself.
or you think is saner that every user repeat a process for every machine, instead of offerted an alternative port for those countless users that cant (as I mention ealy) oppen 22?
I firmly believe that restricting access to SSH, port 22 only, is something that will greatly hinder wide adoption. At the very least, it will prevent myself from uploading/updating my several AUR packages.
Instead of requiring others to solve your problem, you should explain to your network administrators that this rule is counterproductive. I don't really think that this will hinder adoption since port 22 is the default ssh port.
Well burocracy and dumb admins are nought to not let you open port 22,
this word is a place ful of peoples of all kinds, and full of dumb decisions.
Cheers,
-- *Pablo Lezaeta*
Le 15/06/2015 22:00, Pablo Lezaeta Reyes a écrit :
2015-06-15 16:33 GMT-03:00 Giancarlo Razzolini <grazzolini@gmail.com>:
Em 15-06-2015 16:26, Tom Swartz escreveu: A rule that denies outgoing SSH access is a dumb one. It doesn't protect the rest of the devices on the network.
In my school we get attempts to forcebrute into ouir server... this once was attempted throw port 22, that what I get in response for request open port 22 in my school firewal.
Therefor they refuse to open 22 since that insident.
Then you should precise you want *outgoing* on port 22 to be open. Not /incoming/. Bruno
If your network admins don't know the difference between incoming and outgoing ports, or not opening things like ssh ports to the internet that really isn't an Arch problem... - Justin -- Regards, Justin Dray E: justin@dray.be M: 0433348284
Em 15-06-2015 17:00, Pablo Lezaeta Reyes escreveu:
Is not the only as pointer in this thread, also you not considered the idea that burocracy for somethink that simple as oppen a port could take months if not year or even coutless failed attempts?
Well, each organization has it's own process. But, it doesn't protect any internal machine not to allow outgoing ssh.
In my school we get attempts to forcebrute into ouir server... this once was attempted throw port 22, that what I get in response for request open port 22 in my school firewal.
Yes, this is a common problem. You can have some sort of blocking daemon, like fail2ban, or you can change the ssh port altogether. But, I don't see arch doing this, since tcp port 22 is the IANA assigned port for SSH. I bet they have bruteforce mitigations in place, on top of only allowing PubKey authentication.
Therefor they refuse to open 22 since that insident.
or you think is saner that every user repeat a process for every machine, instead of offerted an alternative port for those countless users that cant (as I mention ealy) oppen 22? Well burocracy and dumb admins are nought to not let you open port 22, this word is a place ful of peoples of all kinds, and full of dumb decisions.
If they can't distinguish, as other people already mentioned, from incoming and outgoing, then they should really rethink their carreers. It's the same thing with ICMP or VLAN's. I don't really worry about being blocked at any place I might go because I use a VPN. I think everybody should get one, not just for better privacy and unblocked internet access, but for avoiding ISP QoS. But it's sad to know that some people will let this kind of blocking (which is relatively easy to circumvent) prevent them from contributing to arch. Cheers, Giancarlo Razzolini
On 15 June 2015 at 21:33, Giancarlo Razzolini <grazzolini@gmail.com> wrote:
Em 15-06-2015 16:26, Tom Swartz escreveu:
With all due respect, requiring that a user punch holes in their security firewalls is not a proper or long term solution to the issue at hand.
It is the only solution.
AFAICS it's "the only solution" only due to decisions made by the people maintaining AUR, or is there some technical reason that makes it *impossible* to allow HTTPS access to the git repos?
For home users, this might be a valid (although no less sane) solution, but in corporate networks where the firewall rules are crafted for a reason (e.g. to protect the rest of the devices on the network).
A rule that denies outgoing SSH access is a dumb one. It doesn't protect the rest of the devices on the network.
I fully agree with you, but you make a very common mistake here: you apply logic and rational thinking to a situation that isn't governed by it :) You know it's a silly rule, I know it's a silly rule, everyone I interact with at work on a daily basis knows it's a silly rule. However, convincing the IT department of a 50000+ behemoth of a company that it's a silly rule *and that it should be changed* is a huge undertaking!
I firmly believe that restricting access to SSH, port 22 only, is something that will greatly hinder wide adoption. At the very least, it will prevent myself from uploading/updating my several AUR packages.
Instead of requiring others to solve your problem, you should explain to your network administrators that this rule is counterproductive. I don't really think that this will hinder adoption since port 22 is the default ssh port.
You clearly are fortunate enough to only be surrounded by people who base their decisions on logic and who are willing to go back on earlier decisions, and make changes solely based on well-founded arguments presented by engineers. I've worked in about 10+ different organisations, ranging in size from 50 to 100000+ and I have still to find a place like the one you are in. I strongly urge you to *never* switch jobs! /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus
participants (6)
-
Bruno Pagani
-
Giancarlo Razzolini
-
Justin Dray
-
Magnus Therning
-
Pablo Lezaeta Reyes
-
Tom Swartz