7 ms·

Sshmuxd: SSH proxy to replace jump hosts

108 points by Spiritus 11y ago

zobzu 11y ago
Its nice.. That said, one if the real issue is getting people to use -W ;)
- dijit 11y ago
  I'm looking at the man page, I had no idea about `-W`. However, what does this protect against that the standard: ProxyCommand ssh -q <jumpHost> nc %h 22 doesn't protect? Edit: just tried `-W` as an addition to the line but I get littlefish :: ~ » ssh pgsql3 Bad stdio forwarding specification '<jumpHost>' ssh_exchange_identification: Connection closed by remote host
  - joushou 11y ago
    sshmux gives fine-grained user controls. In the normal jumphost example, you can use ssh -W to connect to arbitrary ports and hosts on the network, poking around where you weren't intended (ssh -W is just netcat where the ssh server initiates the connection for you). With sshmux, ssh -W will only work to hosts permitted for that user, and any other request will just fail.
  - keeperofdakeys 11y ago
    Try formatting it like this: ProxyCommand ssh jumpHost -W %h:%p -W is essentially the same as using nc, however it doesn't require executing a command on the jumphost. This project uses that fact to make the jumphost more secure (you can't execute arbitrary commands), and do destination white-listing for each user.
  - zobzu 11y ago
    -W is just a nicer wait of doing your nc command
- joushou 11y ago
  That's true. Some people complained that this isn't documented enough, so there is a wiki page for sshmuxd explaining what it does. Agent forwarding with sshmux should be safer than the general case, though, as the agent is handled in memory, rather than as a socket. The agent is also not forwarded to the destination.
- ryan-c 11y ago
  https://github.com/ryancdotorg/ssh-chain https://github.com/ryancdotorg/ssh-chain should just work with this.
