Sshr: Proxy server for routing SSH connections(github.com)
github.com
Sshr: Proxy server for routing SSH connections
https://github.com/tsurubee/sshr
5 comments
Interesting solution, I would have assumed most people would choose the ~/.ssh/config + proxyjump feature to solve this vs adding a new tool into the mix. Is the benefit mostly in centralization of the config/routes or am I missing the target usecase?
Thanks for your comment. I am the author of sshr.
The operation using proxyjump and sshr are quite different. As far as I know, even if proxyjump is used, the user must explicitly specify the destination host to be connected finally. On the other hand, the user using sshr does not know the destination host. The host is determined by sshr. (The developer using sshr can freely incorporate own hook functions that dynamically determines the destination host.) Therefore, if the user knows only the IP address or host name of sshr server, the user is transparently connected to the server associated with the username.
Since the behavior is completely different, the use cases are of course different. Sshr is effective when the server administrator wants to manages the association information between the users and the servers in the database or yaml file and so on. The server administrator can freely change the server used by the user without making the user aware of it.
The operation using proxyjump and sshr are quite different. As far as I know, even if proxyjump is used, the user must explicitly specify the destination host to be connected finally. On the other hand, the user using sshr does not know the destination host. The host is determined by sshr. (The developer using sshr can freely incorporate own hook functions that dynamically determines the destination host.) Therefore, if the user knows only the IP address or host name of sshr server, the user is transparently connected to the server associated with the username.
Since the behavior is completely different, the use cases are of course different. Sshr is effective when the server administrator wants to manages the association information between the users and the servers in the database or yaml file and so on. The server administrator can freely change the server used by the user without making the user aware of it.
Let me supplement the above.
The word "user" was used to mean an SSH client.
The word "user" was used to mean an SSH client.
Somewhat similar, depending on what you might want: https://github.com/cea-hpc/sshproxy
Thanks for your comment. I am the author of sshr.
The biggest difference between cea-hpc/sshproxy and sshr is that the developer using sshr can freely incorporate own hook functions that dynamically determines the destination host. Thanks to the hook function, we can manage the information of destination host in the free data format, such as database or yaml file and so on, although sshproxy forces us to manage the information by etcd.
Of course, sshproxy seems to have some great features that sshr doesn't have. Thank you for teaching me a great solution!
The biggest difference between cea-hpc/sshproxy and sshr is that the developer using sshr can freely incorporate own hook functions that dynamically determines the destination host. Thanks to the hook function, we can manage the information of destination host in the free data format, such as database or yaml file and so on, although sshproxy forces us to manage the information by etcd.
Of course, sshproxy seems to have some great features that sshr doesn't have. Thank you for teaching me a great solution!