scp: error: unexpected filename:





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}







10















An SCP I've been using for a long time to upload files has suddenly stopped working. I ran the script 12 hours ago and it worked just fine, but has suddenly stopped.



The command in question was uploading the current directory to a remote folder:



#!/bin/bash
cd "$(dirname "$0")"

scp -r . <remote_server>:<remote_folder>


The error message is:



scp: error: unexpected filename: .


I'm on a Mac running Mojave 10.14.2.



UPDATE: I have solved the specific problem by rewriting the command to this, but I'd still be interested to know what broke:



scp -r $(pwd) <remote_server>:<remote_folder>









share|improve this question

























  • I tried on Mojave 10.14.3 and it works. Is the directory empty?

    – Matteo
    Feb 8 at 11:27


















10















An SCP I've been using for a long time to upload files has suddenly stopped working. I ran the script 12 hours ago and it worked just fine, but has suddenly stopped.



The command in question was uploading the current directory to a remote folder:



#!/bin/bash
cd "$(dirname "$0")"

scp -r . <remote_server>:<remote_folder>


The error message is:



scp: error: unexpected filename: .


I'm on a Mac running Mojave 10.14.2.



UPDATE: I have solved the specific problem by rewriting the command to this, but I'd still be interested to know what broke:



scp -r $(pwd) <remote_server>:<remote_folder>









share|improve this question

























  • I tried on Mojave 10.14.3 and it works. Is the directory empty?

    – Matteo
    Feb 8 at 11:27














10












10








10


0






An SCP I've been using for a long time to upload files has suddenly stopped working. I ran the script 12 hours ago and it worked just fine, but has suddenly stopped.



The command in question was uploading the current directory to a remote folder:



#!/bin/bash
cd "$(dirname "$0")"

scp -r . <remote_server>:<remote_folder>


The error message is:



scp: error: unexpected filename: .


I'm on a Mac running Mojave 10.14.2.



UPDATE: I have solved the specific problem by rewriting the command to this, but I'd still be interested to know what broke:



scp -r $(pwd) <remote_server>:<remote_folder>









share|improve this question
















An SCP I've been using for a long time to upload files has suddenly stopped working. I ran the script 12 hours ago and it worked just fine, but has suddenly stopped.



The command in question was uploading the current directory to a remote folder:



#!/bin/bash
cd "$(dirname "$0")"

scp -r . <remote_server>:<remote_folder>


The error message is:



scp: error: unexpected filename: .


I'm on a Mac running Mojave 10.14.2.



UPDATE: I have solved the specific problem by rewriting the command to this, but I'd still be interested to know what broke:



scp -r $(pwd) <remote_server>:<remote_folder>






bash scp






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Feb 8 at 10:41









mtak

11.3k23353




11.3k23353










asked Feb 8 at 10:13









Eliezer SteinbockEliezer Steinbock

1536




1536













  • I tried on Mojave 10.14.3 and it works. Is the directory empty?

    – Matteo
    Feb 8 at 11:27



















  • I tried on Mojave 10.14.3 and it works. Is the directory empty?

    – Matteo
    Feb 8 at 11:27

















I tried on Mojave 10.14.3 and it works. Is the directory empty?

– Matteo
Feb 8 at 11:27





I tried on Mojave 10.14.3 and it works. Is the directory empty?

– Matteo
Feb 8 at 11:27










2 Answers
2






active

oldest

votes


















11














The culprit is CVE-2018-20685, whose description is:




In OpenSSH 7.9, scp.c in the scp client allows remote SSH servers to
bypass intended access restrictions via the filename of . or an empty
filename. The impact is modifying the permissions of the target
directory on the client side.




This is part of a larger set of SCP vulnerabilities. Quoting from there:




Overview



SCP clients from multiple vendors are susceptible to a malicious scp
server performing unauthorized changes to target directory and/or
client output manipulation.



Description



Many scp clients fail to verify if the objects returned by the scp
server match those it asked for. This issue dates back to 1983 and
rcp, on which scp is based. A separate flaw in the client allows the
target directory attributes to be changed arbitrarily. Finally, two
vulnerabilities in clients may allow server to spoof the client
output.