daurnimator 11y ago
> sshmux, and by extension, sshmuxd, can only forward normal sessions (ssh'ing directly to sshmuxd without a ProxyCommand) if agent forwarding is enabled. This is very dangerous. With the average setup, anyone with root access on the middle box can borrow the ssh key of any user connecting through it. See http://unixwiz.net/techtips/ssh-agent-forwarding.html#sec http://unixwiz.net/techtips/ssh-agent-forwarding.html#sec for more info.
- hlieberman 11y ago
  Considering this seems intended for use in somewhat corporate situations, it may or may not be that serious of a problem. This is yet another situation where Kerberos got it right years and years ago, but is almost impossible to actually /use/ even now after n years.
  - beagle3 11y ago
    Could you give a quick summary (or a link) about how Kerberos works in this respect ?
  - joushou 11y ago
    Exactly. And yes, Kerberos got it somewhat right, but as someone who have used configured and used it, it is quite the exercise to set up. It took ages to get working, and even then, it was slightly cumbersome to use.
    - cpach 11y ago
      "It took ages to get working, and even then, it was slightly cumbersome to use." I've wondered from time to time why Kerberos more or less faded into obscurity. I guess we have the answer then.
  - asdfaoeu 11y ago
    Kerberos is just as open as ssh-agents. The middle server is still able to impersonate you.
Galanwe 11y ago
I don't really understand what this is supposed to be useful for. Relying on a random software to secure your ssh entry point, instead of a proper linux configuration, that seems like a risky tradeoff.
- joushou 11y ago
  I'm the author of the project. The project is meant to ensure that you can allow multiple users access through a jump-host style mechanism, while not permitting any other "abuse" of the jump host. You can lock down SSH a lot, but not as much as sshmux does. Security wise, the code is very, very simple and easy to follow, and even if it went rogue, that's no different than the trust you put in your usual SSH server. If this is a concern, do not use the agent forwarding mode, which would render a rogue server a pointless and unfruitful prank. If you use the ProxyCommand mode, the only thing an "evil" sshmux would be able to do would be to break the connection. It won't be able to fake the endpoint if it is already in your known_hosts, as it does not have the real endpoints private host key. It is, therefore, secure in this mode.
erikb 11y ago
Why not simply configure your ssh correctly?
- guipsp 11y ago
  Jump hosts exist for a purpose.
  - erikb 11y ago
    Yes, and there is a way to configure your client to use one.
    - joushou 11y ago
      sshmux is a jump host that allows more user-control than you can with a ssh server. Unless you use the interactive mode with agent forward, you still need to configure your client to use one. I'm not sure I get what you're on about, to be honest. :/
tokenizerrr 11y ago
Does this support SFTP? What about for windows users that use FileZilla and don't have an .ssh/config?
- joushou 11y ago
  SFTP/SCP works if you use the ProxyCommand, or agent forwarding. Clients such as WinSCP support agent forwarding, at least. Not sure about FileZilla. I'm not a Windows user, so can't say. :/
  - tokenizerrr 11y ago
    I know FileZilla also supports agent forwarding, but I'm not entirely sure how this would work in practise. If I'm understanding things right you can have a single jumphost and give a user access to multiple targets. So when the user connects to the jumphost using SFTP then what files/directories do they see? Maybe I should just install and try this for myself...
    - joushou 11y ago
      Interactive selection for agent-forwarding only works for regular SSH, not sftp, due to having no way to enter input. If I get around to it, one could wrap sftp completely, so that the available servers simply show up as root-level directories. EDIT: Opened an issue about it.
      - tokenizerrr 11y ago
        > If I get around to it, one could wrap sftp completely, so that the available servers simply show up as root-level directories. That wound be amazing! I'll see if I can check if ProxyCommand is doable with FileZilla later as well.
wila 11y ago
Looked at the code, it is nice and short. However I'm not that familiar with go so might be overlooking something. Is there any logging included on who connected at what time from what IP?
- joushou 11y ago
  Not at the current time. Will implement, just haven't had the time. I mainly code on this during my daily commute between Denmark and Sweden. :)
  - tinco 11y ago
    You live in Copenhagen and work in Malmo or something? Is that common?
    - joushou 11y ago
      Landskrona, actually. Malmö would have been nicer, but the waiting list for an apartment is 2-3 years. It's actually quite common, especially in Malmö (Malmö<->Copenhagen takes about half an hour, Landskrona<->Copenhagen 1:20), for a lot of reasons. The first being that living expenses, including rent and household items, are cheaper in Sweden. Local wages are always adjusted after the local living expenses, so living in Sweden while working in Denmark is economically favorable, especially seeing that you get a tax deduction bonus based on distance from home to work through the shortest feasible route. Cars are also orders of magnitude cheaper in Sweden due to different taxing. Not everything is cheaper or better there, though. Diesel and alcohol is more expensive, and my selection of rye bread is much narrower up there! For me, it's due to me wanting to start a life with my wife, and a lot private things going on that made Sweden the obvious choice.
james_woods 11y ago
Why not simply use a VPN?
- joushou 11y ago
  VPN's can be quite a pain, and is considerably more work than raw SSH. Depending on the VPN, the authentication strength is usually also quite a bit lower than that of SSH with RSA keys. There's also additional overhead. I have both VPN and jump hosts to get into our corporate network, and I most certainly prefer the jump host for convenience and performance. There is also the user-level access restrictions of sshmux which will be much more difficult to replicate with VPN's. At least with pptpd, I believe it would require putting users on individual subnets with firewall rules restricting access to only their permitted hosts. Long story short, it wouldn't be a feasible solution.
VLM 11y ago
Probably 15 years ago I did something similar at an overall system level with a program called pdmenu which provided a jump host menu for semi-technical users. The technical details of course are entirely different, but it did the same general system idea of presenting individual users with custom tailored prompts to log into various systems (and a few other tasks, and logging, etc). pdmenu had (has?) a great menu CLI for end users.
jamiesonbecker 11y ago
Jumpboxes aren't that bad to automate, actually. We already help with automating jumpbox creation. (docs: https://userify.com/docs/tips/jumpbox/ https://userify.com/docs/tips/jumpbox/) and we're building even more jumpbox automation now. Don't allow root for any jumpbox accounts, but of course root escalation exploits abound. (I just found another in an AWS agent yesterday.) Of course, as another commenter mentioned, if your jumpbox is compromised, than the jumpbox could serve as a gateway to your network. It's a tradeoff between exposing all of your servers to inbound SSH or only one. There's another way, which is pure TCP forwarding on a different port for each server (ie 21321 -> inner server 22), but whether this actually reduces the attack surface is debatable, since the totality of open ports remains the same across the entire network. My personal feeling is that using a jumpbox and locking it down (preferably to your company's IP ranges, etc) is the best way to go. You can also add MFA to the jumpbox entry point itself. We're going to help with automating all of that in the near future, too. (disclaimer: CTO @Userify)
- joushou 11y ago
  Hi CTO for Userify person! One thing is setup of jump hosts (basic version just being a box with sshd enabled + users with authorized_keys, which is beyond simple), but it's the limitation of hosts. I have 1 big network where a set of users are only allowed to jump to 1 or more unique host each, with myself and a few others being able to jump to every single one. I believe that your solution requires things to be on different subnets to isolate them, with separate jump hosts for each subnet, correct? Here, I only need one sshmux for everyone. Another "fun" feature is that sshmux can also throw unknown users to a separate host, such as ssh-chat, for support or hanging out. Actually, in case of -oProxyCommand="ssh -W %h:%p jump_host", you're still fully secure in the case that the jump host (sorry for not calling it a jumpbox) is compromised. This is true both for normal SSH servers and for sshmux. They can mess with the original raw ssh connection that requests the forward, but this will just screw the connection up. They can connect it to a wrong host, but that will provide incorrect host keys. The agent isn't forwarded, so they don't get to sign anything with the private key. Messing with the new connection that gets established is subject to SSH's normal MITM resistance. This means that even root on the jump host would require real SSH protocol vulnerabilities to attack the connection. Good luck with Userify!
