# Package installation via ssh not https
**URL:** https://discourse.julialang.org/t/package-installation-via-ssh-not-https/9709
**Category:** New to Julia
**Tags:** package, ssh
**Created:** [March 14, 2018, 7:27am UTC](https://discourse.julialang.org/t/package-installation-via-ssh-not-https/9709 "2018-03-14T07:27:45Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@TAJD](https://discourse.julialang.org/u/TAJD)
#### Post date: [March 14, 2018, 7:27am UTC](https://discourse.julialang.org/t/package-installation-via-ssh-not-https/9709/1 "2018-03-14T07:27:46Z")
The server I’m using has out of date ca-certificates so I’m unable to use https to download julia packages - is there a way of changing the install process so I can use ssh to download packages off github?
---
### Author:  [@rdeits](https://discourse.julialang.org/u/rdeits)
#### Post date: [March 14, 2018, 12:55pm UTC](https://discourse.julialang.org/t/package-installation-via-ssh-not-https/9709/2 "2018-03-14T12:55:23Z")
You can use a `url` rule in your `~/.gitconfig` file to tell git to substitute one URL pattern for another:
```julia
[url "git@github.com:"]
insteadOf = https://github.com/
```
but I’m not entirely sure whether this will work in Julia’s built in LibGit2. Does that work for you?
---
### Author:  [@TAJD](https://discourse.julialang.org/u/TAJD)
#### Post date: [March 14, 2018, 2:21pm UTC](https://discourse.julialang.org/t/package-installation-via-ssh-not-https/9709/3 "2018-03-14T14:21:43Z")
Thanks for the suggestion but I’m afraid it doesn’t.
The issue lies with the login node I’m using having outdated ca-certificates and the support team can’t be bothered to sort out the dependency issues to update them.
I’m going to try seeing if I can clone my entire julia repository and running updates via my personal laptop. This is a little bit of a silly workaround - apparently only for outdated hardware.
---
### Author:  [@tk3369](https://discourse.julialang.org/u/tk3369)
#### Post date: [March 15, 2018, 3:43pm UTC](https://discourse.julialang.org/t/package-installation-via-ssh-not-https/9709/4 "2018-03-15T15:43:17Z")
Would it be good to have the package manager provide a way to use plain http than https at the discretion of the user?
---
### Author:  [@nalimilan](https://discourse.julialang.org/u/nalimilan)
#### Post date: [March 15, 2018, 4:32pm UTC](https://discourse.julialang.org/t/package-installation-via-ssh-not-https/9709/5 "2018-03-15T16:32:10Z")
You should be able to download an up-to-date certificates file and pass it to libgit2 when starting Julia via `SSL_CERT_FILE=/path/to/file.pem julia`. You can download certificates from [curl - Extract CA Certs from Mozilla](https://curl.haxx.se/docs/caextract.html). There’s also the `SSL_CERT_DIR` variable, and by default Julia will look for this file at `abspath(joinpath(Base.JULIA_HOME,Base.DATAROOTDIR,"julia","cert.pem"))`.
Julia 0.7 ships certificates files since [this PR](https://github.com/JuliaLang/julia/pull/24212), though there’s been [some discussion](https://github.com/JuliaLang/julia/pull/26125) about the fact that it should be the OS’s job.
---
### Author:  [@rdeits](https://discourse.julialang.org/u/rdeits)
#### Post date: [March 15, 2018, 4:52pm UTC](https://discourse.julialang.org/t/package-installation-via-ssh-not-https/9709/6 "2018-03-15T16:52:18Z")
Downloading packages over http means that anyone (e.g. a malicious ISP or wireless device) could inspect and alter the contents of your packages as you download them. This situation is even worse than normal web traffic over http because your Julia code is executed directly by the system instead of living in your browser’s sandbox.
Of course, Julia is probably not (yet) a popular target of attack, but this still seems like an unnecessary potential security hole.
---
### Author:  [@TAJD](https://discourse.julialang.org/u/TAJD)
#### Post date: [March 15, 2018, 5:47pm UTC](https://discourse.julialang.org/t/package-installation-via-ssh-not-https/9709/7 "2018-03-15T17:47:28Z")
Thanks for the comments all - I think the solution from nalimilan would have been the right one although the system I was working on was too old to work properly anyway. I’ve avoided the problem though being given access to a more up to date section of my unis supercomputer.