Showing results for 
Search instead for 
Did you mean: 

Ubuntu Repository Access Denied

Level 1
Level 1

I seem to be running into trouble accessing the Ubuntu repo as given in the duounix documentation -
It says to create /etc/apt/sources.list.d/duosecurity.list with the following contents:

deb xenial main
Then execute the following shell commands:
curl -s | sudo apt-key add -
apt-get update && apt-get install duo-unix
And here is where I hit some trouble. I get
Err:1 xenial InRelease 403 Forbidden [IP: 80] E: Failed to fetch 403 Forbidden [IP: 80] E: Some index files failed to download. They have been ignored, or old ones used instead.

So I am at a loss. What is going on here? Anyone else seeing this? Is there another repo I am unaware of?..

14 Replies 14

Level 1
Level 1

I attempted to reproduce this on both Xenial and Precise and didn’t run into your issue.
Are you on a 32bit or 64 bit Xenial server?

As a test are you able to download the deb directly?
$ wget

I am on a 64 bit Artful Aardvark server, actually. However, I don’t see how that would cause a problem with a Xenial repo.

I can download the deb directly, and that is how is ended up installing it, but I would love to figure out why I cannot do it through the repo.
Am I really the only one with this problem? If so, I can live with the direct download.

even going there in a browser gives me an error:

So far you’re the first to report this with Artful Aardvark. We have seen one similar issue with a Debian distro that we failed to reproduce and the customer dropped off so we couldn’t continue troubleshooting.
We typically don’t release packages for the non LTS releases so I’m not entirely sure how compatible downloading a 16.04 package on 17.10 is but I wonder if that’s causing issues.

One other hunch that we might want to explore is double checking that the gpg key downloaded correctly. If that key isn’t present I believe it’s possible apt-get will have errors.
When you ran the curl and then apt-key add commands what was the output? Did it say OK?

Well, I completely understand not updating for a non-LTS release and perhaps that has something to do with it. In which case, I can wait until the next Ubuntu LTS to try again.

The curl command DID return “OK”, yes.

So we just did some more testing on this with 17.10 and it appears that there is something different about how they do package management that breaks with our current system at
We will do our best to make sure we fix this for 18.04 so definitely check back in when that hits.
Thanks for using Duo!

Will do. Thanks for looking into it!

Level 1
Level 1

I have this same problem. I think it stems from how you’re handling non-existent files. The apt tool is trying to fetch an InRelease file (an inline-signed Release file, which can be used in addition to the Release and Release.gpg pair), and when it attempts to fetch that file, Duo’s repository server is returning a 403 Forbidden, rather than a 404 Not Found.

In Ubuntu 17.10, apt prefers using the InRelease file, but apt will fall back to the Release/Release.gpg combo if the InRelease file is not found. The Duo server, however, is not telling apt that the file is not found – the server is telling apt that it is forbidden from accessing it. This seems to be due to a blanket policy on the Duo server to return a 403 Forbidden for any URL that does not exist, rather than a proper 404 code.

I do not know if the reason this happens is because of a change in 17.10’s apt or a change on Duo’s side to the repository configuration to always return 403 Forbidden for any non-existent resource. Either way, if Duo starts returning a 404 Not Found for all non-existent resources (like the InRelease file), everyone’s apt fetches will start working. Alternatively, Duo could provide an InRelease file. I think Duo should make at least the first change because a) it’s proper HTTP handling and b) customers on Ubuntu 17.10 (and maybe older versions) are not getting any automated updates to the duounix code.

The issue with the customer with a Debian distro was probably related to a newer Debian distro that also supported the InRelease file. Given the age of Duo’s packages, they were probably deployed before the InRelease file was preferred for use.

Thanks for taking the time to explain this! I had suspected that it had something to do with a change to the way apt was grabbing from repositories, but I didn’t think about the 403 vs 404 workaround.
That seems like a relatively easy fix on our side. I’ll get this tracked internally so we can assess if it works and if there’s any other concerns to take into account.

Hi, not sure if related, but some firewalls, e.g. Sophos XG declares the pgp key as malware:

2018-04-26 09:41:13Malwaremessageid=“08001” log_type=“Anti-Virus” log_component=“HTTP” log_subtype=“Virus” status="" fw_rule_id=“1” user="" web_policy_id=“13” policy_name="" virus="" url=“” domain=“” src_ip=“” src_country=“R1” dst_ip=“” dst_country=“USA” protocol=“TCP” src_port=“46342” dst_port=“80” bytes_sent=“180” bytes_received=“517” user_agent=“Debian APT-HTTP/1.3 (1.2.26)” status_code=“500”

not only for duo also for e.g.

2018-04-26 12:33:52Malwaremessageid=“08001” log_type=“Anti-Virus” log_component=“HTTP” log_subtype=“Virus” status="" fw_rule_id=“1” user="" web_policy_id=“13” policy_name="" virus="" url=“” domain=“” src_ip=“” src_country=“R1” dst_ip=“” dst_country=“GBR” protocol=“TCP” src_port=“38632” dst_port=“80” bytes_sent=“229” bytes_received=“1063” user_agent="" status_code=“500”

Level 1
Level 1

Now that a new LTS release is available, will you be updating the repo and the install instructions on Duo Unix - 2FA for SSH with PAM Support (pam_duo) | Duo Security to reflect Bionic?


Level 1
Level 1

Any updates on support for Bionic?