zippie 11y ago
This is nice but the agent forwarding is a legitimate concern especially because a compromised host can take off with the private keys which are used while beginning the session. Most private keys are used for more than connecting to a single host. In our setup we use jailkit allowing only ssh passthrough [1], we have added LDAP support to it (may release the patch later). [1] http://olivier.sessink.nl/jailkit/howtos_ssh_only.html http://olivier.sessink.nl/jailkit/howtos_ssh_only.html
- joushou 11y ago
  What authentication do you have from the jump host to the target? To me, it looks like it has been reduced to either none or keyboard-interactive (password) login, which is considered bad practice. I could very easily implement support for this in sshmux, providing the setup you seem to use, as a way to avoid agent forwarding, but I just genuinely did not expect anyone to use password authentication, apart from in default config scenarios, before a public key has been installed. Agent forwarding does not provide private keys, but only individual signing requests. This means that while the user is connected, and evil remote can request arbitrary signing, but only as long as the user is connected, and only as long as the users ssh agent is willing to do so. Using ssh-add -c further means that the user will have to accept each signing request. Also note that ssh -W, which is immune to any of these concerns, is fully supported by sshmux. Correct me if I'm wrong, but "Jailkit" does not seem to stop an evil legitimate user from poking around other hosts with forwarding and such (which they can as long as ssh -W functions, within the limits of what a firewall allows the jump host to do in general). sshmux allows you to lock users to targets, rather than lock general capabilities of the entire jump host. This is because, while I provide clients access to various hosts, I do not trust them enough to have any unnecessary privileges.