The commit that patched this vulnerability in OpenBSD was made on Nov. 16, 2018






share|improve this answer



















  • 2





    Thanks for the explanation. So my SCP somehow got updated over night to include this patch is why it stopped working?

    – Eliezer Steinbock
    Feb 8 at 14:31






  • 2





    Making the scp tool unable to process the standard directory entry "." is an AWFUL solution to this! There must be 10's of other ways they could have solved this (perhaps by verifying that the returned objects ARE what was asked for?)... This is "security by the least effort expended", which is next in line after "security by not publishing the hostname"...

    – Haqa
    Feb 12 at 11:54






  • 1





    Great answer, now I know why my scp scripts on Ubuntu no longer work. But what is the solution? I cannot use * instead of . because the folder contains thousands of files. Is there a new switch to turn off this behaviour?

    – Stéphane
    Feb 12 at 20:35






  • 2





    @Stéphane use $(pwd) instead of .

    – BlackBear
    Feb 13 at 7:35






  • 2





    @BlackBear It's not the same. . allow to copy all files (including those starting with a dot) without copying directory itself. scp -r $(pwd) <host>:<dest. dir> and scp -r . <host>:<dest. dir> ARE different. In first case you've got <dest. dir>/<current dir name>/<files list> when you've got <dest. dir>/<files list> with second case.

    – Bil
    Mar 5 at 8:51





















4














The other answer from @BlackBear explains why this no longer works.



But if like me you ended up on this question also looking for a solution, it seems the right way to do it is with rsync instead of scp. For example, one of my old scp commands would have looked like this:



# this no longer works due to the "."
scp -BCr output/html/. www:/var/www/site/html/


Now instead I use this:



rsync --recursive --times --compress --delete --progress output/html/ www:/var/www/site/html/


If you prefer the shorter flags, it would look like this:



rsync -rtz --del --progress output/html/ www:/var/www/site/html/


The trailing / on the source is important. It tells rsync you want the content of that directory without the directory name.



Also consider --dry-run and man rsync before messing things up.






share|improve this answer
























    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "3"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1403473%2fscp-error-unexpected-filename%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    11














    The culprit is CVE-2018-20685, whose description is:




    In OpenSSH 7.9, scp.c in the scp client allows remote SSH servers to
    bypass intended access restrictions via the filename of . or an empty
    filename. The impact is modifying the permissions of the target
    directory on the client side.




    This is part of a larger set of SCP vulnerabilities. Quoting from there:




    Overview



    SCP clients from multiple vendors are susceptible to a malicious scp
    server performing unauthorized changes to target directory and/or
    client output manipulation.



    Description



    Many scp clients fail to verify if the objects returned by the scp
    server match those it asked for. This issue dates back to 1983 and
    rcp, on which scp is based. A separate flaw in the client allows the
    target directory attributes to be changed arbitrarily. Finally, two
    vulnerabilities in clients may allow server to spoof the client
    output.




    The commit that patched this vulnerability in OpenBSD was made on Nov. 16, 2018






    share|improve this answer



















    • 2





      Thanks for the explanation. So my SCP somehow got updated over night to include this patch is why it stopped working?

      – Eliezer Steinbock
      Feb 8 at 14:31






    • 2





      Making the scp tool unable to process the standard directory entry "." is an AWFUL solution to this! There must be 10's of other ways they could have solved this (perhaps by verifying that the returned objects ARE what was asked for?)... This is "security by the least effort expended", which is next in line after "security by not publishing the hostname"...

      – Haqa
      Feb 12 at 11:54






    • 1





      Great answer, now I know why my scp scripts on Ubuntu no longer work. But what is the solution? I cannot use * instead of . because the folder contains thousands of files. Is there a new switch to turn off this behaviour?

      – Stéphane
      Feb 12 at 20:35






    • 2





      @Stéphane use $(pwd) instead of .

      – BlackBear
      Feb 13 at 7:35






    • 2





      @BlackBear It's not the same. . allow to copy all files (including those starting with a dot) without copying directory itself. scp -r $(pwd) <host>:<dest. dir> and scp -r . <host>:<dest. dir> ARE different. In first case you've got <dest. dir>/<current dir name>/<files list> when you've got <dest. dir>/<files list> with second case.

      – Bil
      Mar 5 at 8:51


















    11














    The culprit is CVE-2018-20685, whose description is:




    In OpenSSH 7.9, scp.c in the scp client allows remote SSH servers to
    bypass intended access restrictions via the filename of . or an empty
    filename. The impact is modifying the permissions of the target
    directory on the client side.




    This is part of a larger set of SCP vulnerabilities. Quoting from there:




    Overview



    SCP clients from multiple vendors are susceptible to a malicious scp
    server performing unauthorized changes to target directory and/or
    client output manipulation.



    Description



    Many scp clients fail to verify if the objects returned by the scp
    server match those it asked for. This issue dates back to 1983 and
    rcp, on which scp is based. A separate flaw in the client allows the
    target directory attributes to be changed arbitrarily. Finally, two
    vulnerabilities in clients may allow server to spoof the client
    output.




    The commit that patched this vulnerability in OpenBSD was made on Nov. 16, 2018






    share|improve this answer



















    • 2





      Thanks for the explanation. So my SCP somehow got updated over night to include this patch is why it stopped working?

      – Eliezer Steinbock
      Feb 8 at 14:31






    • 2





      Making the scp tool unable to process the standard directory entry "." is an AWFUL solution to this! There must be 10's of other ways they could have solved this (perhaps by verifying that the returned objects ARE what was asked for?)... This is "security by the least effort expended", which is next in line after "security by not publishing the hostname"...

      – Haqa
      Feb 12 at 11:54






    • 1





      Great answer, now I know why my scp scripts on Ubuntu no longer work. But what is the solution? I cannot use * instead of . because the folder contains thousands of files. Is there a new switch to turn off this behaviour?

      – Stéphane
      Feb 12 at 20:35






    • 2





      @Stéphane use $(pwd) instead of .

      – BlackBear
      Feb 13 at 7:35






    • 2





      @BlackBear It's not the same. . allow to copy all files (including those starting with a dot) without copying directory itself. scp -r $(pwd) <host>:<dest. dir> and scp -r . <host>:<dest. dir> ARE different. In first case you've got <dest. dir>/<current dir name>/<files list> when you've got <dest. dir>/<files list> with second case.

      – Bil
      Mar 5 at 8:51
















    11












    11








    11







    The culprit is CVE-2018-20685, whose description is:




    In OpenSSH 7.9, scp.c in the scp client allows remote SSH servers to
    bypass intended access restrictions via the filename of . or an empty
    filename. The impact is modifying the permissions of the target
    directory on the client side.




    This is part of a larger set of SCP vulnerabilities. Quoting from there:




    Overview



    SCP clients from multiple vendors are susceptible to a malicious scp
    server performing unauthorized changes to target directory and/or
    client output manipulation.



    Description



    Many scp clients fail to verify if the objects returned by the scp
    server match those it asked for. This issue dates back to 1983 and
    rcp, on which scp is based. A separate flaw in the client allows the
    target directory attributes to be changed arbitrarily. Finally, two
    vulnerabilities in clients may allow server to spoof the client
    output.




    The commit that patched this vulnerability in OpenBSD was made on Nov. 16, 2018






    share|improve this answer













    The culprit is CVE-2018-20685, whose description is:




    In OpenSSH 7.9, scp.c in the scp client allows remote SSH servers to
    bypass intended access restrictions via the filename of . or an empty
    filename. The impact is modifying the permissions of the target
    directory on the client side.




    This is part of a larger set of SCP vulnerabilities. Quoting from there:




    Overview



    SCP clients from multiple vendors are susceptible to a malicious scp
    server performing unauthorized changes to target directory and/or
    client output manipulation.



    Description



    Many scp clients fail to verify if the objects returned by the scp
    server match those it asked for. This issue dates back to 1983 and
    rcp, on which scp is based. A separate flaw in the client allows the
    target directory attributes to be changed arbitrarily. Finally, two
    vulnerabilities in clients may allow server to spoof the client
    output.




    The commit that patched this vulnerability in OpenBSD was made on Nov. 16, 2018







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Feb 8 at 11:56









    BlackBearBlackBear

    23627




    23627








    • 2





      Thanks for the explanation. So my SCP somehow got updated over night to include this patch is why it stopped working?

      – Eliezer Steinbock
      Feb 8 at 14:31






    • 2





      Making the scp tool unable to process the standard directory entry "." is an AWFUL solution to this! There must be 10's of other ways they could have solved this (perhaps by verifying that the returned objects ARE what was asked for?)... This is "security by the least effort expended", which is next in line after "security by not publishing the hostname"...

      – Haqa
      Feb 12 at 11:54






    • 1





      Great answer, now I know why my scp scripts on Ubuntu no longer work. But what is the solution? I cannot use * instead of . because the folder contains thousands of files. Is there a new switch to turn off this behaviour?

      – Stéphane
      Feb 12 at 20:35






    • 2





      @Stéphane use $(pwd) instead of .

      – BlackBear
      Feb 13 at 7:35






    • 2





      @BlackBear It's not the same. . allow to copy all files (including those starting with a dot) without copying directory itself. scp -r $(pwd) <host>:<dest. dir> and scp -r . <host>:<dest. dir> ARE different. In first case you've got <dest. dir>/<current dir name>/<files list> when you've got <dest. dir>/<files list> with second case.

      – Bil
      Mar 5 at 8:51
















    • 2





      Thanks for the explanation. So my SCP somehow got updated over night to include this patch is why it stopped working?

      – Eliezer Steinbock
      Feb 8 at 14:31






    • 2





      Making the scp tool unable to process the standard directory entry "." is an AWFUL solution to this! There must be 10's of other ways they could have solved this (perhaps by verifying that the returned objects ARE what was asked for?)... This is "security by the least effort expended", which is next in line after "security by not publishing the hostname"...

      – Haqa
      Feb 12 at 11:54






    • 1





      Great answer, now I know why my scp scripts on Ubuntu no longer work. But what is the solution? I cannot use * instead of . because the folder contains thousands of files. Is there a new switch to turn off this behaviour?

      – Stéphane
      Feb 12 at 20:35






    • 2





      @Stéphane use $(pwd) instead of .

      – BlackBear
      Feb 13 at 7:35






    • 2





      @BlackBear It's not the same. . allow to copy all files (including those starting with a dot) without copying directory itself. scp -r $(pwd) <host>:<dest. dir> and scp -r . <host>:<dest. dir> ARE different. In first case you've got <dest. dir>/<current dir name>/<files list> when you've got <dest. dir>/<files list> with second case.

      – Bil
      Mar 5 at 8:51










    2




    2





    Thanks for the explanation. So my SCP somehow got updated over night to include this patch is why it stopped working?

    – Eliezer Steinbock
    Feb 8 at 14:31





    Thanks for the explanation. So my SCP somehow got updated over night to include this patch is why it stopped working?

    – Eliezer Steinbock
    Feb 8 at 14:31




    2




    2





    Making the scp tool unable to process the standard directory entry "." is an AWFUL solution to this! There must be 10's of other ways they could have solved this (perhaps by verifying that the returned objects ARE what was asked for?)... This is "security by the least effort expended", which is next in line after "security by not publishing the hostname"...

    – Haqa
    Feb 12 at 11:54





    Making the scp tool unable to process the standard directory entry "." is an AWFUL solution to this! There must be 10's of other ways they could have solved this (perhaps by verifying that the returned objects ARE what was asked for?)... This is "security by the least effort expended", which is next in line after "security by not publishing the hostname"...

    – Haqa
    Feb 12 at 11:54




    1




    1





    Great answer, now I know why my scp scripts on Ubuntu no longer work. But what is the solution? I cannot use * instead of . because the folder contains thousands of files. Is there a new switch to turn off this behaviour?

    – Stéphane
    Feb 12 at 20:35





    Great answer, now I know why my scp scripts on Ubuntu no longer work. But what is the solution? I cannot use * instead of . because the folder contains thousands of files. Is there a new switch to turn off this behaviour?

    – Stéphane
    Feb 12 at 20:35




    2




    2





    @Stéphane use $(pwd) instead of .

    – BlackBear
    Feb 13 at 7:35





    @Stéphane use $(pwd) instead of .

    – BlackBear
    Feb 13 at 7:35




    2




    2





    @BlackBear It's not the same. . allow to copy all files (including those starting with a dot) without copying directory itself. scp -r $(pwd) <host>:<dest. dir> and scp -r . <host>:<dest. dir> ARE different. In first case you've got <dest. dir>/<current dir name>/<files list> when you've got <dest. dir>/<files list> with second case.

    – Bil
    Mar 5 at 8:51







    @BlackBear It's not the same. . allow to copy all files (including those starting with a dot) without copying directory itself. scp -r $(pwd) <host>:<dest. dir> and scp -r . <host>:<dest. dir> ARE different. In first case you've got <dest. dir>/<current dir name>/<files list> when you've got <dest. dir>/<files list> with second case.

    – Bil
    Mar 5 at 8:51















    4














    The other answer from @BlackBear explains why this no longer works.



    But if like me you ended up on this question also looking for a solution, it seems the right way to do it is with rsync instead of scp. For example, one of my old scp commands would have looked like this:



    # this no longer works due to the "."
    scp -BCr output/html/. www:/var/www/site/html/


    Now instead I use this:



    rsync --recursive --times --compress --delete --progress output/html/ www:/var/www/site/html/


    If you prefer the shorter flags, it would look like this:



    rsync -rtz --del --progress output/html/ www:/var/www/site/html/


    The trailing / on the source is important. It tells rsync you want the content of that directory without the directory name.



    Also consider --dry-run and man rsync before messing things up.






    share|improve this answer




























      4














      The other answer from @BlackBear explains why this no longer works.



      But if like me you ended up on this question also looking for a solution, it seems the right way to do it is with rsync instead of scp. For example, one of my old scp commands would have looked like this:



      # this no longer works due to the "."
      scp -BCr output/html/. www:/var/www/site/html/


      Now instead I use this:



      rsync --recursive --times --compress --delete --progress output/html/ www:/var/www/site/html/


      If you prefer the shorter flags, it would look like this:



      rsync -rtz --del --progress output/html/ www:/var/www/site/html/


      The trailing / on the source is important. It tells rsync you want the content of that directory without the directory name.



      Also consider --dry-run and man rsync before messing things up.






      share|improve this answer


























        4












        4








        4







        The other answer from @BlackBear explains why this no longer works.



        But if like me you ended up on this question also looking for a solution, it seems the right way to do it is with rsync instead of scp. For example, one of my old scp commands would have looked like this:



        # this no longer works due to the "."
        scp -BCr output/html/. www:/var/www/site/html/


        Now instead I use this:



        rsync --recursive --times --compress --delete --progress output/html/ www:/var/www/site/html/


        If you prefer the shorter flags, it would look like this:



        rsync -rtz --del --progress output/html/ www:/var/www/site/html/


        The trailing / on the source is important. It tells rsync you want the content of that directory without the directory name.



        Also consider --dry-run and man rsync before messing things up.






        share|improve this answer













        The other answer from @BlackBear explains why this no longer works.



        But if like me you ended up on this question also looking for a solution, it seems the right way to do it is with rsync instead of scp. For example, one of my old scp commands would have looked like this:



        # this no longer works due to the "."
        scp -BCr output/html/. www:/var/www/site/html/


        Now instead I use this:



        rsync --recursive --times --compress --delete --progress output/html/ www:/var/www/site/html/


        If you prefer the shorter flags, it would look like this:



        rsync -rtz --del --progress output/html/ www:/var/www/site/html/


        The trailing / on the source is important. It tells rsync you want the content of that directory without the directory name.



        Also consider --dry-run and man rsync before messing things up.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Feb 12 at 21:39









        StéphaneStéphane

        1413




        1413






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Super User!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1403473%2fscp-error-unexpected-filename%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Plaza Victoria

            Puebla de Zaragoza

            Musa