The setup instructions here (https://developers.cloudflare.com/cloudflare-one/identity/users/short-lived-certificates/#2-ensure-unix-usernames-match-user-sso-identities) are not working for my cloudflared deployment.
I have, in my /etc/ssh/sshd_config:
Match user pi
AuthorizedPrincipalsCommand echo 'andrew'
AuthorizedPrincipalsCommandUser nobody
and in the policy of my Zero Trust SSH application: Require Email “[email protected]”. This should let user [email protected] log in as Unix user pi.
When trying to access the terminal through the browser, I am not logged in as the pi user, but instead as the andrew user.
The document has been updated with new AuthorizedPrincipalsCommand instructions so that the “absolute path” error does not occur. Now connecting from a standard SSH client (vs browser based terminal) works with Authorized principals.
@carride, the updated AuthorizedPrincipalsCommand does not resolve my issue, which is different from what @Bartje describes. There is no error message - logging on as a user other than the email prefix (user andrew in [email protected]) simply does not work.
Have you tried from Cloudflare’s browser rendered terminal, and also thru a ssh client where you have installed and configured cloudflared in ssh_config to send short lived certificates? In GitHub issues they report that browser rendered terminal does not currently work with the differing usernames instructions.
When trying to connect as user pi from my terminal, I get an error [email protected]: Permission denied (publickey). The sshd log file on the RaspberryPi reads: Feb 19 07:34:34 Raspberry sshd[29486]: Connection closed by authenticating user pi ::1 port 46182 [preauth].
Are you referring to any GitHub issues other than this one https://github.com/cloudflare/cloudflared/issues/874? That’s the one I opened - unfortunately, no input from the Cloudflare team as of yet.
If the browser failed to open, please visit the URL above directly in your browser.
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9p1 Raspbian-10+deb10u2+rpt1
debug1: compat_banner: match: OpenSSH_7.9p1 Raspbian-10+deb10u2+rpt1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to ssh.mydomain.com:22 as 'pi'
debug1: load_hostkeys: fopen /Users/myusername/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:s+6JlHlnWh7YqgyOu5bV1PX5SilGjeuIb78u0TRwnvU
debug1: load_hostkeys: fopen /Users/myusername/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host 'ssh.mydomain.com' is known and matches the ED25519 host key.
debug1: Found key in /Users/myusername/.ssh/known_hosts:16
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: get_agent_identities: bound agent to hostkey
debug1: get_agent_identities: ssh_fetch_identitylist: agent contains no identities
debug1: Will attempt key: /Users/myusername/.ssh/id_rsa
debug1: Will attempt key: /Users/myusername/.ssh/id_ecdsa
debug1: Will attempt key: /Users/myusername/.ssh/id_ecdsa_sk
debug1: Will attempt key: /Users/myusername/.ssh/id_ed25519
debug1: Will attempt key: /Users/myusername/.ssh/id_ed25519_sk
debug1: Will attempt key: /Users/myusername/.ssh/id_xmss
debug1: Will attempt key: /Users/myusername/.ssh/id_dsa
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/myusername/.ssh/id_rsa
debug1: Trying private key: /Users/myusername/.ssh/id_ecdsa
debug1: Trying private key: /Users/myusername/.ssh/id_ecdsa_sk
debug1: Trying private key: /Users/myusername/.ssh/id_ed25519
debug1: Trying private key: /Users/myusername/.ssh/id_ed25519_sk
debug1: Trying private key: /Users/myusername/.ssh/id_xmss
debug1: Trying private key: /Users/myusername/.ssh/id_dsa
debug1: No more authentication methods to try.
In this cloudflared docs github issue, there is a comment that the browser rendered terminal does not currently work with short-lived certs
–
Your client SSH log does not show sending the cloudflared short-lived certificate. So I suspect you have not completed that setup at step 7
This command will create a .cloudflared directory in your home directory, and will output the ssh_config fragment you must insert into your ~/.ssh/config file or create a unique e.g. cf-config.txt to use with the -F parameter when running ssh client e.g. ssh user@tunnelhost -F cf-config.txt
This is example of output by above cloudflared command. Every time you run the ssh client to this host a certificate is created which will expire in a few minutes. You can see these certs in the ~/.cloudflared directory after you run ssh
my client log showing use of the .cloudflared short lived cert
debug1: Offering public key: /Users/username/.cloudflared/hostname.com-cf_key-cert.pub ECDSA-CERT SHA256:.... explicit
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: /Users/username/.cloudflared/hostname.com-cf_key-cert.pub ECDSA-CERT SHA256:.... explicit
Many thanks, it does seems that this particular setup step had not been correctly implemented. Accessing with a differing username via the terminal now works. As you pointed out, the same functionality is currently broken for the browser-based terminal.