Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

upterm host should reject any unauthenticated users when --authorized-key, --github-user or --gitlab-user option is present #119

Open
lhotari opened this issue Mar 24, 2022 · 1 comment · May be fixed by #232

Comments

@lhotari
Copy link

lhotari commented Mar 24, 2022

Problem:
I ran into an issue where I had a passed an empty file to --authorized-key option for the upterm host command.

Steps to reproduce

  1. Start a new upterm host session in a docker container:
# start a new ubuntu docker container
docker run --rm -it ubuntu:20.04 bash
# in the container run these commands to start upterm
apt-get update
DEBIAN_FRONTEND=noninteractive apt-get -y install --no-install-recommends curl openssh-client ca-certificates
curl -sL https://github.com/owenthereal/upterm/releases/download/v0.7.6/upterm_linux_amd64.tar.gz | \
  tar zxvf - -C /tmp upterm && \
  install /tmp/upterm /usr/local/bin/ && rm -rf /tmp/upterm
mkdir -p ~/.ssh && chmod 0700 ~/.ssh
ssh-keygen -q -t ed25519 -N "" -f ~/.ssh/id_ed25519
# Auto-generate ~/.ssh/known_hosts by attempting connection to uptermd.upterm.dev
ssh -i ~/.ssh/id_ed25519 -o 'StrictHostKeyChecking no' uptermd.upterm.dev
cat <(cat ~/.ssh/known_hosts | awk '{ print "@cert-authority * " $2 " " $3 }' | sort | uniq) >> ~/.ssh/known_hosts
touch ~/.ssh/authorized_keys
upterm host -a $HOME/.ssh/authorized_keys -- bash
  1. Use the SSH session string in another terminal. The client connects to the upterm session. This is unexpected since -a $HOME/.ssh/authorized_keys is passed to upterm host.

Expected behavior

upterm host should reject any unauthenticated users when --authorized-key, --github-user or --gitlab-user option is present.
An empty authorized keys file shouldn't be an exception.

@bavarianbidi
Copy link
Contributor

👍 from my side.
we've run into the same issue and we are first wondering why we are still able to login.

IMHO we could fail if one of the flags are defined and if len(authorizedKeys) > 0.

h := &host.Host{
Host: flagServer,
Command: args,
ForceCommand: forceCommand,
Signers: signers,
HostKeyCallback: hkcb,
AuthorizedKeys: authorizedKeys,
KeepAliveDuration: 50 * time.Second, // nlb is 350 sec & heroku router is 55 sec
SessionCreatedCallback: displaySessionCallback,
ClientJoinedCallback: clientJoinedCallback,
ClientLeftCallback: clientLeftCallback,
Stdin: os.Stdin,
Stdout: os.Stdout,
Logger: logger,
ReadOnly: flagReadOnly,
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants