Issuing Command Via SSH Prompts for Password
I'm having an issue with a script used in a project I inherited that has little to no documentation, and am in the process of documenting everything. I'm trying to debug an issue with one line of a script that is executed on the host machine to call out to a LAN-attached Raspberry Pi with SSH to return some information about the Pi.
We already have working versions of this Raspberry Pi which can execute the script without issue, and I'm not sure what the difference is. When executed on the new one, it prompts for the root password on the Pi, but it has not done this on previous versions of the device. I assume it has something to do with the SSH configuration but I don't know enough about SSH to say what would be the cause.
The line in particular causing the issue is:
ssh -o StrictHostKeyChecking=no {host_name} uname -a &>/dev/null
rc=$? #gets the return value of the remote command so we can read the uname info
{host_name} of course is the actual host name it's connecting to, but I've left that part out for privacy reasons. The script is the same on both machines.
Both Pi devices are the same model and I'm having trouble narrowing down what could cause me to not be able to execute this command. Does anyone know what I need to configure in order to be able to execute this command on the Pi remotely?
linux bash ssh raspberry-pi
add a comment |
I'm having an issue with a script used in a project I inherited that has little to no documentation, and am in the process of documenting everything. I'm trying to debug an issue with one line of a script that is executed on the host machine to call out to a LAN-attached Raspberry Pi with SSH to return some information about the Pi.
We already have working versions of this Raspberry Pi which can execute the script without issue, and I'm not sure what the difference is. When executed on the new one, it prompts for the root password on the Pi, but it has not done this on previous versions of the device. I assume it has something to do with the SSH configuration but I don't know enough about SSH to say what would be the cause.
The line in particular causing the issue is:
ssh -o StrictHostKeyChecking=no {host_name} uname -a &>/dev/null
rc=$? #gets the return value of the remote command so we can read the uname info
{host_name} of course is the actual host name it's connecting to, but I've left that part out for privacy reasons. The script is the same on both machines.
Both Pi devices are the same model and I'm having trouble narrowing down what could cause me to not be able to execute this command. Does anyone know what I need to configure in order to be able to execute this command on the Pi remotely?
linux bash ssh raspberry-pi
1
Impossible to answer with the info at hand. Do you have the same users on both Pis? If you do, does one of them have a dedicated~/.ssh/config
entry on your local machine? If no, does the working one have a relevant entry in/etc/sudoers
or/etc/sudoers.d/*
? P.S.: I'm surprised the script does what you're asking, normally commands to be executed on the remote host need to be grouped with their parameters by quotes, e.g.ssh -o StrictHostKeyChecking=no {host_name} "uname -a" &>/dev/null
...
– tink
Nov 19 '18 at 16:47
Probably the first devices have the ssh keys setup by someone previously but this new device has not as you have not done it.
– Matias Barrios
Nov 19 '18 at 16:53
@tink Yes, same users on both devices, as the users are created by the same script. No, there is no "config" file in that directory for either Pi, just a known_hosts file, but there are several private and public keys in /etc/ssh. I'm currently copying these from the old one to the new one to see if that changes anything. It may be a sudoers problem, but I thought I had fixed that already.
– Darin Beaudreau
Nov 19 '18 at 17:05
You also mentionedroot
in the original post - are you really executing ssh commands as root?! ;) Keep prodding. Btw, looking for keys in /etc/ssh is the wrong place, check root's~/.ssh
forauthorized_keys
...
– tink
Nov 19 '18 at 17:11
The command is not being explicitly executed as root, but the ssh command only specifies the hostname, not the user, so it defaults to root. Also, as I said, there is nothing in ~/.ssh besides the known_hosts file.
– Darin Beaudreau
Nov 19 '18 at 18:15
add a comment |
I'm having an issue with a script used in a project I inherited that has little to no documentation, and am in the process of documenting everything. I'm trying to debug an issue with one line of a script that is executed on the host machine to call out to a LAN-attached Raspberry Pi with SSH to return some information about the Pi.
We already have working versions of this Raspberry Pi which can execute the script without issue, and I'm not sure what the difference is. When executed on the new one, it prompts for the root password on the Pi, but it has not done this on previous versions of the device. I assume it has something to do with the SSH configuration but I don't know enough about SSH to say what would be the cause.
The line in particular causing the issue is:
ssh -o StrictHostKeyChecking=no {host_name} uname -a &>/dev/null
rc=$? #gets the return value of the remote command so we can read the uname info
{host_name} of course is the actual host name it's connecting to, but I've left that part out for privacy reasons. The script is the same on both machines.
Both Pi devices are the same model and I'm having trouble narrowing down what could cause me to not be able to execute this command. Does anyone know what I need to configure in order to be able to execute this command on the Pi remotely?
linux bash ssh raspberry-pi
I'm having an issue with a script used in a project I inherited that has little to no documentation, and am in the process of documenting everything. I'm trying to debug an issue with one line of a script that is executed on the host machine to call out to a LAN-attached Raspberry Pi with SSH to return some information about the Pi.
We already have working versions of this Raspberry Pi which can execute the script without issue, and I'm not sure what the difference is. When executed on the new one, it prompts for the root password on the Pi, but it has not done this on previous versions of the device. I assume it has something to do with the SSH configuration but I don't know enough about SSH to say what would be the cause.
The line in particular causing the issue is:
ssh -o StrictHostKeyChecking=no {host_name} uname -a &>/dev/null
rc=$? #gets the return value of the remote command so we can read the uname info
{host_name} of course is the actual host name it's connecting to, but I've left that part out for privacy reasons. The script is the same on both machines.
Both Pi devices are the same model and I'm having trouble narrowing down what could cause me to not be able to execute this command. Does anyone know what I need to configure in order to be able to execute this command on the Pi remotely?
linux bash ssh raspberry-pi
linux bash ssh raspberry-pi
asked Nov 19 '18 at 16:40
Darin Beaudreau
145115
145115
1
Impossible to answer with the info at hand. Do you have the same users on both Pis? If you do, does one of them have a dedicated~/.ssh/config
entry on your local machine? If no, does the working one have a relevant entry in/etc/sudoers
or/etc/sudoers.d/*
? P.S.: I'm surprised the script does what you're asking, normally commands to be executed on the remote host need to be grouped with their parameters by quotes, e.g.ssh -o StrictHostKeyChecking=no {host_name} "uname -a" &>/dev/null
...
– tink
Nov 19 '18 at 16:47
Probably the first devices have the ssh keys setup by someone previously but this new device has not as you have not done it.
– Matias Barrios
Nov 19 '18 at 16:53
@tink Yes, same users on both devices, as the users are created by the same script. No, there is no "config" file in that directory for either Pi, just a known_hosts file, but there are several private and public keys in /etc/ssh. I'm currently copying these from the old one to the new one to see if that changes anything. It may be a sudoers problem, but I thought I had fixed that already.
– Darin Beaudreau
Nov 19 '18 at 17:05
You also mentionedroot
in the original post - are you really executing ssh commands as root?! ;) Keep prodding. Btw, looking for keys in /etc/ssh is the wrong place, check root's~/.ssh
forauthorized_keys
...
– tink
Nov 19 '18 at 17:11
The command is not being explicitly executed as root, but the ssh command only specifies the hostname, not the user, so it defaults to root. Also, as I said, there is nothing in ~/.ssh besides the known_hosts file.
– Darin Beaudreau
Nov 19 '18 at 18:15
add a comment |
1
Impossible to answer with the info at hand. Do you have the same users on both Pis? If you do, does one of them have a dedicated~/.ssh/config
entry on your local machine? If no, does the working one have a relevant entry in/etc/sudoers
or/etc/sudoers.d/*
? P.S.: I'm surprised the script does what you're asking, normally commands to be executed on the remote host need to be grouped with their parameters by quotes, e.g.ssh -o StrictHostKeyChecking=no {host_name} "uname -a" &>/dev/null
...
– tink
Nov 19 '18 at 16:47
Probably the first devices have the ssh keys setup by someone previously but this new device has not as you have not done it.
– Matias Barrios
Nov 19 '18 at 16:53
@tink Yes, same users on both devices, as the users are created by the same script. No, there is no "config" file in that directory for either Pi, just a known_hosts file, but there are several private and public keys in /etc/ssh. I'm currently copying these from the old one to the new one to see if that changes anything. It may be a sudoers problem, but I thought I had fixed that already.
– Darin Beaudreau
Nov 19 '18 at 17:05
You also mentionedroot
in the original post - are you really executing ssh commands as root?! ;) Keep prodding. Btw, looking for keys in /etc/ssh is the wrong place, check root's~/.ssh
forauthorized_keys
...
– tink
Nov 19 '18 at 17:11
The command is not being explicitly executed as root, but the ssh command only specifies the hostname, not the user, so it defaults to root. Also, as I said, there is nothing in ~/.ssh besides the known_hosts file.
– Darin Beaudreau
Nov 19 '18 at 18:15
1
1
Impossible to answer with the info at hand. Do you have the same users on both Pis? If you do, does one of them have a dedicated
~/.ssh/config
entry on your local machine? If no, does the working one have a relevant entry in /etc/sudoers
or /etc/sudoers.d/*
? P.S.: I'm surprised the script does what you're asking, normally commands to be executed on the remote host need to be grouped with their parameters by quotes, e.g. ssh -o StrictHostKeyChecking=no {host_name} "uname -a" &>/dev/null
...– tink
Nov 19 '18 at 16:47
Impossible to answer with the info at hand. Do you have the same users on both Pis? If you do, does one of them have a dedicated
~/.ssh/config
entry on your local machine? If no, does the working one have a relevant entry in /etc/sudoers
or /etc/sudoers.d/*
? P.S.: I'm surprised the script does what you're asking, normally commands to be executed on the remote host need to be grouped with their parameters by quotes, e.g. ssh -o StrictHostKeyChecking=no {host_name} "uname -a" &>/dev/null
...– tink
Nov 19 '18 at 16:47
Probably the first devices have the ssh keys setup by someone previously but this new device has not as you have not done it.
– Matias Barrios
Nov 19 '18 at 16:53
Probably the first devices have the ssh keys setup by someone previously but this new device has not as you have not done it.
– Matias Barrios
Nov 19 '18 at 16:53
@tink Yes, same users on both devices, as the users are created by the same script. No, there is no "config" file in that directory for either Pi, just a known_hosts file, but there are several private and public keys in /etc/ssh. I'm currently copying these from the old one to the new one to see if that changes anything. It may be a sudoers problem, but I thought I had fixed that already.
– Darin Beaudreau
Nov 19 '18 at 17:05
@tink Yes, same users on both devices, as the users are created by the same script. No, there is no "config" file in that directory for either Pi, just a known_hosts file, but there are several private and public keys in /etc/ssh. I'm currently copying these from the old one to the new one to see if that changes anything. It may be a sudoers problem, but I thought I had fixed that already.
– Darin Beaudreau
Nov 19 '18 at 17:05
You also mentioned
root
in the original post - are you really executing ssh commands as root?! ;) Keep prodding. Btw, looking for keys in /etc/ssh is the wrong place, check root's ~/.ssh
for authorized_keys
...– tink
Nov 19 '18 at 17:11
You also mentioned
root
in the original post - are you really executing ssh commands as root?! ;) Keep prodding. Btw, looking for keys in /etc/ssh is the wrong place, check root's ~/.ssh
for authorized_keys
...– tink
Nov 19 '18 at 17:11
The command is not being explicitly executed as root, but the ssh command only specifies the hostname, not the user, so it defaults to root. Also, as I said, there is nothing in ~/.ssh besides the known_hosts file.
– Darin Beaudreau
Nov 19 '18 at 18:15
The command is not being explicitly executed as root, but the ssh command only specifies the hostname, not the user, so it defaults to root. Also, as I said, there is nothing in ~/.ssh besides the known_hosts file.
– Darin Beaudreau
Nov 19 '18 at 18:15
add a comment |
2 Answers
2
active
oldest
votes
Quick fix:
sshpass -p 'password' ssh -o StrictHostKeyChecking=no user@server
Detailed fix:
Most likely you would need to set up Async keys (public/Private) for proper passwordless login. Your command does not show you are using keys so I'm assuming you are not (e.g. -A or -i /path/to/key). Generally root user is blocked (I guess not your problem), I would set up another user for this or change sshd config. You could also Compare the sshd configurations between the Pi Boxes.
See: https://www.raspberrypi.org/documentation/remote-access/ssh/passwordless.md
Alright, that's something I could explore, but the whole point of this was to figure out why the original one doesn't need a password and to change the new one to reflect it. I would prefer not to alter the script and to figure out how the original one fixed this issue, since I'm supposed to be documenting the setup process, not changing it.
– Darin Beaudreau
Nov 19 '18 at 18:16
@DarinBeaudreau we dont' have enough info. to answer your question :-( .. I would start by comparing the config files for ssh between the PI boxes . Can you share that information with us ?
– Mike Q
Nov 19 '18 at 18:23
As I mentioned above, there is no ~/.ssh/config. The only file in that directory is the known_hosts file.
– Darin Beaudreau
Nov 19 '18 at 18:34
After checking the sshd_config on both devices, one thing stood out. In the original device, the sshd_config file in /etc/ssh has a line that says "PermitRootLogin yes", while the new one has that line commented out, but it says "#PermitRootLogin prohibit-password". Could this be the issue?
– Darin Beaudreau
Nov 19 '18 at 18:39
try ssh -vv on the working system to see what it's doing
– Mike Q
Nov 19 '18 at 19:06
|
show 8 more comments
Okay, so after some more digging around, I discovered that there was a separate .ssh directory under /root that contained an authorized_keys file. After copying this to the new Pi, it worked. I had been wondering all this time if there was a separate config folder for root, but I've never gone digging around /root, so I wasn't aware that it was there.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
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%2fstackoverflow.com%2fquestions%2f53379106%2fissuing-command-via-ssh-prompts-for-password%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
Quick fix:
sshpass -p 'password' ssh -o StrictHostKeyChecking=no user@server
Detailed fix:
Most likely you would need to set up Async keys (public/Private) for proper passwordless login. Your command does not show you are using keys so I'm assuming you are not (e.g. -A or -i /path/to/key). Generally root user is blocked (I guess not your problem), I would set up another user for this or change sshd config. You could also Compare the sshd configurations between the Pi Boxes.
See: https://www.raspberrypi.org/documentation/remote-access/ssh/passwordless.md
Alright, that's something I could explore, but the whole point of this was to figure out why the original one doesn't need a password and to change the new one to reflect it. I would prefer not to alter the script and to figure out how the original one fixed this issue, since I'm supposed to be documenting the setup process, not changing it.
– Darin Beaudreau
Nov 19 '18 at 18:16
@DarinBeaudreau we dont' have enough info. to answer your question :-( .. I would start by comparing the config files for ssh between the PI boxes . Can you share that information with us ?
– Mike Q
Nov 19 '18 at 18:23
As I mentioned above, there is no ~/.ssh/config. The only file in that directory is the known_hosts file.
– Darin Beaudreau
Nov 19 '18 at 18:34
After checking the sshd_config on both devices, one thing stood out. In the original device, the sshd_config file in /etc/ssh has a line that says "PermitRootLogin yes", while the new one has that line commented out, but it says "#PermitRootLogin prohibit-password". Could this be the issue?
– Darin Beaudreau
Nov 19 '18 at 18:39
try ssh -vv on the working system to see what it's doing
– Mike Q
Nov 19 '18 at 19:06
|
show 8 more comments
Quick fix:
sshpass -p 'password' ssh -o StrictHostKeyChecking=no user@server
Detailed fix:
Most likely you would need to set up Async keys (public/Private) for proper passwordless login. Your command does not show you are using keys so I'm assuming you are not (e.g. -A or -i /path/to/key). Generally root user is blocked (I guess not your problem), I would set up another user for this or change sshd config. You could also Compare the sshd configurations between the Pi Boxes.
See: https://www.raspberrypi.org/documentation/remote-access/ssh/passwordless.md
Alright, that's something I could explore, but the whole point of this was to figure out why the original one doesn't need a password and to change the new one to reflect it. I would prefer not to alter the script and to figure out how the original one fixed this issue, since I'm supposed to be documenting the setup process, not changing it.
– Darin Beaudreau
Nov 19 '18 at 18:16
@DarinBeaudreau we dont' have enough info. to answer your question :-( .. I would start by comparing the config files for ssh between the PI boxes . Can you share that information with us ?
– Mike Q
Nov 19 '18 at 18:23
As I mentioned above, there is no ~/.ssh/config. The only file in that directory is the known_hosts file.
– Darin Beaudreau
Nov 19 '18 at 18:34
After checking the sshd_config on both devices, one thing stood out. In the original device, the sshd_config file in /etc/ssh has a line that says "PermitRootLogin yes", while the new one has that line commented out, but it says "#PermitRootLogin prohibit-password". Could this be the issue?
– Darin Beaudreau
Nov 19 '18 at 18:39
try ssh -vv on the working system to see what it's doing
– Mike Q
Nov 19 '18 at 19:06
|
show 8 more comments
Quick fix:
sshpass -p 'password' ssh -o StrictHostKeyChecking=no user@server
Detailed fix:
Most likely you would need to set up Async keys (public/Private) for proper passwordless login. Your command does not show you are using keys so I'm assuming you are not (e.g. -A or -i /path/to/key). Generally root user is blocked (I guess not your problem), I would set up another user for this or change sshd config. You could also Compare the sshd configurations between the Pi Boxes.
See: https://www.raspberrypi.org/documentation/remote-access/ssh/passwordless.md
Quick fix:
sshpass -p 'password' ssh -o StrictHostKeyChecking=no user@server
Detailed fix:
Most likely you would need to set up Async keys (public/Private) for proper passwordless login. Your command does not show you are using keys so I'm assuming you are not (e.g. -A or -i /path/to/key). Generally root user is blocked (I guess not your problem), I would set up another user for this or change sshd config. You could also Compare the sshd configurations between the Pi Boxes.
See: https://www.raspberrypi.org/documentation/remote-access/ssh/passwordless.md
answered Nov 19 '18 at 17:54


Mike Q
2,52312337
2,52312337
Alright, that's something I could explore, but the whole point of this was to figure out why the original one doesn't need a password and to change the new one to reflect it. I would prefer not to alter the script and to figure out how the original one fixed this issue, since I'm supposed to be documenting the setup process, not changing it.
– Darin Beaudreau
Nov 19 '18 at 18:16
@DarinBeaudreau we dont' have enough info. to answer your question :-( .. I would start by comparing the config files for ssh between the PI boxes . Can you share that information with us ?
– Mike Q
Nov 19 '18 at 18:23
As I mentioned above, there is no ~/.ssh/config. The only file in that directory is the known_hosts file.
– Darin Beaudreau
Nov 19 '18 at 18:34
After checking the sshd_config on both devices, one thing stood out. In the original device, the sshd_config file in /etc/ssh has a line that says "PermitRootLogin yes", while the new one has that line commented out, but it says "#PermitRootLogin prohibit-password". Could this be the issue?
– Darin Beaudreau
Nov 19 '18 at 18:39
try ssh -vv on the working system to see what it's doing
– Mike Q
Nov 19 '18 at 19:06
|
show 8 more comments
Alright, that's something I could explore, but the whole point of this was to figure out why the original one doesn't need a password and to change the new one to reflect it. I would prefer not to alter the script and to figure out how the original one fixed this issue, since I'm supposed to be documenting the setup process, not changing it.
– Darin Beaudreau
Nov 19 '18 at 18:16
@DarinBeaudreau we dont' have enough info. to answer your question :-( .. I would start by comparing the config files for ssh between the PI boxes . Can you share that information with us ?
– Mike Q
Nov 19 '18 at 18:23
As I mentioned above, there is no ~/.ssh/config. The only file in that directory is the known_hosts file.
– Darin Beaudreau
Nov 19 '18 at 18:34
After checking the sshd_config on both devices, one thing stood out. In the original device, the sshd_config file in /etc/ssh has a line that says "PermitRootLogin yes", while the new one has that line commented out, but it says "#PermitRootLogin prohibit-password". Could this be the issue?
– Darin Beaudreau
Nov 19 '18 at 18:39
try ssh -vv on the working system to see what it's doing
– Mike Q
Nov 19 '18 at 19:06
Alright, that's something I could explore, but the whole point of this was to figure out why the original one doesn't need a password and to change the new one to reflect it. I would prefer not to alter the script and to figure out how the original one fixed this issue, since I'm supposed to be documenting the setup process, not changing it.
– Darin Beaudreau
Nov 19 '18 at 18:16
Alright, that's something I could explore, but the whole point of this was to figure out why the original one doesn't need a password and to change the new one to reflect it. I would prefer not to alter the script and to figure out how the original one fixed this issue, since I'm supposed to be documenting the setup process, not changing it.
– Darin Beaudreau
Nov 19 '18 at 18:16
@DarinBeaudreau we dont' have enough info. to answer your question :-( .. I would start by comparing the config files for ssh between the PI boxes . Can you share that information with us ?
– Mike Q
Nov 19 '18 at 18:23
@DarinBeaudreau we dont' have enough info. to answer your question :-( .. I would start by comparing the config files for ssh between the PI boxes . Can you share that information with us ?
– Mike Q
Nov 19 '18 at 18:23
As I mentioned above, there is no ~/.ssh/config. The only file in that directory is the known_hosts file.
– Darin Beaudreau
Nov 19 '18 at 18:34
As I mentioned above, there is no ~/.ssh/config. The only file in that directory is the known_hosts file.
– Darin Beaudreau
Nov 19 '18 at 18:34
After checking the sshd_config on both devices, one thing stood out. In the original device, the sshd_config file in /etc/ssh has a line that says "PermitRootLogin yes", while the new one has that line commented out, but it says "#PermitRootLogin prohibit-password". Could this be the issue?
– Darin Beaudreau
Nov 19 '18 at 18:39
After checking the sshd_config on both devices, one thing stood out. In the original device, the sshd_config file in /etc/ssh has a line that says "PermitRootLogin yes", while the new one has that line commented out, but it says "#PermitRootLogin prohibit-password". Could this be the issue?
– Darin Beaudreau
Nov 19 '18 at 18:39
try ssh -vv on the working system to see what it's doing
– Mike Q
Nov 19 '18 at 19:06
try ssh -vv on the working system to see what it's doing
– Mike Q
Nov 19 '18 at 19:06
|
show 8 more comments
Okay, so after some more digging around, I discovered that there was a separate .ssh directory under /root that contained an authorized_keys file. After copying this to the new Pi, it worked. I had been wondering all this time if there was a separate config folder for root, but I've never gone digging around /root, so I wasn't aware that it was there.
add a comment |
Okay, so after some more digging around, I discovered that there was a separate .ssh directory under /root that contained an authorized_keys file. After copying this to the new Pi, it worked. I had been wondering all this time if there was a separate config folder for root, but I've never gone digging around /root, so I wasn't aware that it was there.
add a comment |
Okay, so after some more digging around, I discovered that there was a separate .ssh directory under /root that contained an authorized_keys file. After copying this to the new Pi, it worked. I had been wondering all this time if there was a separate config folder for root, but I've never gone digging around /root, so I wasn't aware that it was there.
Okay, so after some more digging around, I discovered that there was a separate .ssh directory under /root that contained an authorized_keys file. After copying this to the new Pi, it worked. I had been wondering all this time if there was a separate config folder for root, but I've never gone digging around /root, so I wasn't aware that it was there.
answered Nov 28 '18 at 13:32
Darin Beaudreau
145115
145115
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- 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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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%2fstackoverflow.com%2fquestions%2f53379106%2fissuing-command-via-ssh-prompts-for-password%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
1
Impossible to answer with the info at hand. Do you have the same users on both Pis? If you do, does one of them have a dedicated
~/.ssh/config
entry on your local machine? If no, does the working one have a relevant entry in/etc/sudoers
or/etc/sudoers.d/*
? P.S.: I'm surprised the script does what you're asking, normally commands to be executed on the remote host need to be grouped with their parameters by quotes, e.g.ssh -o StrictHostKeyChecking=no {host_name} "uname -a" &>/dev/null
...– tink
Nov 19 '18 at 16:47
Probably the first devices have the ssh keys setup by someone previously but this new device has not as you have not done it.
– Matias Barrios
Nov 19 '18 at 16:53
@tink Yes, same users on both devices, as the users are created by the same script. No, there is no "config" file in that directory for either Pi, just a known_hosts file, but there are several private and public keys in /etc/ssh. I'm currently copying these from the old one to the new one to see if that changes anything. It may be a sudoers problem, but I thought I had fixed that already.
– Darin Beaudreau
Nov 19 '18 at 17:05
You also mentioned
root
in the original post - are you really executing ssh commands as root?! ;) Keep prodding. Btw, looking for keys in /etc/ssh is the wrong place, check root's~/.ssh
forauthorized_keys
...– tink
Nov 19 '18 at 17:11
The command is not being explicitly executed as root, but the ssh command only specifies the hostname, not the user, so it defaults to root. Also, as I said, there is nothing in ~/.ssh besides the known_hosts file.
– Darin Beaudreau
Nov 19 '18 at 18:15