thomashabets2 11y ago
https://blog.habets.se/2014/06/Another-way-to-protect-your-SSH-keys https://blog.habets.se/2014/06/Another-way-to-protect-your-S... Seems like the same thing. Even written in go, too.
- joushou 11y ago
  I see why you might think that, but no. SSHProxy tries to move the private key from your computer to an external thing. SSHProxy doesn't have anything to do with sshmux. SSHProxy is a two part thing: 1. A server that, when connected to, will ssh to the requested host, but authenticate with a local private key. 2. A client that will, when connected to the server, work like netcat for ProxyCommand purposes. I'm skipping some info about additional SSH sessions being involved, as they don't provide any additional security. The result is essentially ProxyCommand="ssh -W %h:%p jump_host", but instead of you having the private key, the jump_host has it. You then use a different private key to authenticate to the jump host. I get the idea, and I by no means say he shouldn't have implemented it, but this provides no additional security what so ever. It just moves your private key from one machine to another. I hope he had fun implementing it, though! If you don't implement what might be a bad idea, you'll never get around to the good ones. Plus, bad ideas can be fun, even if they remain bad when done.
  - thomashabets2 11y ago
    Ah yes, on closer inspection on a non-phone they are quite different. You are just wrong on the no additional security though. In addition to enabling auditing, it also allows a username/password to be turned into an ssh key, so that you can know that if the rpi wasn't turned on, then nobody could log in to the target machine. It's similar to a TPM in this regard (as blog says), or can be a jumpgate protecting the systems behind it from compromised or malicious users. I'm sorry you don't get it, but I'm not hurt by someone not understanding something when they criticize it. If you don't see the point of not having direct access to your key, then there's nothing I can do.
    - joushou 11y ago
j_s 11y ago
I've used a similar setup to wrap RDP to allow employees to securely remotely access their office desktop. There is a market for someone willing to make this a turn-key replacement for Terminal Services.
Daviey 11y ago
Increasingly I am using sshuttle[0] to solve this problem. When you have lots of machines, ProxyCommand'ing always feels like such a burden. [0] https://github.com/apenwarr/sshuttle https://github.com/apenwarr/sshuttle
- joushou 11y ago
  When I use SSH as VPN, it's usually because I want less flexible applications to use it, using socks5 configured as a system-level proxy. When doing more work on our corporate network, I usually SSH through the jump to my desktop and work from there, unless I specifically need to access another machine for something. As for sshuttle, it's a very convenient device, although the design appears rather complicated. I'll look into it.
  - beagle3 11y ago
    The design is possibly the simplest for what it does (and it does that exceedingly well). sshuttle is: - a tcp multiplexer (multiple connections onto one stream) - a router (uses firewall rules to make normal connections go through the multiplexer) - a few kludgy tunneling operations, to make the combination above seem like a real VPN (discovery of remote subnets, tunneling of DNS requests, ....) - a default setup that runs the multiplexed stream through an ssh connection, thereby giving all the security guarantees that ssh provides (integrity, confidentiality, mitm resistance) - packaged in such a way that the remote side needs to have a minimal python>2.6 install, and a user capable of making tcp connections. Nothing more. In my experience, it works way better than IPSEC tunnels and some commercial VPNs that I've used. With two caveats that I'm ok with with: a) only TCP, and b) all connections seem to come from your remote ssh server. No VPN solution that I'm aware of makes so few demands; do you know of one that doesn't require root at the remote server?
    - joushou 11y ago
      ssh -D (socks5 mode) doesn't require root, and can forward both udp and tcp traffic, doing what it appears that the client requires. socks5 is just a protocol that tells the server to connect to X on port Y using protocol Z, or to bind to X on port Y using protocol Z. Root is only required if you want to bind to privileged ports. A bonus with this is that it only requires a SSH server in default configuration. SOCKS5 most common usage is to just use it as a proxy for HTTP traffic or similar, but it can make any connection. The trick lies in the "kludgy tunnelling operations" and the "router" (firewall rules).It's this magic that makes it better than the socks5 proxy solution, as it really does appear like a VPN. I wonder how much effort it would be to get rid of some of the "magic", though. But I have to agree, that ANYTHING is better than a real VPN in complexity.

108 points by Spiritus 11y ago

zobzu 11y ago

Its nice.. That said, one if the real issue is getting people to use -W ;)

dijit 11y ago
I'm looking at the man page, I had no idea about `-W`. However, what does this protect against that the standard: ProxyCommand ssh -q <jumpHost> nc %h 22 doesn't protect? Edit: just tried `-W` as an addition to the line but I get littlefish :: ~ » ssh pgsql3 Bad stdio forwarding specification '<jumpHost>' ssh_exchange_identification: Connection closed by remote host
- joushou 11y ago
  sshmux gives fine-grained user controls. In the normal jumphost example, you can use ssh -W to connect to arbitrary ports and hosts on the network, poking around where you weren't intended (ssh -W is just netcat where the ssh server initiates the connection for you). With sshmux, ssh -W will only work to hosts permitted for that user, and any other request will just fail.
- keeperofdakeys 11y ago
  Try formatting it like this: ProxyCommand ssh jumpHost -W %h:%p -W is essentially the same as using nc, however it doesn't require executing a command on the jumphost. This project uses that fact to make the jumphost more secure (you can't execute arbitrary commands), and do destination white-listing for each user.
- zobzu 11y ago
  -W is just a nicer wait of doing your nc command
joushou 11y ago
That's true. Some people complained that this isn't documented enough, so there is a wiki page for sshmuxd explaining what it does. Agent forwarding with sshmux should be safer than the general case, though, as the agent is handled in memory, rather than as a socket. The agent is also not forwarded to the destination.
ryan-c 11y ago
https://github.com/ryancdotorg/ssh-chain https://github.com/ryancdotorg/ssh-chain should just work with this.

daurnimator 11y ago

