sshd

Can't connect with ssh and sshd complains about permissions on authorized_keys files

I was recently trying to connect to a CentOS box from Windows and had the following error in /var/log/secure (after enabling DEBUG3 level logging in /etc/ssh/sshd_config):

Dec 19 18:01:05 hostname sshd[25119]: debug1: trying public key file /root/.ssh/authorized_keys
Dec 19 18:01:05 hostname sshd[25119]: debug1: Could not open authorized keys '/root/.ssh/authorized_keys': Permission denied

It's an SELinux problem, and I don't quite understand it, but here's the one-liner that fixes it:

restorecon -FRvv ~/.ssh

Found on stackoverflow: "SSHD Gives error could not open Authorized Keys, although permissions seem correct"

Tags: 

Starting sshd With a Higher Nice Value

I wanted sshd on my MythTV box to start with a lower priority than other processes. Sometimes I do large transfers to this box over scp (although usually I use nfs). I tried:

nice -n 10 /usr/sbin/sshd ${myopts} ${SSHD_OPTS}

and

start-stop-daemon -N 10 --stop --quiet --pidfile /var/run/${SVCNAME}.pid --signal HUP

in my /etc/init.d/sshd startup script (in Gentoo) but that didn't work. Even after restarting sshd and logging out and back in again (via ssh) there were still sshd processes running at nice level 0. I think it's because sshd likes to spawn itself at priority 0 (rather than the priority of the parent process, not sure if that is standard or not, but whatever).

The solution I came up with was to run this as a cron job:

ps -o pid -C sshd --no-heading | xargs renice 10

This renices all processes named sshd to nice level 10. This can actually be run by the normal user (if you only log in via ssh as normal user) because the processes that get nice level 0 seem to be processes created by the normal user that you log in as.

Tags: 
Subscribe to RSS - sshd