New Feature Request - Personel Password Manager

[kendinitekmeleyenkedi]

Hi,

A per-user password manager feature can be very useful. Since the current vault feature is used in common, personal user information cannot be noted. In addition to this feature, it would be perfect to be able to access the devices directly by using these personal usernames and passwords in the tunnels made.

Thanks.

[t347s]

Hi, Nice feature request, there also should be a option for an admin to setup a tunnel and a user (with limited privileges) just to use it that credentials which you mentioned.

Thank you!

[thorstenkramm]

In addition to this feature, it would be perfect to be able to access the devices directly by using these personal usernames and passwords in the tunnels made.

@kendinitekmeleyenkedi Almost impossible to achieve. Most remote access solutions, first and foremost SSH and RDP are encrypted. We cannot inject a username or password.

[thorstenkramm]

setup a tunnel and a user (with limited privileges) just to use it that credentials which you mentioned.

@t347s Sorry. I don't get it. You want to set up a tunnel, tie the tunnel to a single user, and this user should be allowed to use the tunnel only with some pre-defined credentials? What kind of remote access do you have in mind? SSH, RDP, VNC?

[t347s]

Hi @thorstenkramm , Something like that, my ideea is to assign a user the possibility to connect to a machine (via SSH, RDP, VNC, depends on necessities) and the user/password combination to be predefined by admin via vault (its allready implemented in rport), so that user will do not know the credentials to connect but will have the tunnel predefined to use it.

To be more simple, when an admin configures a tunnel there should be an option like: "Share this connection with user/group", when select this should be "Please select a group or a user to share this tunnel", then another option who ask "Share the connection with your submited credentials (not visible for the user or group)" or let the user/group to use their own credentials.

Right, this type of tunnel shoul be "permanent", the option "Distroy tunnel after" should be greyed out.

All this combinations of user/pass should be stored in Vault.

All this is tied with another feature, manage group access rights like mentioned here: https://github.com/cloudradar-monitoring/rport/discussions/641

The initial feature request "Personel Password Manager" is here in combination with vault, if the user have it's own credentials then why not store it in vault and used when it creates a tunnel, if he has the rights to do that.

I know, it's a little complex, if is needed i will elaborate as much as possibile.

Thank you for you support!

[thorstenkramm]

@t347s This is basically what https://goteleport.com/ offers. It's very unlikely that we will implement the features requested above.

We are doing "just" tunnels. We bring you to the front door. Having keys is out of our scope. We don't want to integrate with the auth mechanisms of the operating systems. Taking credentials from the vault and injecting them to an RDP or SSH connection is - due to encryption - technically not possible. We would need to hook into PAM on Linux and signal the OS there's a pre-authenticated user coming. But the direct interaction with PAM has a huge security impact on your machines. We don't want to open pandora's box.

Please tell me, what kind of remote access do you have in mind? SSH, RDP, VNC? SSH is very versatile, and some creative workarounds might be possible. RDP via browser has some limited options.

[t347s]

Hi @thorstenkramm , Thank you for your answer. I understand; i tried teleport but it seems like a basic version of rport, i need what rport offers.

Please tell me, what kind of remote access do you have in mind? SSH, RDP, VNC? Answer: SSH

So, what is exactly the role of Vault in rport?

Thank you!

[thorstenkramm]

The vault is an encrypted storage to secure share data on the team. You can store credentials there. But you must use copy and paste to use them on an ssh connection. Handing over a clear text password from the browser to an ssh client securely is not that easy. At the moment, I can't imagine how.

Why don't you use key-based authentication for ssh?

[t347s]

For the moment i use key-based authentication for cloud provider connectivity, for local env not. If i have key-based authentication for SSH how do rport helps me to make my life easy? How do i tie a tunnel to a key?

[thorstenkramm]

You tie the public key to a remote server, not to a tunnel. If you create a tunnel, the key will automatically be applied. This is done by your ssh client, not by Rport. This approach is the cleanest and most secure approach. Applying some kind of access control on tunnel level can easily be leveraged by connecting to the SSH port without the tunnel. You can add a small script to the rport library that adds your public key and the keys of your teammates to the remote servers.

[t347s]

Hi @thorstenkramm , I tested goteleport, in the server part the dev from teleport opted for something interesting, it's based on user ACL, a user to connect to a vm must have the rights to do that and to use a ssh connection the admin must implement a user that is mandatory present on vm. I believe that this type of configuration can be implemented on rport. I excluded other manage sources, like kubernetes or DB...

To be more clear (an imaginary rport configuration like teleport): After install of server client solution, an admin declares the user rights on the rport usage, then creates a connection with a user account that must be present on the target vm. So, without usage of SSH keys or credentials a user from rport can connect on target vm based on the rport server-client security interaction - here i have no knowledge about what happends "behind de screen". The Vault component is not used in this case, no credentials or ssh keys is used.

What do you think, it's a teleport feature that can be implemented in rport?

Thank you!

[thorstenkramm]

@t347s You can start a second SSHD that listens on localhost only, that will authenticate just one user and empty passwords are allowed. The relevant lines on the second sshd_config would be.

Port 2222
ListenAddress 127.0.0.1
AllowUsers rport
PermitEmptyPasswords yes

Change the shell of the rport user to /bin/bash using chsh -s /bin/bash rport. Set an empty password for the user. mkpasswd -s </dev/null and enter the generated hash to /etc/shadow manually.

Once the second SSHD is started, you can create a tunnel to the device and log in using the user rport without a password.

There is a security drawback. Any user on this machine can change to the rport user without a password.

[sempervictus]

As an extension of the "don't implement your own cryptography even if you're a cryptographer" principle, i would suggest considering credential management from the same perspective. There is a fair number of existing vault solutions with programmatic access permitting prescriptive integration and subsequent offload of segmentation, management, and actual credential access to dedicated systems. Many of these things have been audited (see BitWarden/VaultWarden/Hashi's stuff) and continue to be due to their use in enterprise to provide a relative quotient of safety. Concurrently, as someone who's job often entails acquisition of credentials from systems (3 decades of offsec practice, and counting), i would suggest not keeping all of your eggs in one basket because you'd either have to spend considerable resources in perpetuity in the security audit and improvement cycle of that specific feature (and audit of all dependencies, codepaths, etc around that) or eventually end up compromised by someone figuring out a side-channel or actual access path to the contents of memory regions holding those secrets - being a pass-thru proxy for materiel encrypted to the end-user's session is the most safe posture in terms of critical data handling. I'm not big on Golang but pretty sure i've come across some libraries designed to make handling the cleartext output from back-end vault providers "safer" for the brief period before they can be encrypted and passed to the browser session for decryption (making safety the user's responsibility more than the server's).

[bloesss]

We also need another field. I just have "Name" and "Key". But I don't know where its for. So we use "router:radmin" for Name. And cannot copy this directly inside the web interface.

Another missing feature is a password audit. Showing or copying a password must have an audit entry.

[thorstenkramm]

@bloesss The issue you are posting to is not a generic wish list. It's just about “Personal Password Manager”. Your two requests are not related. I kindly ask you to remove your comment and create two new topics on the wish list here