• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Setting up passwordless SSH - ARRRRRRRRRRRRRRRRRRRRRRRGH!

Ken g6

Programming Moderator, Elite Member
Moderator
This should be easy. On the client, I ran:

Code:
cd ~/.ssh
ssh-keygen -t rsa -f id_rsa -P ""
scp id_rsa.pub ken@server:~/.ssh/authorized_keys2
ssh -i id_rsa -o "PasswordAuthentication no" ken@server

Note that I used the password for the scp. The ssh said permission denied. 😡

I've fiddled with my sshd_conf in the past. Maybe that's the problem?

Code:
# Package generated configuration file
# See the sshd(8) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile	%h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords yes

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

UsePAM yes
 
Check the logs on server, it usually tells you what's wrong and the most likely culprit is permissions on either the ~/.ssh directory or the id_rsa.pub file itself.
 
Logs? What logs? Where? ()🙂

(I assume it's something in /var/log, but that's as far as I got.)
 
Ken,

Like nothinman said, check the permissions on the files created.

Sometimes the OS/version of SSH wants authorized_keys as opposed to what you have with a 2, so try both. I've never used the P flag before but it seems fine, you also dont need to add all of that stuff to your ssh string. Just type ssh server and it if works, it works so to speak.

Failing that, try running ssh -vvv user@host. That will give you the most verbose output and you can see exactly which step its failing on.

Here is what I do:
user@host$: ssh-keygen -t rsa (hit enter through prompts)
user@host$: scp id_rsa.pub user@host2:/var/tmp
user@host2$ cat /var/tmp/id_rsa.pub >> /home/user/.ssh/authorized_keys
user@host$: ssh user@host2
 
Last edited:
Logs? What logs? Where? ()🙂

(I assume it's something in /var/log, but that's as far as I got.)

On something Debian-based /var/log/daemon.log should work, as might /var/log/messages since that's generally an aggregation of most, if not all, of the log sources.
 
run a second ssh instance on the target server and tail -f var/log/messages, if it does not show up there try auth.log
 
Can't find anything in the logs. Permissions are fine: 0600 for files and 0700 for ~/.ssh

Ssh with -vvv is saying it's not finding ~/.ssh/identity. Is that something I need?
 
Can't find anything in the logs. Permissions are fine: 0600 for files and 0700 for ~/.ssh

Ssh with -vvv is saying it's not finding ~/.ssh/identity. Is that something I need?

identity was used in sshv1. Make sure everything is v2, which uses the id_rsa stuff. As in ssh -2 to see if it makes a difference.

In your conf file, clearly, you have authorized_keys as the file to look for, so change the authorized_keys2 to remove the 2. Make sure, somehow, that you copied the file over correctly and that it looks okay (right perms and the entire thing is on 1 line, etc.).
 
The contents of my .ssh directory:
Code:
$ ls -ld ~/.ssh; ls -l ~/.ssh
drwx------ 3 ken ken 4096 2010-08-03 11:04 /home/ken/.ssh
total 52
lrwxrwxrwx 1 ken ken   16 2010-08-03 09:43 authorized_keys -> authorized_keys2
-rw------- 1 ken ken  393 2010-08-03 11:04 authorized_keys2
-rw------- 1 ken ken  236 2010-08-03 09:57 config
-rw------- 1 ken ken  119 2010-05-19 23:20 config~
-rw------- 1 ken ken  532 2009-07-02 15:56 identity
-rw------- 1 ken ken  528 2009-07-02 15:56 identity2
-rw------- 1 ken ken  544 2009-07-02 15:56 identity3
-rw------- 1 ken ken 1743 2010-05-19 18:14 id_rsa
-rw------- 1 ken ken 1675 2010-08-03 09:56 id_rsa2
-rw------- 1 ken ken  391 2010-08-03 09:56 id_rsa2.pub
-rw------- 1 ken ken  400 2010-05-19 18:14 id_rsa.pub
-rw------- 1 ken ken 1817 2010-08-03 09:55 id_rsa.tgz
drwx------ 2 ken ken 4096 2010-05-19 18:12 key_backup
-rw------- 1 ken ken 1768 2010-08-03 10:09 known_hosts

I had to set some stuff up to use GitHub. That worked, and still works, but is it possible I changed something else in some settings somewhere that's in conflict with this?
 
Code:
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
Hrm...

This code rang a bell. :hmm:

If I sat here long enough (and thought about it) I could remember the exact situation that cropped up for me, but...

The 'fix' was to uncomment GSSAPIAuthentication, e.g.

Code:
# GSSAPI options
GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

Took care of my problem... :awe:

It's a shot-in-the-dark, but you might give it a try.
 
make sure you are not SU or running cron's - real and effective uid can screw you many times.

login as joe
su to root
su to sam
which .ssh will you be using ? 🙂 with which config. (priviledge escalations should be off in your conf). there is ssh.conf and sshd.conf 😉
 
I got it! /var/log/auth.log said:
Authentication refused: bad ownership or modes for directory /home/ken

I changed the permissions from 775 to 755, and it worked!

However, I had a setup whereby a PHP script could write to a file in a subdirectory of /home/ken. I think I had set up PHP's user to be in my group, and I bet that script won't work now. Can you suggest how to make the two compatible?

Edit: Got it: I set up a directory /home/php, fixed its permissions, and soft-linked to it.
 
Last edited:
you want to set a subdirectory to 775 or if its one file just that file.

do not do broad stroke permissions when unnecessary or some a-hole will do a rm -rf /* and take out files that are too widely open.
 
Somewhere I got the notion that a user doesn't have permission to access a file unless they have permission to do the same to all parent directories of that file. Although now I think about it that doesn't make a lot of sense. 😕

Edit: Was it perhaps true on Solaris or something?
 
Last edited:
Somewhere I got the notion that a user doesn't have permission to access a file unless they have permission to do the same to all parent directories of that file. Although now I think about it that doesn't make a lot of sense. 😕

Edit: Was it perhaps true on Solaris or something?

I have a similar recollection but I think it was just the execute bit that needs set on the parent directories. You might've been able to get around that with ACLs, but IMO it's better not to have anything except user data in user's home directories so your symlink fix is better anyway.
 
Back
Top