U2F not working with Gitea 1.10.3

[0x6d61726b]

• Gitea version (or commit ref):
  Gitea version 1.10.3 built with GNU Make 4.1, go1.13.6 : bindata, sqlite, sqlite_unlock_notify
• Git version:
  git version 2.20.1
• Operating system:
  Linux test 4.19.0-6-amd64 Rename import paths: "github.com/gogits/gogs" -> "github.com/go-gitea/gitea" #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) x86_64 GNU/Linux
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist: (level debug)
  2020/02/02 16:35:00 ...ce/gracehttp/http.go:142:Serve() [I] Serving [::]:3000 with pid 1234
2020/02/02 16:35:05 .../xorm/session_raw.go:76:queryRows() [I] [SQL] SELECT 'id', 'lower_name', 'name', 'full_name', 'email', 'keep_email_private', 'email_notifications_preference', 'passwd', 'passwd_hash_algo', 'must_change_password', 'login_type', 'login_source', 'login_name', 'type', 'location', 'website', 'rands', 'salt', 'language', 'description', 'created_unix', 'updated_unix', 'last_login_unix', 'last_repo_visibility', 'max_repo_creation', 'is_active', 'is_admin', 'allow_git_hook', 'allow_import_local', 'allow_create_organization', 'prohibit_login', 'avatar', 'avatar_email', 'use_custom_avatar', 'num_followers', 'num_following', 'num_stars', 'num_repos', 'num_teams', 'num_members', 'visibility', 'repo_admin_change_team_access', 'diff_view_style', 'theme' FROM 'user' WHERE 'id'=? LIMIT 1 []interface {}{1} - took: 102.363µs
2020/02/02 16:35:05 ...s/context/context.go:330:func1() [D] Session ID: 1bbce208aa01b2cd
2020/02/02 16:35:05 ...s/context/context.go:331:func1() [D] CSRF Token: 0-lR0jNh25DGmwImY3X7u9qOYoA6MTU4MDY1MTIwMTc1MTY2MjU2OQ
2020/02/02 16:35:05 .../xorm/session_raw.go:76:queryRows() [I] [SQL] SELECT count(*) FROM 'notification' WHERE (user_id = ?) AND (status = ?) []interface {}{1, 0x1} - took: 49.808µs
2020/02/02 16:35:05 .../xorm/session_raw.go:76:queryRows() [I] [SQL] SELECT 'id', 'name', 'user_id', 'raw', 'counter', 'created_unix', 'updated_unix' FROM 'u2f_registration' WHERE (user_id = ?) []interface {}{1} - took: 29.496µs

Description

I tried to add a yubikey security key/token to gitea and got the error message "Could not read your security key.". I used both Firefox 72.0.2 and Chrome 79.0.3945.130 but was unable to add the security key.

• Gitea is directly accessed via https (not yet through a reverse proxy, but port-forwarding from 443->3000).
• Both browers work fine on the YubiKey with WebAuthn and webauthn.io demo page.
• I cannot reproduce this problem at https://try.gitea.io (adding security key works there).

I already searched documentation and issues, but was not yet able to find a solution.
What can I do for further debugging? Unfortunately, the log does not output any error message.

Screenshots

[lunny]

Are you visiting a localhost? That will not work with U2F.

[0x6d61726b]

Hi @lunny,

thanks for your hint. I use a dyndns service to resolv to the public IP address of my ISP (to which also the SSL certificate was issued to by letsencrypt) which today resolves to 93.220.xxx.xxx. However gitea runs on the virtual machine with the IP address 192.168.1.6. Traffic is forwarded from the ISP router to the virtual machine with NAT.

