A couple final remarks : I recently had to reformat the installation drive and I'm using my folder that was stored on another drive. When reinstalling Fedora 21, I was forced to create a home directory on that drive, but then I switched my user account to point to a backed-up version of my old home directory after I created the mount points for the other drives.

EDIT : Passwordless login also works using the following invocations :

/usr/sbin/sshd -D

(no daemon, but no debug messages)

/usr/shbin/sshd

( which I guess constitutes a temporary workaround,since this does invoke the daemon)

So the only thing you're doing different between these test cases is that in the working one you're using sshd -d and in the other one you're not? And enabling debug logging makes it work?
– Wumpus Q. WumbleyMay 13 '15 at 23:37

Not quite-- in one case I've started sshd directly, as you say, but in the other, I've used Fedora's systemctl command, viz. systemctl start sshd.service. What I haven't done is try involking it explicitly WITHOUT the debug option, I'll report back in a second.
– Mark KellyMay 13 '15 at 23:40

I'd try to get the -d into the other startup method, convince it to log the output somewhere. Or let it get started then strace -f -p it and connect.
– Wumpus Q. WumbleyMay 13 '15 at 23:56

What are you seeing in the logs in the failed case? (Possibly with LogLevel increased in sshd_config....)
– mattdmMay 14 '15 at 15:52

3 Answers
3

This is an SELinux problem, caused by your home directory being in a weird location. The thing you did to disable it, didn't. SELinux isn't a service, and systemctl status selinux is just telling you that ("not-found (Reason: No such file or directory)").

You could run setenforce permissive or otherwise disable SELinux, but this kind of like taking the doors off of your house just because you misplaced your housekeys once. Running chcon -t ssh_home_t ~/.ssh/ should do it.

How do I know? Because that the type for the files in ~/.ssh on my system. But I could have installed sepolicy from the policycoreutils-devel package, and run sepolicy manpage -t ssh_d to generate the ssh_selinux.8 man page, which documents the actual policy in place.

Really, I'd most suggest forgetting all of that, just mounting your drive at /home rather than /mnt/driveB, and then running restorecon -R -v /home.

I'll accept this answer, but I don't think I'll quite be able to apply it. This device has several different shares of different formats going, and stopping SELinux has resolved several issues with each of them. That said, I'm sure there's a way to configure SELinux to handle them, but it will take quite a lot of doing.
– Mark KellyMay 18 '15 at 1:30

I had (what I believe to be) a similar problem, wherein SSH attempts to users whose home directories were based on an NFS share were being repeatedly rejected, with only the following cryptic message written to the (debug/verbose) output of ssh:

debug1: key_parse_private2: missing begin marker

As indicated by the other answers, it turned out to be an SELinux problem. However, it appears that there is a solution more fine-grained than disabling SELinux enforcement entirely.

On the host which is serving the home directories, run the following command to tell SELinux to label the directory containing the user home directories the same way as the default home-directory-containing directory /home:

Then run this command to recursively reset SELinux labels on the home directories:

sudo restorecon -R /path/to/custom/homedir/container/on/server

If you are using NFS (as in my case), then take execute the following additional command on each client where the home directories are mounted, in order to set SELinux to allow the use of NFS-mounted home directories: