Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
> From: Chris Johnson [mailto:effigies at riseup.net] > > True, and good point. Personally, I like SSH keys, but do you know of > any reasons to prefer HTTPS to SSH, apart from key management? Why build one when you can have two at twice the price? ;-) Honestly, they both work well. I think ssh is slightly more convenient, as more clients know how to use ssh keys for auto authentication, while by contrast, the ability to store the password in a https git client seems to be a hacked-on afterthought, if available at all. But yes, there is one specific situation where I cared about https instead of ssh. A company where I didn't control the firewall, they granted me inbound port 443, and refused to grant me inbound port 22. Similarly, I've worked at companies where they permit us to make *outbound* port 443 and not 22. So if I happened to want to connect to a public server that only gave me access on 22... Well... That sucks. So if your server is to be publicly facing, it's beneficial to enable every secure port, in order to reach the broadest range of users. If it's going to be internal and you have control over all the access barriers, then no worries. Do whatever you like best. Specifically for gitlab, I recommend, to always enable https, for the aforementioned security concern. In my most recent deployment, we got https working, and then I logged in and uploaded my ssh public key. So it's all irrelevant, everything's awesome. :-)
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |