On Mon, 14 Apr 2014, Yves Dorfsman wrote: > On 2014-04-14 17:52, Damien Miller wrote: > > > > It's easy to determine whether sshd is at fault here. Just replace > > curl with 'cat' of a >12KB file. > > > > It works when doing a cat from a file, it looks more like an issue with the > pipe mechanism. For example, this works, regardless of the size of the file: > > #!/bin/bash > curl -s --compressed http://someurl.example.com/pubkeys/$1 >somefile > cat somefile So curl/wget aren't coping with stdout being non-blocking. Those are bugs in curl and wget. You've got the right workaround, but just don't use a predictable filename (i.e. use mktemp). > > > I created a bash script that runs > > > > > > #!/bin/bash > > > curl -s --compressed http://someurl.example.com/pubkeys/$1 > > > > this is terrifying. > > Why? DNS hijacking, man in the middle attack? Risk when the web server is > compromised (we are using S3 here)? All of the above and more. You've just taken the very small attack surface of reading keys from an authorized_keys file and massively increased it to include DNS, HTTP and the security of the HTTP server (also the security of the network and every router between the sshd and HTTP server if you aren't using HTTPS). -d _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
