joushou

ssh-agent, as a protocol-concept is not as broken as it sounds. It's just that the implemented interface (socket) is bad when combined with no user acknowledgment of sign requests. I think the worst part is that the agent doesn't ask the user for confirmation, which would essentially invalidate most of the ways you would abuse the agent. Attacks would be reduced to spamming or attempted phishing with agent requests.

Kerberos could have bad interface as well, but I don't know how that would work in this scenario. The protocol itself is secure, but just as with ssh agent forwarding, if you let everyone make authentication requests without requiring user interaction to verify it, it will have the same problems.

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.

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.

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. :/

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. :)

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.

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.

Agent forwarding can be dangerous, yes, in the sense that you are giving the remote host you are connecting to (or jumphost in this case) permission to sign things with your private key.

In the normal case, this is done through a socket, which means that root on the machine can access it, and sign arbitrary things. A compromised machine is therefore dangerous. This is no different than getting root access on the local machine, as you can access your local ssh agent there as well.

However, with sshmux, the agent channel is not forwarded as a socket, but instead internally handled as the ssh channel it really is. This means that compromising the agent at sshmux requires arbitrary memory access, which is a considerably more difficult feat, and means that the machine is 100% compromised regardless.

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.

I understand, I just don't see where it is an improvement.

My rant is mainly triggered by dynamic linking being the standard without many people questioning the usability. It rarely it works as intended, especially with versioned symbols. If I depend on openssl, and an update comes in, then one of 3 things can have happened: 1. They updated the old symbols 2. They implemented new symbols, but left the old ones behind 3. They implemented new symbols, killing the old ones.

1. means that the behaviour of the library under my application changes, which can lead to unexpected bugs. 2. means that my application is not experiencing the fix at all. 3. means that my application won't start anymore, due to dyld errors. 3 is what happens when you update something to a new version in the normal manner.

This "multi-version" mess also makes the libs more complicated than they're supposed to be. My ubuntu libc, for example, includes symbols from 2.2.5, 2.3, 2.3.2, 2.4, 2.5, 2.7, 2.8, 2.11, and 2.15, just to check the very last symbols. It's a mess.

For users, it's mainly a headache when trying to get newer versions of packages that depend on newer libs. This isn't much of an issue if you're, say, a gentoo or arch linux user, but if you're maintaining Debian systems, and need a package from a newer repo but can't/don't want to dist-upgrade to testing/experimental, then you're practically screwed short of compiling things yourself.

For distro maintainers, it's a mess as all packages depending on the lib for that distro release needs to be recompiled when releasing a new version of the lib, which is a lot of work.

Dynamic linking and versioned symbols is also the very reason that causes sites with binary releases to have a binary for Windows, a binary for OS X, a binary for Ubuntu 14.04, a binary for Red hat 6.3, a binary for Arch Linux, a binary for..., further increasing the inconvenience for the user.

The only time you have benefits from dynamic linking is in the very rare scenario 1 of updated libraries, where everything is done exactly right when modifying old symbols so nothing breaks, which is a bit unlikely unless the bug fix was very simple. It also has to be serious enough that the library maintainers see the need to backport the bugfix to the old library versions, rather than release a new one. Otherwise, it's only dragging things down, both in performance, resource consumption and maintenance overhead.

A bit of dynamic linking reading: http://harmful.cat-v.org/software/dynamic-linking/ http://harmful.cat-v.org/software/dynamic-linking/versioned-...

Dynamic linking is not synonymous with security or ease of use. It's known to significantly reduce performance, both when loading as well as runtime whenever an external symbol is used, and the memory savings aren't too great. One has to remember that static linking also means that unused symbols are left behind, as the compiler knows what is needed.

Ability to update components of an application is one of the ideas behind dynamic linking, but in practice it doesn't work that well, and often requires that the application is updated to link against a newer version, which of course can only happen when the distro updates. This also includes LTS distros and backports, which you either have to wait for or kill support for.

There's also a difference in how Go vs. things like C and C++ handles linking, due to Go actually knowing about multiple files, and who uses what. This is quite a bit different than the copy-pasta that C preprocessors generate. We just ported a major product from C++ to Go, which gave us significant performance boost with considerably less code and complexity (This is not a "Go is better than C++", Go just provided a lot of things we needed in the std library that were hard to get in C++). The "necessities" were dynamically linked (libstdc++, libgcc_s, pthread, libc, ...), but our own libs were statically linked in. The binary was 51MB. The equivalent, completely statically linked Go binary is 8MB. It also does a clean build in <500ms, rather than the 3-5 minutes it took for the C++ project.

