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

SSHPortal accepts the first key, then disconnects, even if there are multiple in ssh-agent. #453

Open
systemmonkey42 opened this issue Feb 15, 2023 · 0 comments

Comments

@systemmonkey42
Copy link

systemmonkey42 commented Feb 15, 2023

Actual Result / Problem

sshportal always accepts the first key provided, without first checking if it is valid for a user.
sshportal always accepts the first key provided, without first checking if the target host is valid for the owner of that key.

I use ssh-agent with multiple keys (production hosts, dev hosts, multiple github accounts, etc)

When I attempt to SSH to sshportal it always accepts the first key unconditionally, making it difficult to ensure it authenticates correctly when I want to connect to a production host, vs development host or even admin console.

A normal SSH server simply rejects keys it is not interested in, and accepts keys that work.

Once sshportal has accepted the connection, it then provides verbose error messages which may give hope to hackers.

By default sshportal supports a useless implementation of password authentication. This must be disabled to deter hackers from even trying.

Expected Result / Suggestion

The ssh public key handling should detect if the key does not provide the user access to what they want (ie admin console, or the selected host), and return "FALSE", allowing the SSH client to try the next key.

Ensure the ssh client is disconnected with a standard authentication error, rather than accepting the connection and returning verbose message which may leak private information.

Some context

Fixed in fork (https://github.com/systemmonkey42/sshportal)

  • Reject unknown key, so ssh client tries next key automatically
  • Reject KNOWN key, if the requested bastion host is not accessible to that user, so ssh client tries next key.
  • Disable PASSWORD authentication COMPLETELY to ensure hackers stop trying sooner (this is a publicly facing service)
  • Ensure the remote user gets a standard "permission denied (publickey)" message, instead of custom messages which may leak information.
  • Eliminate the magic username "admin" which allowed users to authenticate with any valid key, and get an admin console even if they did not have admin access. You must now use a valid username/publickey combination to get console access (even if you don't have admin)

Note the sshportal banner still indicates that it is a custom ssh server, however removing the git tag makes it more difficult to locate the exact version and exploit vulnerabilities.

...

libvoid pushed a commit to alterway/sshportal that referenced this issue May 31, 2023
libvoid pushed a commit to alterway/sshportal that referenced this issue May 31, 2023
Needed to reject known key if the requested bastion host is not accessible to that user, so ssh client tries next key.
See moul#453
libvoid pushed a commit to alterway/sshportal that referenced this issue Jun 5, 2023
libvoid pushed a commit to alterway/sshportal that referenced this issue Jun 5, 2023
Needed to reject known key if the requested bastion host is not accessible to that user, so ssh client tries next key.
See moul#453
libvoid pushed a commit to alterway/sshportal that referenced this issue Jun 5, 2023
libvoid pushed a commit to alterway/sshportal that referenced this issue Jun 5, 2023
Needed to reject known key if the requested bastion host is not accessible to that user, so ssh client tries next key.
See moul#453
libvoid pushed a commit to alterway/sshportal that referenced this issue Jun 6, 2023
libvoid pushed a commit to alterway/sshportal that referenced this issue Jun 6, 2023
Needed to reject known key if the requested bastion host is not accessible to that user, so ssh client tries next key.
See moul#453
libvoid pushed a commit to alterway/sshportal that referenced this issue Jul 13, 2023
libvoid pushed a commit to alterway/sshportal that referenced this issue Jul 13, 2023
Needed to reject known key if the requested bastion host is not accessible to that user, so ssh client tries next key.
See moul#453
libvoid pushed a commit to alterway/sshportal that referenced this issue Jul 13, 2023
libvoid pushed a commit to alterway/sshportal that referenced this issue Jul 13, 2023
Needed to reject known key if the requested bastion host is not accessible to that user, so ssh client tries next key.
See moul#453
libvoid pushed a commit to alterway/sshportal that referenced this issue Jul 17, 2023
libvoid pushed a commit to alterway/sshportal that referenced this issue Jul 17, 2023
Needed to reject known key if the requested bastion host is not accessible to that user, so ssh client tries next key.
See moul#453
libvoid pushed a commit to alterway/sshportal that referenced this issue Jul 17, 2023
libvoid pushed a commit to alterway/sshportal that referenced this issue Jul 17, 2023
Needed to reject known key if the requested bastion host is not accessible to that user, so ssh client tries next key.
See moul#453
libvoid pushed a commit to alterway/sshportal that referenced this issue Jul 17, 2023
libvoid pushed a commit to alterway/sshportal that referenced this issue Jul 17, 2023
Needed to reject known key if the requested bastion host is not accessible to that user, so ssh client tries next key.
See moul#453
libvoid pushed a commit to alterway/sshportal that referenced this issue Jul 17, 2023
libvoid pushed a commit to alterway/sshportal that referenced this issue Jul 17, 2023
Needed to reject known key if the requested bastion host is not accessible to that user, so ssh client tries next key.
See moul#453
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

No branches or pull requests

1 participant