Willmer, Alex
2020-Dec-01 14:54 UTC
Does order of options matter in authorized_keys? Does it differ by option?
Good morning all, I'm confused about whether the order of options matter, in a single authorized_keys entry. I'm seeing contradictory behaviour, depending on the option. AFAICT the man page does not specify this. As far as I can tell - when restrict & permitlisten are combined order matters, later options override earlier options (i.e. last wins) - when restrict & permitopen are combined order does *not* matter. restrict is always overridden by permitopen. Questions: 1. Is ordering of key options (meant to be) significant? 2. Are there (meant to be) differing precedence rules for permitlisten, and permitopen? Reproduction I created 4 keys $ ssh-keygen -t ed25519 -q -P "" -f ~/.ssh/id_permitlisten_restrict $ ssh-keygen -t ed25519 -q -P "" -f ~/.ssh/id_restrict_permitlisten $ ssh-keygen -t ed25519 -q -P "" -f ~/.ssh/id_permitopen_restrict $ ssh-keygen -t ed25519 -q -P "" -f ~/.ssh/id_restrict_permitopen then added 4 entries to .ssh/authorized_keys on the remote system (OpenSSH 8.3p1, on Ubuntu 20.10, in a docker container) permitlisten="localhost:1234",port-forwarding,restrict ssh-ed25519 AAAAC3Nza...7Ykx restrict,port-forwarding,permitlisten="localhost:1234" ssh-ed25519 AAAAC3Nza...JMvV permitopen="localhost:1234",port-forwarding,restrict ssh-ed25519 AAAAC3Nza...0UbY restrict,port-forwarding,permitopen="localhost:1234" ssh-ed25519 AAAAC3Nza...GHjo then tested them using the commands SSH_OPTS="-F/dev/null -oIdentitiesOnly=yes -oExitOnForwardFailure=yes -N -T" SSH_HOST="test at localhost" SSH_PORT="2222" ssh $SSH_OPTS -p$SSH_PORT $SSH_HOST -i ~/.ssh/id_permitlisten_restrict -R localhost:1234:localhost:1234 ssh $SSH_OPTS -p$SSH_PORT $SSH_HOST -i ~/.ssh/id_restrict_permitlisten -R localhost:1234:localhost:1234 ssh $SSH_OPTS -p$SSH_PORT $SSH_HOST -i ~/.ssh/id_permitopen_restrict -L localhost:1234:localhost:1234 ssh $SSH_OPTS -p$SSH_PORT $SSH_HOST -i ~/.ssh/id_restrict_permitopen -L localhost:1234:localhost:1234 I found that - the 1st (permitlisten, then restrict, attempting remote forward) failed, with "Error: remote port forwarding failed for listen port 1234". - the 2nd (restrict, then permitlisten, attempting remote forward) succeeded - the 3rd (permitopen, then restrict, attempting local forward) succeeded - the 4th (restrict, then permitopen, attempting local forward) succeeded The 1st and 3rd results seem inconsistent. I expected either both to succeed, or both to fail. Did I miss something? With thanks, Alex