SCP Requires Password After System Restarted Following Power Outage
Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
SCP Requires Password After System Restarted Following Power Outage
I have two systems: a server running Ubuntu 11.4 and a client running Ubuntu 11.10. I set the system up to allow me to scp from the client to the server without a password using the steps outlined here.
Everything worked fine until there was a power outage and I needed to restart the systems. Now scp always asks for a password. I was wondering what could have changed. Should I go through the whole setup procedure again?
check both systems for the files you created (id_rsa and id_rsa.pub) in addition to known_hosts and authorized_keys. then verify their permissions on both sides. they should look something like the following:
Code:
drwx------ 11 user user 374 Mar 14 19:32 ./
drwxrwxr-x+ 103 user user 3502 Apr 9 11:59 ../
-rw------- 1 user user 4424 Jan 5 21:17 authorized_keys
-rw-r--r-- 1 user user 175 Jan 5 21:28 config
-r-------- 1 user user 3239 Jul 21 2012 id_rsa
-rw-r--r-- 1 user user 741 Jan 5 21:17 id_rsa.cent.pub
-rw-r--r-- 1 user user 752 Jul 21 2012 id_rsa.pub
-rw-r--r-- 1 user user 5657 Mar 14 19:32 known_hosts
if the permissions are incorrect then keyless authentication will fail. this is a security check and a good thing.
Should I go through the whole setup procedure again?
It would make a lot more sense to look at the client and the server, make sure the keys are still there, and check the dir permissions that you set etc. Go through the setup, check both ends.
Can you log in with a password? If yes, then the key exchange is not working. If not, then the problems may be deeper.
check both systems for the files you created (id_rsa and id_rsa.pub) in addition to known_hosts and authorized_keys. then verify their permissions on both sides. they should look something like the following:
Code:
drwx------ 11 user user 374 Mar 14 19:32 ./
drwxrwxr-x+ 103 user user 3502 Apr 9 11:59 ../
-rw------- 1 user user 4424 Jan 5 21:17 authorized_keys
-rw-r--r-- 1 user user 175 Jan 5 21:28 config
-r-------- 1 user user 3239 Jul 21 2012 id_rsa
-rw-r--r-- 1 user user 741 Jan 5 21:17 id_rsa.cent.pub
-rw-r--r-- 1 user user 752 Jul 21 2012 id_rsa.pub
-rw-r--r-- 1 user user 5657 Mar 14 19:32 known_hosts
if the permissions are incorrect then keyless authentication will fail. this is a security check and a good thing.
Thank you for your reply. My permissions are as you describe but my file names are slightly different. I have authorized_keys, id_rsa, id_rsa.pub and known_hosts but not config or id_rsa.cent.pub. I do have id_dsa, id_dsa.pub, id_ecdsa and id_ecdsa.pub. My full listing is as follows.
Ownership had been www-data, since the transfer is done by web applications, but I changed it to root on the client. That did not affect the scp from server.
It would make a lot more sense to look at the client and the server, make sure the keys are still there, and check the dir permissions that you set etc. Go through the setup, check both ends.
Can you log in with a password? If yes, then the key exchange is not working. If not, then the problems may be deeper.
What's strange (to me at least) is that
Code:
sudo scp
asks for a password for the server (as well as the password for sudo) but
Code:
scp
does not. I have written a executable that includes a system scp call and have found that the client does not ask for a password if I run it as
when you sudo you are running as some user other then the user you are log in as, mainly as root, this is wrong and bad.
also you should not have changed the permissions on ~/.ssh to root root that is wrong and bad. put them back to the owner of /home/user, who ever the user is. again read my post, if the permissions are WRONG, you will not be allowed to use passwordless authentication, ie: you will not be able to use ssh keys to authenticate due to permissions issues.
when you ssh or scp to a remote location you should ALWAYS user the following basic format:
###### DIRECTIONS FOR CREATING RSA KEY################
Directions for creating the rsa key and making the two
servers talk to each other without password. Unless otherwise specified all of these tasks
are performed on server A.
1st change directory into .ssh and check what files are there.
[user@user ~]$ cd .ssh
[user@user .ssh]$ ls -l
total 4
-rw-r--r-- 1 user group 2980 Jun 13 12:02 known_hosts
*note* If the .ssh directory is not to be found in your /home/user directory you have two choices.
1: create it...
[user@user ~]$ mkdir -p .ssh
2: ssh into some other system. This to me is the better option. Not only will
it create the ~/.ssh directory, but it will populate it with known_hosts file
with the correct permissions.
2nd create the rsa key.
[user@user .ssh]$ ssh-keygen -t rsa -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
cb:b0:40:c6:e9:f4:9e:f5:71:fc:c3:00:c0:f7:c6:75 user@user.localdomain
*note* The -t flag is for the TYPE of key to generate, in this case rsa, you can also use the
older dsa key, but that is not as secure.
The -b 4096 is the byte size of the encrypted key. 4096 is military grade encryption
and basically impossible to crack without spending far more money then it would be worth.
As this key is to be used in scripts there is no passphrase. This is less secure, but
allows for unattended access to the remote system. Ideal for scripting.
3rd check that there are two new files with the following permissions
[user@user .ssh]$ ls -l
total 12
-rw------- 1 user group 3243 Jun 22 15:50 id_rsa
-rw-r--r-- 1 user group 743 Jun 22 15:50 id_rsa.pub
-rw-r--r-- 1 user group 2980 Jun 13 12:02 known_hosts
4th change directory back to the users $HOME
[user@user .ssh]$ cd
5th copy the key to the remote server
[user@user ~]$ ssh-copy-id -i ~/.ssh/id_rsa.pub user@<IP_SERVER_B>
25
user@<IP_SERVER_B>'s password:
Now try logging into the machine, with "ssh 'user@<IP_SERVER_B>'", and check in:
.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.
==================================================================================================== =====
5a: If ssh-copy-id failes you can manually perform the same basic task as follows:
[user@user ~]$ scp ~/.ssh/id_rsa.pub user@<IP_SERVER_B>:/home/user/.ssh/
user@<IP_SERVER_B>'s password:
[user@user ~]$ ssh user@<IP_SERVER_B>
[user@user ~]$ cd .ssh
[user@user ~]$ cat id_rsa.pub >> authorized_keys
[user@user ~]$ ls -laF
total 88
drwx------ 11 user group 374 Mar 14 19:32 ./
drwxrwxr-x+ 101 user group 3434 Mar 22 17:11 ../
-rw------- 1 user group 4424 Jan 5 21:17 authorized_keys
-rw-r--r-- 1 user group 175 Jan 5 21:28 config
-r-------- 1 user group 3239 Jul 21 2012 id_rsa
-rw-r--r-- 1 user group 752 Jul 21 2012 id_rsa.pub
-rw-r--r-- 1 user group 5657 Mar 14 19:32 known_hosts
*note* You might need to change the permissions of the above files. The key files that
must be correct are: authorized_keys, id_rsa.pub, and known_hosts. If those
have the wrong permissions your ssh key will fail and you will be prompted for
a password for each ssh connection attempt.
*note* Also be mindful of the permissions for the ~/.ssh directory. It must be:
drwx------. 2 user group 4096 Mar 14 15:23 .ssh/
If the permissions are not restrictive enough ssh will not trust the keys and will
ignore them.
==================================================================================================== =====
6th, follow directions on the screen.
[user@user ~]$ ssh user@<IP_SERVER_B>
Last login: Fri Jun 22 14:12:08 2012 from 10.10.4.77
[user@user ~]$ exit
logout
Connection to <IP_SERVER_B> closed.
###### END OF DIRECTIONS FOR CREATING RSA KEY################
It might be a good idea to perform this both ways all depending on your needs.
when you sudo you are running as some user other then the user you are log in as, mainly as root, this is wrong and bad.
also you should not have changed the permissions on ~/.ssh to root root that is wrong and bad. put them back to the owner of /home/user, who ever the user is. again read my post, if the permissions are WRONG, you will not be allowed to use passwordless authentication, ie: you will not be able to use ssh keys to authenticate due to permissions issues.
when you ssh or scp to a remote location you should ALWAYS user the following basic format:
now if the permissions and sshd.conf are configured properly you can do this without password if your ssh keys are proper and authenticate.
if you change any one of the above passwordless authentication WILL FAIL.
1. set your permissions back to the user and its group
2. verify that permissions and ownership are 100% correct
3. confirm that your sshd.conf is configured properly
4. follow basic syntax for both ssh and scp
Thank you for your reply. I can scp without a password if I leave the sudo part out. I changed the ownership if the .ssh directory, and its contents, to www-data since all the scp-ing is done from a web page. But either way I can scp if I leave the sudo out.
Thank you for your reply. I can scp without a password if I leave the sudo part out. I changed the ownership if the .ssh directory, and its contents, to www-data since all the scp-ing is done from a web page. But either way I can scp if I leave the sudo out.
Thanks,
Peter.
good, again that is due to sudo meaning change ownership to root. if you want to ssh as a specific user, then use that users account, not sudo.
Thank you for your reply. My permissions are as you describe but my file names are slightly different. I have authorized_keys, id_rsa, id_rsa.pub and known_hosts but not config or id_rsa.cent.pub. I do have id_dsa, id_dsa.pub, id_ecdsa and id_ecdsa.pub. My full listing is as follows.
Ownership had been www-data, since the transfer is done by web applications, but I changed it to root on the client. That did not affect the scp from server.
Thanks,
Peter
little old, but i am also noting that your id_rsa files are both set to rw, this is incorrect, they should be r only.
It sounds to me like the ssh-agent program did not restart. The agent is the program, on the client machine, that's supposed to intercept the public-key request and figure out what public-key to offer. If it's not running, no key is offered.
But it also sounds like the remote system is configured to accept a password if you don't present the proper key. It shouldn't be permitted to do that. Either you have the key, or you should not be allowed in.
Quote:
Originally Posted by A bad but common scenario:
ssh: Please present your marvelous super-secure wonder key!
intruder: I'm an intruder. So, I don't have one. Guess I'm screwed, then, huh?
ssh: Of course not! No problem! There are lots of other things we can try! "What's the magic word?"
intruder:Uhhhh... "magic?"
ssh: Correct! You may proceed!
SSH supports several different authentication strategies, but it will cycle through them from strongest to weakest, and accept the weakest one.
Last edited by sundialsvcs; 10-15-2013 at 09:46 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.