I have activated Identity Aware Proxy on a GCP Load Balancer and configured it to authenticate the users against my OIDC Identity Provider (Auth0) through Google Identity Platform with a default login page hosted on Cloud Run.
When I browse my application I got redirected to the login page but then this happens:
although the document is available and publicly reachable at that URL:
I followed GCP documentation step by step and cannot find any troubleshooting guide. Any thoughts?
Thanks
I have a couple of virtualized RHEL 6 running on a RHEV host. Both host and VMs have >1year uptime.
Only in the last two days they started seldom throwing these kernel messages at random times
kernel: Clocksource tsc unstable (delta = -17179878652 ns). Enable clocksource failover by adding clocksource_failover kernel parameter.
Fine: I'll follow the advice. The strange thing is, though, I'm not using tsc as a clocksource
[~]# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
kvm-clock
Studying the documentation of the clocksource framework, I came up with more questions than answers.
First of all, why is the kernel complaining about a clocksource that the system is not supposed to use? Is the kernel cycling anyway through all the available clocksources, perhaps? If yes, what for?
As far as I know, the message means that the current clocksource is drifted away from the watchdog clocksource more than WATCHDOG_THRESHOLD but what is the current watchdog clocksource? It cannot be kvm-clock, since it usually has CLOCK_SOURCE_MUST_VERIFY set. Is there a way to display it at runtime?
I understand that tsc isn't considered to be accurate with modern CPUs because of throttling/power saving features but /proc/cpuinfo tells that the processors seen by the VM have the constant_tsc flag. So I would assume tsc can also provide a quite reliable timing. Is that flag a "bypass" to the underlying real CPU or is it just an emulated one, running its own counter? In the first case, I could speculate that the host's scheduler switched the VM process to a different core having a drifted counter. Could this make sense?
This is quite a mistery for me. I usually use passwordless RSA authentication to login into my remote *nix servers with ssh and sftp. Never had any problem until now.
I cannot connect to an Ubuntu 9.10 machine:
user@myclient$ ssh -i .ssh/Ganymede_key [email protected]
[...]
debug1: Host 'ganymede.server.com' is known and matches the RSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:14
debug2: bits set: 494/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: .ssh/Ganymede_key (0xb96a0ef8)
debug2: key: .ssh/Ganymede_key ((nil))
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: .ssh/Ganymede_key
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: .ssh/Ganymede_key
debug1: read PEM private key done: type RSA
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Then it falls back to password authentication. If I disable password authentication on the remote machine my connection attempt just fails with a "Permission denied (publickey)." state.
Same thing for sftp from command line.
The "funny" thing is that the exact same RSA key works like a charm with a Filezilla sftp session instead:
12:08:00 Trace: Offered public key from "/home/user/.filezilla/keys/Ganymede_key"
12:08:00 Trace: Offer of public key accepted, trying to authenticate using it.
12:08:01 Trace: Access granted
12:08:01 Trace: Opened channel for session
12:08:01 Trace: Started a shell/command
12:08:01 Status: Connected to ganymede.server.com
12:08:02 Trace: CSftpControlSocket::ConnectParseResponse()
12:08:02 Trace: CSftpControlSocket::ResetOperation(0)
12:08:02 Trace: CControlSocket::ResetOperation(0)
12:08:02 Status: Retrieving directory listing...
12:08:02 Trace: CSftpControlSocket::SendNextCommand()
12:08:02 Trace: CSftpControlSocket::ChangeDirSend()
12:08:02 Command: pwd
12:08:02 Response: Current directory is: "/root"
12:08:02 Trace: CSftpControlSocket::ResetOperation(0)
12:08:02 Trace: CControlSocket::ResetOperation(0)
12:08:02 Trace: CSftpControlSocket::ParseSubcommandResult(0)
12:08:02 Trace: CSftpControlSocket::ListSubcommandResult()
12:08:02 Trace: CSftpControlSocket::ResetOperation(0)
12:08:02 Trace: CControlSocket::ResetOperation(0)
12:08:02 Status: Directory listing successful
Any thoughts?
M