> sshmux, and by extension, sshmuxd, can only forward normal sessions (ssh'ing directly to sshmuxd without a ProxyCommand) if agent forwarding is enabled. This is very dangerous. With the average setup, anyone with root access on the middle box can borrow the ssh key of any user connecting through it. See http://unixwiz.net/techtips/ssh-agent-forwarding.html#sec http://unixwiz.net/techtips/ssh-agent-forwarding.html#sec for more info.

hlieberman 11y ago
Considering this seems intended for use in somewhat corporate situations, it may or may not be that serious of a problem. This is yet another situation where Kerberos got it right years and years ago, but is almost impossible to actually /use/ even now after n years.
- beagle3 11y ago
  Could you give a quick summary (or a link) about how Kerberos works in this respect ?
- joushou 11y ago
  Exactly. And yes, Kerberos got it somewhat right, but as someone who have used configured and used it, it is quite the exercise to set up. It took ages to get working, and even then, it was slightly cumbersome to use.
  - cpach 11y ago
    "It took ages to get working, and even then, it was slightly cumbersome to use." I've wondered from time to time why Kerberos more or less faded into obscurity. I guess we have the answer then.
- asdfaoeu 11y ago
  Kerberos is just as open as ssh-agents. The middle server is still able to impersonate you.

Galanwe 11y ago

I don't really understand what this is supposed to be useful for. Relying on a random software to secure your ssh entry point, instead of a proper linux configuration, that seems like a risky tradeoff.

joushou 11y ago
I'm the author of the project. The project is meant to ensure that you can allow multiple users access through a jump-host style mechanism, while not permitting any other "abuse" of the jump host. You can lock down SSH a lot, but not as much as sshmux does. Security wise, the code is very, very simple and easy to follow, and even if it went rogue, that's no different than the trust you put in your usual SSH server. If this is a concern, do not use the agent forwarding mode, which would render a rogue server a pointless and unfruitful prank. If you use the ProxyCommand mode, the only thing an "evil" sshmux would be able to do would be to break the connection. It won't be able to fake the endpoint if it is already in your known_hosts, as it does not have the real endpoints private host key. It is, therefore, secure in this mode.

erikb 11y ago

Why not simply configure your ssh correctly?

guipsp 11y ago
Jump hosts exist for a purpose.
- erikb 11y ago
  Yes, and there is a way to configure your client to use one.
  - joushou 11y ago
    sshmux is a jump host that allows more user-control than you can with a ssh server. Unless you use the interactive mode with agent forward, you still need to configure your client to use one. I'm not sure I get what you're on about, to be honest. :/

tokenizerrr 11y ago

Does this support SFTP? What about for windows users that use FileZilla and don't have an .ssh/config?

joushou 11y ago
SFTP/SCP works if you use the ProxyCommand, or agent forwarding. Clients such as WinSCP support agent forwarding, at least. Not sure about FileZilla. I'm not a Windows user, so can't say. :/
- tokenizerrr 11y ago
  I know FileZilla also supports agent forwarding, but I'm not entirely sure how this would work in practise. If I'm understanding things right you can have a single jumphost and give a user access to multiple targets. So when the user connects to the jumphost using SFTP then what files/directories do they see? Maybe I should just install and try this for myself...
  - joushou 11y ago
    Interactive selection for agent-forwarding only works for regular SSH, not sftp, due to having no way to enter input. If I get around to it, one could wrap sftp completely, so that the available servers simply show up as root-level directories. EDIT: Opened an issue about it.
    - tokenizerrr 11y ago
      > If I get around to it, one could wrap sftp completely, so that the available servers simply show up as root-level directories. That wound be amazing! I'll see if I can check if ProxyCommand is doable with FileZilla later as well.

wila 11y ago

Looked at the code, it is nice and short. However I'm not that familiar with go so might be overlooking something. Is there any logging included on who connected at what time from what IP?

joushou 11y ago
Not at the current time. Will implement, just haven't had the time. I mainly code on this during my daily commute between Denmark and Sweden. :)
- tinco 11y ago
  You live in Copenhagen and work in Malmo or something? Is that common?
  - joushou 11y ago
    Landskrona, actually. Malmö would have been nicer, but the waiting list for an apartment is 2-3 years. It's actually quite common, especially in Malmö (Malmö<->Copenhagen takes about half an hour, Landskrona<->Copenhagen 1:20), for a lot of reasons. The first being that living expenses, including rent and household items, are cheaper in Sweden. Local wages are always adjusted after the local living expenses, so living in Sweden while working in Denmark is economically favorable, especially seeing that you get a tax deduction bonus based on distance from home to work through the shortest feasible route. Cars are also orders of magnitude cheaper in Sweden due to different taxing. Not everything is cheaper or better there, though. Diesel and alcohol is more expensive, and my selection of rye bread is much narrower up there! For me, it's due to me wanting to start a life with my wife, and a lot private things going on that made Sweden the obvious choice.

james_woods 11y ago

Why not simply use a VPN?

joushou 11y ago
VPN's can be quite a pain, and is considerably more work than raw SSH. Depending on the VPN, the authentication strength is usually also quite a bit lower than that of SSH with RSA keys. There's also additional overhead. I have both VPN and jump hosts to get into our corporate network, and I most certainly prefer the jump host for convenience and performance. There is also the user-level access restrictions of sshmux which will be much more difficult to replicate with VPN's. At least with pptpd, I believe it would require putting users on individual subnets with firewall rules restricting access to only their permitted hosts. Long story short, it wouldn't be a feasible solution.

VLM 11y ago

Probably 15 years ago I did something similar at an overall system level with a program called pdmenu which provided a jump host menu for semi-technical users. The technical details of course are entirely different, but it did the same general system idea of presenting individual users with custom tailored prompts to log into various systems (and a few other tasks, and logging, etc). pdmenu had (has?) a great menu CLI for end users.

jamiesonbecker 11y ago

Jumpboxes aren't that bad to automate, actually. We already help with automating jumpbox creation. (docs: https://userify.com/docs/tips/jumpbox/ https://userify.com/docs/tips/jumpbox/) and we're building even more jumpbox automation now. Don't allow root for any jumpbox accounts, but of course root escalation exploits abound. (I just found another in an AWS agent yesterday.) Of course, as another commenter mentioned, if your jumpbox is compromised, than the jumpbox could serve as a gateway to your network. It's a tradeoff between exposing all of your servers to inbound SSH or only one. There's another way, which is pure TCP forwarding on a different port for each server (ie 21321 -> inner server 22), but whether this actually reduces the attack surface is debatable, since the totality of open ports remains the same across the entire network. My personal feeling is that using a jumpbox and locking it down (preferably to your company's IP ranges, etc) is the best way to go. You can also add MFA to the jumpbox entry point itself. We're going to help with automating all of that in the near future, too. (disclaimer: CTO @Userify)