... But do remember, that Go 1.5 brings dynamic linking for the ones that want it. While the Go creators don't seem super fond of dynamic linking, they are providing it.

Regarding updating, "go get -u packagename" will update all dependencies, assuming the dependencies are go-gettable. Vendoring changes the picture a bit, in the sense that applications will bundle their own version of things to simplify things a bit, but that doesn't really change the go get -u command. Follow with a go build, and your application is up to date.

The original authors of dynamic linking concluded that the cost was way higher than the benefits, both in memory usage and general performance, but the client demanded it. Dynamic linking is the number one binary compatibility issue on Linux.

Go 1.5 has mechanisms for dynamic linking, though.

SSH with SOCKS5 tunnelling enabled does exactly this. The trick is that VPN's aren't allowed very often, so that's where the TLS tunnel trick steps in. You can use a VPN over TLS with serve2d if you want. I just find ssh -D5000 easier to set up quickly "in the field" than a VPN, especially seeing that it doesn't require server configuration.

Yup, that's also why I added the ability to tunnel anything over a transport (the only implemented one being TLS).

You can get the SSH client to connect over this either by using an openssl s_client trick, or by just using my little tunnel tool (https://github.com/joushou/tunnel).

MySQL seems to use a server initiated protocol (which I always find to be a terrible idea, as it means that an evil client has to do very little to trigger a larger amount of traffic in return, potentially to a spoofed address).

Postgres (which I would recommend over MySQL any day) seems to have a saner client-initiated protocol. I only read part of the spec, but I'll try to see what pattern would need matching later today.

Uh, wow, the popularity just skyrocketed. It's 00:17 and I just came home from a concert, so bear with me maybe being a bit incoherent.

First of all, I'd like to thank my wife, who helped motivate me, my parents, who you know, did the thing that brought me here, my work, for paying me to browse news and occasionally code...

So, why Go? Because it was easiest that way. Try to take a look at how simple the ProxyConn thing is, which is the core of the entire thing. Go is a tool that I found suitable for the task. It also brings things like easy cross-compilation after the code has been written (Seriously, GOOS=windows go build on my mac and I get a PE32+, GOOS=darwin go build on my linux desktop and I get a Mach-O binary). You also get to interact easily with the wonderful Go infrastructure, in case you don't want to redirect to external services.

Why make something that already exists? Well, I didn't know that there were so many solutions, I just thought "Hmm, I wonder if I can make this work in a nice fashion...". That's not going to stop me from continuing development of my own, however. I have ideas I want to try, features I want to implement. It's powering everything on my own servers, and the stealthiness of SSH over TLS (NOT just SSH on port 443) have been (ab)used multiple times already.

Is my solution better than the others? Well, I of course like my own solution, but with few exceptions, I think I bring some interesting flexibility to the game. A lot fo solutions seem to be fixed for a certain purpose, such as SSH and HTTPS, usually just in their regular variants. I don't really care what you want to serve, as long as you can write down some unique bytes in the config for serve2d, or write a more complicated handler directly for serve2. Add transports if you want. Want SSH over TLS over WebSocket over IP over avian carriers? Add the transports.

I'm going to sleep now, and I hope the world haven't self-ignited before I wake up. It's really exciting and motivating to see how people react to private projects.

Hopefully your "What's up with the name" section is better than mine!

I guess the best way to find alternative solutions is to write one and have people tell you there's other like it! I genuinely didn't know there were so many doing equivalent things.

I do think serve2d is considerably more flexible than Corkscrew, though, being able to tunnel anything over TLS if needed. Or other transports, if more are added. I also let you use the same ports for other things.

Actually, yes, packet inspecting firewalls do. Hence the SSH over TLS, to make things stealthy.

How well do you hear 1Hz? A 44.1KHz doesn't have a lot of frequencies outside of the audible range, but that's not really that relevant, as that's only a minor trim compared to the crazy things lossy compression algorithms do here. Their main focus is having the result sound almost like the original. The audible sound-image is modified extensively by them, with focus on simplifications that are hard to notice for a human.