SSH w/Keys: Win10 Client. Key Refused.

[doni49]

I pulled my RasPI out of storage today and have been trying to get it working again (I had it working a few years ago but had put it in storage for the past year or so). After starting it up today, I ran apt-get update and apt-get upgrade to be sure it had all the latest patches.

Anyway....... When attempting to connect my laptop (purchased since the last time the RasPi was in service and has Win10) via SSH, it keeps telling me that it refused the key.

I used PuttyGen to generate a public/private key pair (RSA), copied the contents of the OpenSSH field into ~/.ssh/authorized_keys. I saved both the public key and the private key files on my laptop (not encrypted for now). Then I set Putty to use the private key file.

This is the contents of my authorized_keys file (yes it's all one line -- the website word-wrapped it):

Code: Select all

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAgEAp+G18QqhzVZ4onsgyucI7iT+/9mGbVXYdP+M4TSTZV+iwp8p7mJx0Fv3DYdxDTRAr0/aEvoj+N8LFxaTcHO7quonq/rM6NQA3hyABMvMpDUZ8/bBmVYKxNdcZJ90hN7tRWP0X7OXUjuZlhcctCjsVc5INvLt1sDNwsAXpFbGtpkEF7pk+hAXnkxM9h28rFZVyqIk0vYlXJNjQJ/USPyfl6YpLBWswWeWOZ40GLwHOEFJBbtweNEh4WhogSLxDKmTkq3aZycWhGErAbRaNLHYVXSyxIBtY1ln9FyNEfny4vfB2g7bMTeQ1VqZXcV31Jl0x9jYb3+R6zaOCcNZgmwHY4hG4CAi8lk48XLsloIlgNgkkkWqZ7jME3YpuCuE8Fi3qMcafSgThPLpCi7mvAqMCjM4mktILE7s+/bh7Lc+39J5k8fNvJDPTbqyFfquJqZEDGCCFdCeneJymqNkZZnTExVQrp7vkyPSXwwjVhYAnYrRc7Hno8jtKkWZTyiZPGwscpfqUBdz4BSHdoFYUvBEpSheVdfr4/mtr3aUwYyLJQp/pwQZe7v6yMwX4TfZRo6l9bKHaboUvOUp9SidnklPfW6CoBn8X8O3Nl4WCk+0K9w9tj55qOw6XNFL5YHrI2odL8efd0CMhZZkNV6QVRpYo6lZwUUbu2iAZnIe/tPHSXU= rsa-key-20160130

This is my /etc/ssh/sshd_config file:

Code: Select all

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
#Port 22
Port 9922
# 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
HostKey /etc/ssh/ssh_host_ecdsa_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 yes
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 no

# 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

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
#UsePAM no
PermitRootLogin no
AllowUsers pi
RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys
#PasswordAuthentication yes

[jojopi]

Check for errors on the Pi, after the failure:

Code: Select all

sudo grep sshd /var/log/auth.log

sshd will not trust your authorized_keys file if you have made your home or .ssh directories writeable by other users.

[DirkS]

Check /var/log/auth.log on your Pi.

It could be that the authorisation for ~./ssh and / or ~/.ssh/authorized_keys is not acceptable.
It should be 700 and 600 respectively

[doni49]

I created the .ssh folder AND the authorized_keys while logged in as pi and they're under the pi userfolder. But yet the ls command seems to indicate that they're both owned by root.

Then I even tried to explicitly chown them to change the ownership to pi and it still shows as root. I've tried doing the chown both wth and without sudo with the same effect. Here's the output of JUST doing it without sudo.

Code: Select all

pi@RasPiHomeNas ~ $ chown pi .ssh
pi@RasPiHomeNas ~ $ chown pi .ssh/authorized_keys
pi@RasPiHomeNas ~ $ chmod 700 .ssh
pi@RasPiHomeNas ~ $ chmod 600 .ssh/authorized_keys
pi@RasPiHomeNas ~ $ ls -ld .ssh/authorized_keys
-rwxrwxrwx 1 root root 738 Jan 30 23:25 .ssh/authorized_keys
pi@RasPiHomeNas ~ $ ls -ld .ssh
drwxrwxrwx 1 root root 0 Jan 30 23:25 .ssh

[doni49]

And I think you're right -- that's exactly what's causing this. But why won't it let me assign the ownership?

Here's what the auth.log shows.

Code: Select all

pi@RasPiHomeNas /var/log $ sudo grep sshd /var/log/auth.log
Jan 31 08:21:54 RasPiHomeNAS sshd[2933]: Server listening on 0.0.0.0 port 9922.
Jan 31 08:22:34 RasPiHomeNAS sudo:     root : TTY=pts/0 ; PWD=/ ; USER=root ; COMMAND=/sbin/iptables
Jan 31 08:22:34 RasPiHomeNAS sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Jan 31 08:22:34 RasPiHomeNAS sudo: pam_unix(sudo:session): session closed for user root
Jan 31 08:23:53 RasPiHomeNAS sshd[3049]: Authentication refused: bad ownership or modes for file /var/home/pi/.ssh/authorized_keys
Jan 31 08:23:57 RasPiHomeNAS sshd[3049]: Accepted password for pi from 10.1.1.118 port 50486 ssh2
pi@RasPiHomeNas /var/log $

[DirkS]

Code: Select all

pi@RasPiHomeNas ~ $ chown pi .ssh
pi@RasPiHomeNas ~ $ chown pi .ssh/authorized_keys
pi@RasPiHomeNas ~ $ chmod 700 .ssh
pi@RasPiHomeNas ~ $ chmod 600 .ssh/authorized_keys
pi@RasPiHomeNas ~ $ ls -ld .ssh/authorized_keys
-rwxrwxrwx 1 root root 738 Jan 30 23:25 .ssh/authorized_keys
pi@RasPiHomeNas ~ $ ls -ld .ssh
drwxrwxrwx 1 root root 0 Jan 30 23:25 .ssh

You'll have to use root privileges to change ownership

Code: Select all

sudo chown -R pi ~/.ssh

Then you can change the the privileges as you did above

BTW: re the root ownership. Did you use 'sudo' to create the folder and authorized_keys?

[doni49]

You'll have to use root privileges to change ownership

I thought that by running the command as sudo, I WAS doing it with root privileges. If not, what's the purpose of sudo?

BTW: re the root ownership. Did you use 'sudo' to create the folder and authorized_keys?

No I'm certain that I didn't use sudo. I've read that they have to be owned by the user and ONLY the user so I wanted to be certain not to use sudo.

[doni49]

Even that appears to leave the privileges unchanged.

Code: Select all

pi@RasPiHomeNas /var/log $ sudo chown -R pi ~/.ssh
pi@RasPiHomeNas /var/log $ sudo chown -R pi ~/.ssh/authorized_keys
pi@RasPiHomeNas /var/log $ ls -ld ~/.ssh
drwxrwxrwx 1 root root 0 Jan 30 23:25 /home/pi/.ssh
pi@RasPiHomeNas /var/log $ ls -l ~/.ssh/authorized_keys
-rwxrwxrwx 1 root root 738 Jan 30 23:25 /home/pi/.ssh/authorized_keys

[jojopi]

Clearly the home directory is not in a filesystem that supports Unix access controls. You will have to change the mount options instead, but it will be difficult to get ownership and permissions that are acceptable for more than one user.

Again, sshd's requirements are that the files and directories not be writeable by other users. Since files and directories are by default not writeable by other users, you never need to chown or chmod anything unless you have previously done something odd.

[doni49]

You'll have to use root privileges to change ownership

I thought that by running the command as sudo, I WAS doing it with root privileges. If not, what's the purpose of sudo?

BTW: re the root ownership. Did you use 'sudo' to create the folder and authorized_keys?

No I'm certain that I didn't use sudo. I've read that they have to be owned by the user and ONLY the user so I wanted to be certain not to use sudo.

Ok. Just to be absolutely SURE that they weren't created using sudo, I renamed the .ssh folder and then created a NEW folder & file. It STILL shows root as owner.

Code: Select all

pi@RasPiHomeNas ~ $ mv .ssh .ssh-bak
pi@RasPiHomeNas ~ $ mkdir .ssh
pi@RasPiHomeNas ~ $ nano .ssh/authorized_keys
pi@RasPiHomeNas ~ $ ls -ld ~/.ssh
drwxrwxrwx 1 root root 160 Jan 31 08:54 /home/pi/.ssh
pi@RasPiHomeNas ~ $ ls -l ~/.ssh/authorized_keys
-rwxrwxrwx 1 root root 738 Jan 31 08:54 /home/pi/.ssh/authorized_keys
pi@RasPiHomeNas ~ $ nano .ssh/authorized_keys
pi@RasPiHomeNas ~ $

[doni49]

[quote="jojopi"]Clearly the home directory is not in a filesystem that supports Unix access controls.[quote]

1. What would cause that? This WAS working fine before it went into storage. And I didn't think that was even possible.
2. How can I get it to use a filesystem that DOES support Unix access controls?

[jojopi]

The logs from sshd suggest that your /home may be a symlink to /var/home, and that cannot be the only non-standard thing you have done. If you do not remember why you made these changes, or what filesystems and mounts you are using, it may be better to start again.

You cannot implement /var using FAT or NTFS.

[doni49]

The logs from sshd suggest that your /home may be a symlink to /var/home, and that cannot be the only non-standard thing you have done. If you do not remember why you made these changes, or what filesystems and mounts you are using, it may be better to start again.

You cannot implement /var using FAT or NTFS.

I don't why it's showing as a symlink but I do know why the home folder location doesn't match the default -- I didn't want the user files stored on the SD card. I'd be concerned about having so many writes to the card.

Here's the thread from way-back-when in which I asked about doing this.
viewtopic.php?f=91&t=48069

[doni49]

I'm working on rebuilding from scratch. I did an fdisk -l to see what it shows for the formatting on my external hard drive (on which I want to store the home folders). What it shows is below. I'm confused because I thought ExtFAT is acceptable. And it shows as HPFS/NTFS/exFAT. So how can I force it to use an acceptable system?

Code: Select all

pi@RasPiHomeNas /var/home $ sudo fdisk -l

Disk /dev/mmcblk0: 8270 MB, 8270118912 bytes
4 heads, 16 sectors/track, 252384 cylinders, total 16152576 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00017b69

        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1            8192      122879       57344    c  W95 FAT32 (LBA)
/dev/mmcblk0p2          122880    16152575     8014848   83  Linux

Disk /dev/sda: 2000.4 GB, 2000398931968 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029164 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x6931c2ea

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048  3907026943  1953512448    7  HPFS/NTFS/exFAT
pi@RasPiHomeNas /var/home $