joushou 11y ago
Hi CTO for Userify person! One thing is setup of jump hosts (basic version just being a box with sshd enabled + users with authorized_keys, which is beyond simple), but it's the limitation of hosts. I have 1 big network where a set of users are only allowed to jump to 1 or more unique host each, with myself and a few others being able to jump to every single one. I believe that your solution requires things to be on different subnets to isolate them, with separate jump hosts for each subnet, correct? Here, I only need one sshmux for everyone. Another "fun" feature is that sshmux can also throw unknown users to a separate host, such as ssh-chat, for support or hanging out. Actually, in case of -oProxyCommand="ssh -W %h:%p jump_host", you're still fully secure in the case that the jump host (sorry for not calling it a jumpbox) is compromised. This is true both for normal SSH servers and for sshmux. They can mess with the original raw ssh connection that requests the forward, but this will just screw the connection up. They can connect it to a wrong host, but that will provide incorrect host keys. The agent isn't forwarded, so they don't get to sign anything with the private key. Messing with the new connection that gets established is subject to SSH's normal MITM resistance. This means that even root on the jump host would require real SSH protocol vulnerabilities to attack the connection. Good luck with Userify!

zippie 11y ago

This is nice but the agent forwarding is a legitimate concern especially because a compromised host can take off with the private keys which are used while beginning the session. Most private keys are used for more than connecting to a single host. In our setup we use jailkit allowing only ssh passthrough [1], we have added LDAP support to it (may release the patch later). [1] http://olivier.sessink.nl/jailkit/howtos_ssh_only.html http://olivier.sessink.nl/jailkit/howtos_ssh_only.html

joushou 11y ago
What authentication do you have from the jump host to the target? To me, it looks like it has been reduced to either none or keyboard-interactive (password) login, which is considered bad practice. I could very easily implement support for this in sshmux, providing the setup you seem to use, as a way to avoid agent forwarding, but I just genuinely did not expect anyone to use password authentication, apart from in default config scenarios, before a public key has been installed. Agent forwarding does not provide private keys, but only individual signing requests. This means that while the user is connected, and evil remote can request arbitrary signing, but only as long as the user is connected, and only as long as the users ssh agent is willing to do so. Using ssh-add -c further means that the user will have to accept each signing request. Also note that ssh -W, which is immune to any of these concerns, is fully supported by sshmux. Correct me if I'm wrong, but "Jailkit" does not seem to stop an evil legitimate user from poking around other hosts with forwarding and such (which they can as long as ssh -W functions, within the limits of what a firewall allows the jump host to do in general). sshmux allows you to lock users to targets, rather than lock general capabilities of the entire jump host. This is because, while I provide clients access to various hosts, I do not trust them enough to have any unnecessary privileges.

thomashabets2 11y ago

https://blog.habets.se/2014/06/Another-way-to-protect-your-SSH-keys https://blog.habets.se/2014/06/Another-way-to-protect-your-S... Seems like the same thing. Even written in go, too.