Here is the tcpdump file that was captured during the "add security key" procedure:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
08:09:55.741008 IP 93.220.xxx.xxx.49866 > 192.168.1.6.3000: Flags [P.], seq 4280327037:4280327716, ack 1741328768, win 1025, length 679
08:09:55.741041 IP 192.168.1.6.3000 > 93.220.xxx.xxx.49866: Flags [.], ack 679, win 716, length 0
08:09:55.745807 IP 192.168.1.6.3000 > 93.220.xxx.xxx.49866: Flags [P.], seq 1:336, ack 679, win 716, length 335
08:09:55.790815 IP 93.220.xxx.xxx.49866 > 192.168.1.6.3000: Flags [.], ack 336, win 1024, length 0
08:09:59.951388 IP 93.220.xxx.xxx.49933 > 192.168.1.6.3000: Flags [.], seq 3126526437:3126526438, ack 1943948608, win 1025, length 1
08:09:59.951428 IP 192.168.1.6.3000 > 93.220.xxx.xxx.49933: Flags [.], ack 1, win 246, options [nop,nop,sack 1 {0:1}], length 0
08:09:59.963152 IP 93.220.xxx.xxx.49937 > 192.168.1.6.3000: Flags [.], seq 3555876064:3555876065, ack 1335527715, win 1024, length 1
08:09:59.963225 IP 192.168.1.6.3000 > 93.220.xxx.xxx.49937: Flags [.], ack 1, win 266, options [nop,nop,sack 1 {0:1}], length 0
08:09:59.963170 IP 93.220.xxx.xxx.49936 > 192.168.1.6.3000: Flags [.], seq 2695486276:2695486277, ack 2730822703, win 1025, length 1
08:09:59.963243 IP 192.168.1.6.3000 > 93.220.xxx.xxx.49936: Flags [.], ack 1, win 247, options [nop,nop,sack 1 {0:1}], length 0
08:09:59.982799 IP 93.220.xxx.xxx.49935 > 192.168.1.6.3000: Flags [.], seq 3937215492:3937215493, ack 2161389577, win 1025, length 1
08:09:59.982863 IP 192.168.1.6.3000 > 93.220.xxx.xxx.49935: Flags [.], ack 1, win 246, options [nop,nop,sack 1 {0:1}], length 0
08:10:00.077591 IP 93.220.xxx.xxx.49934 > 192.168.1.6.3000: Flags [.], seq 2568963727:2568963728, ack 1579807665, win 1023, length 1
08:10:00.077637 IP 192.168.1.6.3000 > 93.220.xxx.xxx.49934: Flags [.], ack 1, win 265, options [nop,nop,sack 1 {0:1}], length 0
14 packets captured
14 packets received by filter
0 packets dropped by kernel

Do you think this is the problem?

[lunny]

And could you have any js error on your chrome console?

[0x6d61726b]

I did not find any errors neither in Chrome nor in Firefox. I did update to the pre-Release (v1.11.0-rc2) just to see if that eliminates the issue, but that wasn't the case. This is also the reason why the error message looks different now. In addition I again tried using registration/login on webauthn.io which worked fine.

Can I do anything else to track-down this issue?
The log file still does not contain any further hints.

[0x6d61726b]

I did further debugging with Firefox console today (which I am more familiar with) and found out that I had an incorrect ROOT_URL entry in app.ini telling the wrong protocol and no port.

Incorrect setting:

DOMAIN           = <subdomainnamae>.dynv6.net
HTTP_PORT        = 3000
PROTOCOL         = https
ROOT_URL         = http://<subdomainnamae>.dynv6.net

After I changed the ROOT_URL the authentication worked as expected:

ROOT_URL         = https://<subdomainnamae>.dynv6.net:3000

Maybe additional information can be added to the manual?

Thanks again for your support.

[zeripath]

I don't understand why you've even set the ROOT_URL there. There's no need to set it - you've just set it to the default value.

The docs state:

ROOT_URL: %(PROTOCOL)s://%(DOMAIN)s:%(HTTP_PORT)s/: Overwrite the automatically generated public URL. This is useful if the internal and the external URL don’t match (e.g. in Docker).

You're not the only person I've seen do this but I still don't understand where it is coming from.

[zeripath]

Anyway as this was a configuration issue I'm going to close this.

[0x6d61726b]

I don't understand why you've even set the ROOT_URL there. There's no need to set it - you've just set it to the default value.
...
You're not the only person I've seen do this but I still don't understand where it is coming from.

What I was doing was running the installation wizard on http://\<ip-adress\>:3000/install which created the app.ini file that contains contains the following values in the server section (with SSH disabled):

[server]
SSH_DOMAIN       = localhost
DOMAIN           = localhost
HTTP_PORT        = 3000
ROOT_URL         = http://<fqdn>:3000/
DISABLE_SSH      = true
LFS_START_SERVER = true
LFS_CONTENT_PATH = /var/lib/gitea/data/lfs
LFS_JWT_SECRET   = <removed>
OFFLINE_MODE     = false

The ROOT_URL field value is set by the installation wizard and seems to get the value from the Gitea Base URL * (required) field.

So maybe thats an explanation why I am not the only person with that kind of non-recommended configuration?

[lunny]

@0x6d61726b That's a good workaround. Maybe we should add a hint on FAQ.