LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - General (https://www.linuxquestions.org/questions/linux-general-1/)
-   -   SCP Requires Password After System Restarted Following Power Outage (https://www.linuxquestions.org/questions/linux-general-1/scp-requires-password-after-system-restarted-following-power-outage-4175458016/)

OtagoHarbour 04-13-2013 12:18 PM

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?

Thanks,
Peter.

lleb 04-13-2013 12:29 PM

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.

camorri 04-13-2013 12:36 PM

Quote:

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.

OtagoHarbour 04-14-2013 02:14 PM

Quote:

Originally Posted by lleb (Post 4930927)
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.

Code:

-rw------- 1 root root  613 2012-08-25 17:29 authorized_keys
-rw------- 1 root root  668 2012-08-25 17:31 id_dsa
-rw-r--r-- 1 root root  613 2012-08-25 17:31 id_dsa.pub
-rw------- 1 root peter  361 2012-08-25 17:31 id_ecdsa
-rw-r--r-- 1 root root  283 2012-08-25 17:31 id_ecdsa.pub
-rw------- 1 root root  1679 2012-08-25 17:32 id_rsa
-rw-r--r-- 1 root peter  400 2012-08-25 17:32 id_rsa.pub
-rw-r--r-- 1 root peter  222 2012-08-25 17:32 known_hosts

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

OtagoHarbour 04-14-2013 02:19 PM

Quote:

Originally Posted by camorri (Post 4930933)
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

Code:

./executable
but the client asks for a password if I run it as

Code:

sudo ./executable
Thanks,
Peter.

chrism01 04-14-2013 09:27 PM

Sounds like sudoers is directing it to run as a different user, that doesn't have an ssh auth-key.
Quote:

The basic structure of a user specification is 'who = where (as_whom) what'.
http://linux.die.net/man/5/sudoers

lleb 04-14-2013 10:53 PM

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:

Code:

ssh remote_user@remote_IP

scp /path/to/local/file remote_user@remote_IP:/path/to/put/local/file/on/remote/system/

scp remote_user@remote_IP:/path/of/remote/file/to/copy/to/local/system /path/to/put/remote/file/on/local/system/

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

lleb 04-14-2013 10:54 PM

here follow this simple howto:

Quote:

a

###### 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.
enjoy

OtagoHarbour 04-17-2013 07:06 PM

Quote:

Originally Posted by lleb (Post 4931629)
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:

Code:

ssh remote_user@remote_IP

scp /path/to/local/file remote_user@remote_IP:/path/to/put/local/file/on/remote/system/

scp remote_user@remote_IP:/path/of/remote/file/to/copy/to/local/system /path/to/put/remote/file/on/local/system/

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.

Thanks,
Peter.

lleb 04-18-2013 07:43 AM

Quote:

Originally Posted by OtagoHarbour (Post 4933611)
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.

lleb 10-12-2013 12:27 PM

Quote:

Originally Posted by OtagoHarbour (Post 4931475)
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.

Code:

-rw------- 1 root root  613 2012-08-25 17:29 authorized_keys
-rw------- 1 root root  668 2012-08-25 17:31 id_dsa
-rw-r--r-- 1 root root  613 2012-08-25 17:31 id_dsa.pub
-rw------- 1 root peter  361 2012-08-25 17:31 id_ecdsa
-rw-r--r-- 1 root root  283 2012-08-25 17:31 id_ecdsa.pub
-rw------- 1 root root  1679 2012-08-25 17:32 id_rsa
-rw-r--r-- 1 root peter  400 2012-08-25 17:32 id_rsa.pub
-rw-r--r-- 1 root peter  222 2012-08-25 17:32 known_hosts

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.

sundialsvcs 10-15-2013 09:38 AM

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.


All times are GMT -5. The time now is 05:03 PM.