joushou 11y ago
I see why you might think that, but no. SSHProxy tries to move the private key from your computer to an external thing. SSHProxy doesn't have anything to do with sshmux. SSHProxy is a two part thing: 1. A server that, when connected to, will ssh to the requested host, but authenticate with a local private key. 2. A client that will, when connected to the server, work like netcat for ProxyCommand purposes. I'm skipping some info about additional SSH sessions being involved, as they don't provide any additional security. The result is essentially ProxyCommand="ssh -W %h:%p jump_host", but instead of you having the private key, the jump_host has it. You then use a different private key to authenticate to the jump host. I get the idea, and I by no means say he shouldn't have implemented it, but this provides no additional security what so ever. It just moves your private key from one machine to another. I hope he had fun implementing it, though! If you don't implement what might be a bad idea, you'll never get around to the good ones. Plus, bad ideas can be fun, even if they remain bad when done.
- thomashabets2 11y ago
  Ah yes, on closer inspection on a non-phone they are quite different. You are just wrong on the no additional security though. In addition to enabling auditing, it also allows a username/password to be turned into an ssh key, so that you can know that if the rpi wasn't turned on, then nobody could log in to the target machine. It's similar to a TPM in this regard (as blog says), or can be a jumpgate protecting the systems behind it from compromised or malicious users. I'm sorry you don't get it, but I'm not hurt by someone not understanding something when they criticize it. If you don't see the point of not having direct access to your key, then there's nothing I can do.
  - joushou 11y ago

j_s 11y ago

I've used a similar setup to wrap RDP to allow employees to securely remotely access their office desktop. There is a market for someone willing to make this a turn-key replacement for Terminal Services.

Daviey 11y ago

Increasingly I am using sshuttle[0] to solve this problem. When you have lots of machines, ProxyCommand'ing always feels like such a burden. [0] https://github.com/apenwarr/sshuttle https://github.com/apenwarr/sshuttle

joushou 11y ago
When I use SSH as VPN, it's usually because I want less flexible applications to use it, using socks5 configured as a system-level proxy. When doing more work on our corporate network, I usually SSH through the jump to my desktop and work from there, unless I specifically need to access another machine for something. As for sshuttle, it's a very convenient device, although the design appears rather complicated. I'll look into it.
- beagle3 11y ago
  The design is possibly the simplest for what it does (and it does that exceedingly well). sshuttle is: - a tcp multiplexer (multiple connections onto one stream) - a router (uses firewall rules to make normal connections go through the multiplexer) - a few kludgy tunneling operations, to make the combination above seem like a real VPN (discovery of remote subnets, tunneling of DNS requests, ....) - a default setup that runs the multiplexed stream through an ssh connection, thereby giving all the security guarantees that ssh provides (integrity, confidentiality, mitm resistance) - packaged in such a way that the remote side needs to have a minimal python>2.6 install, and a user capable of making tcp connections. Nothing more. In my experience, it works way better than IPSEC tunnels and some commercial VPNs that I've used. With two caveats that I'm ok with with: a) only TCP, and b) all connections seem to come from your remote ssh server. No VPN solution that I'm aware of makes so few demands; do you know of one that doesn't require root at the remote server?
  - joushou 11y ago
    ssh -D (socks5 mode) doesn't require root, and can forward both udp and tcp traffic, doing what it appears that the client requires. socks5 is just a protocol that tells the server to connect to X on port Y using protocol Z, or to bind to X on port Y using protocol Z. Root is only required if you want to bind to privileged ports. A bonus with this is that it only requires a SSH server in default configuration. SOCKS5 most common usage is to just use it as a proxy for HTTP traffic or similar, but it can make any connection. The trick lies in the "kludgy tunnelling operations" and the "router" (firewall rules).It's this magic that makes it better than the socks5 proxy solution, as it really does appear like a VPN. I wonder how much effort it would be to get rid of some of the "magic", though. But I have to agree, that ANYTHING is better than a real VPN in complexity.