On 26/05/15 18.29, Daniel Kahn Gillmor wrote:> On Tue 2015-05-26 17:42:40 -0400, Kasper Dupont wrote: > > But it does not address all my requirements. I have a > > requirement that the hostname being used must be visible > > to the administrator of the SSH server. And it must be > > visible with minimal effort without requiring any software > > changes on the server. > > The patch you're sending is a software change :)My requirements only said no software changes on the server. It was clear to me very early on, that some changes were needed on the client side. Whether the client side changes can be done as a ProxyCommand remains an open question. But it is certain that a modification of the ssh client would cover all my needs.> > > > But there are not many opportunities for a proxy to inject > > data into the data stream from client to server without > > breaking integrity checks on the packets. > > no, the proxycommand has to wrap the ssh traffic in an outer-layer > tunnel.I need the proxy to communicate with an unmodified server. And I need this communication to include the hostname for the administrator of said server to see. Whether the administrator would have to look in a logfile or a packet capture in order to see the hostname is not important. I believe that once I have an answer to how the proxy can communicate the hostname to the server, then everything else will follow.> > I am still pondering on whether there are other ways to > > get the hostname communicated across to the server without > > breaking the integrity of the connection. > > If you're going to prevent passive attackers from sniffing it, it would > have to be done after the key exchange, which would suggest that the > proxy would need to know the secret key material for the session. That > seems like a bad outcome either way.None of my requirements say the hostname must remain hidden from a passive attacker. So for me it only makes sense to first look for a solution which satisfy my requirements, and only once the requirements are satisfied look for ways to improve the solution to have other nice properties. Sending the hostname after key exchange is impossible. The proxy need to know which server to communicate with, that's the point of sending the hostname in the first place. That means key exchange can only start after the hostname has been sent to the proxy. I don't yet know a way to acheive my desired result using just a ProxyCommand. But with the following change and a ProxyCommand, I believe I would be able to achieve what I am looking for. diff -up openssh-6.6p1/sshconnect.c.original openssh-6.6p1/sshconnect.c --- openssh-6.6p1/sshconnect.c.original 2015-05-23 11:56:55.235217137 +0200 +++ openssh-6.6p1/sshconnect.c 2015-05-27 01:14:02.563652677 +0200 @@ -560,6 +560,9 @@ ssh_exchange_identification(int timeout_ if (options.protocol == SSH_PROTO_2) { enable_compat20(); send_client_banner(connection_out, 0); + packet_send_ignore(0); + packet_send(); + packet_write_wait(); client_banner_sent = 1; } The question then is, would the security implications of adding these three lines be much worse than my original patch? -- Kasper Dupont -- Rigtige m?nd skriver deres egne backupprogrammer #define _(_)"d.%.4s%."_"2s" /* This is my email address */ char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,12,_+2,_+7,_+6);
On 27/05/15 01:22, Kasper Dupont wrote:> On 26/05/15 18.29, Daniel Kahn Gillmor wrote: >> On Tue 2015-05-26 17:42:40 -0400, Kasper Dupont wrote: >>> But it does not address all my requirements. I have a >>> requirement that the hostname being used must be visible >>> to the administrator of the SSH server. And it must be >>> visible with minimal effort without requiring any software >>> changes on the server. >> The patch you're sending is a software change :) > My requirements only said no software changes on the server. > It was clear to me very early on, that some changes were > needed on the client side. > > Whether the client side changes can be done as a > ProxyCommand remains an open question. But it is certain > that a modification of the ssh client would cover all my > needs....with a modified server that acts as a proxy.> I need the proxy to communicate with an unmodified server. > And I need this communication to include the hostname for > the administrator of said server to see. Whether the > administrator would have to look in a logfile or a packet > capture in order to see the hostname is not important.An unmodified *final server* or *proxy server*? The final server would obviously work being unmodified. The proxy server could have modifications or not (perhaps not being a ssh server at all). And why do you need the server administrator (the administrator of the proxy?) to see the hostname? (the proxy logs would contain it, but placing the burden on getting the administrator see the hostname, instead of the proxy obtaining it, is strange)> I believe that once I have an answer to how the proxy can > communicate the hostname to the server, then everything > else will follow.Are you trying to solve a XY Problem ? http://xyproblem.info/> I don't yet know a way to acheive my desired result using > just a ProxyCommand. But with the following change and a > ProxyCommand, I believe I would be able to achieve what I > am looking for.You only need a command that is able to connect to hostname "foo" over proxy "bar", and a proxy server of type "bar" installed in the ipv4 bridging machine. No changes to ssh binaries are needed.
On 27/05/15 02.04, ?ngel Gonz?lez wrote:> On 27/05/15 01:22, Kasper Dupont wrote: > >Whether the client side changes can be done as a > >ProxyCommand remains an open question. But it is certain > >that a modification of the ssh client would cover all my > >needs. > ....with a modified server that acts as a proxy.The proxy is not going to be based on an SSH server. Rather the proxy is going to be a multi-protocol proxy which I already wrote for dispatching TCP connections to backends based on hostname. That proxy does just enough protocol detection to pick out the hostname. Works great for HTTP and HTTPS. I have proof of concept code showing that with only a minor change on the *client* side, connections can go through my unmodified HTTP proxy and be terminated on an unmodified ssh server. That proof of concept code is the baseline which I am going to compare any other solution against. In order for me to consider an alternative to that proof of concept code, the alternative has to offer at least one advantage over my proof of concept code and not violate any of my requirements. The most tricky of my requirements is likely the one about ensuring the hostname will be visible to the administrator of the SSH server without requiring any code changes on the SSH server. I welcome any suggestions to how I can address that requirement. A solution which could be implemented as a ProxyCommand rather than as a modification of the client itself would be an advantage. I have an idea as to how my proof of concept could be modified to work as a ProxyCommand. It remains to be seen, whether it is going to work.> > > >I need the proxy to communicate with an unmodified server. > >And I need this communication to include the hostname for > >the administrator of said server to see. Whether the > >administrator would have to look in a logfile or a packet > >capture in order to see the hostname is not important. > An unmodified *final server* or *proxy server*? The final server > would obviously work being unmodified.The final server needs to work unmodified. Getting that part to work is trivial if you ignore the requirement about the hostname being communicated to the final server. But once the hostname has to be communicated to the final server, it is not completely trivial. It is still doable since sending the hostname as part of a field which is going to be ignored by the server will work.> The proxy server could have > modifications or not (perhaps not being a ssh server at all).The proxy is not going to be an SSH server. The baseline for the proxy is a server designed to be a multi-protocol name based TCP frontend. It works with any TCP protocol in which the client speaks first and the client send the hostname before hearing from the server. So far the protocols I found satisfying those requirements are HTTP and HTTPS.> And why do you need the server administrator (the administrator > of the proxy?) to see the hostname?I am talking about the administrator of the server not the proxy. It needs to be visible to that administrator mainly such that in case of misdirected connections the administator can find the AAAA record directing the client to said server.> (the proxy logs would contain it, > but placing the burden on getting the administrator see the hostname, > instead of the proxy obtaining it, is strange)The proxy logs will certainly contain the hostname, but the administrator of the server could be anybody and wouldn't have access to the proxy logs. Sure they can ask for the hostname to be looked up in the proxy logs. But that would be a needless extra step, if the server administrator can simply look at the traffic being sent to the server in order to know the hostname.> > >I believe that once I have an answer to how the proxy can > >communicate the hostname to the server, then everything > >else will follow. > Are you trying to solve a XY Problem ?No. I have a specific set of requirements, and I am looking for a solution to address that set of requirements. From the list of requirements I am focusing on that one requirement because none of the proposed solutions have addressed it. And my expectation is, that once that requirement has been addressed it is going to be obvious how the rest of the problems can be addressed.> >I don't yet know a way to acheive my desired result using > >just a ProxyCommand. But with the following change and a > >ProxyCommand, I believe I would be able to achieve what I > >am looking for. > You only need a command that is able to connect to hostname > "foo" over proxy "bar", and a proxy server of type "bar" installed > in the ipv4 bridging machine.That does not address the requirement that the hostname is communicated to the server. Sure if that requirement is ignored, there will be plenty of possible approaches. But I am not going to ignore that requirement. Suggestions to how it can be solved if that requirement is ignored are not helping me because I have considered them before and rejected them because they did not satisfy my requirements. It would be much more helpful to me if I got a suggested solution to that single requirement which ignored everything else. -- Kasper Dupont -- Rigtige m?nd skriver deres egne backupprogrammer #define _(_)"d.%.4s%."_"2s" /* This is my email address */ char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,12,_+2,_+7,_+6);