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;
}
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
add a comment |
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
I tried on Mojave 10.14.3 and it works. Is the directory empty?
– Matteo
Feb 8 at 11:27
add a comment |
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
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
bash scp
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
add a comment |
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
add a comment |
2 Answers
2
active
oldest
votes
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
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>
andscp -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
|
show 1 more comment
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.
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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
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>
andscp -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
|
show 1 more comment
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
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>
andscp -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
|
show 1 more comment
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
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
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>
andscp -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
|
show 1 more comment
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>
andscp -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
|
show 1 more comment
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.
add a comment |
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.
add a comment |
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.
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.
answered Feb 12 at 21:39
StéphaneStéphane
1413
1413
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
I tried on Mojave 10.14.3 and it works. Is the directory empty?
– Matteo
Feb 8 at 11:27