-
-
Notifications
You must be signed in to change notification settings - Fork 135
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
Comments
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
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)
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.
...
The text was updated successfully, but these errors were encountered: