Linda Walsh wrote:
Mark Goldstein wrote:
On Fri, Apr 17, 2009 at 10:17 PM, Linda Walsh <suse@tlinx.org> wrote:
Seems odd that having it commented out would mean it's the current default in 11.0+10.3, but not in 11.1, but the sshd_config, I'd think, would only be used in logging in to a server.
It is also commented out on my 11.0. Probably it is done by hardening scripts. It is considered better security practice, not to allow root remote logging. One is supposed to log in as normal user and then use sudo / su to do root stuff.
I don't think it's done by hardening scripts. The "allow root" would disallow logging via password (as well, _I think_ by a shared RSA or DSA key). Ideally, you only log in from machines on your network that use your key and disallow keyboard-interactive password login. But in the instance of wanting to access your system from some outside 'public' system, people have trusted passwords, which unfortunately, might be electronically sniffed, presuming not outright monitored by those providing the "public terminal", thus, the desirability of some type of one-time password generation system.
Meanwhile, I'm still a bit bewildered why public-key login is not working, but only for root (leaving only interactive pw) on the new system. Was hoping someone else might 'just know' if (by running into and solving the same prob) due to some 11.1 specific change. Probably change in 11.1 was the culprit. Meanwhile, back to searching...(my Friday evenings and weekends are filled with great fun! :-))
-linda
Linda, Mark hit the nail on the head. Root logins are *not* permitted by default. The sshd_config is simply giving you the wrong impression. The line: #PermitRootLogin yes needs to be uncommented and followed by an rcsshd restart (or reload) to enable root login. I just leave it as is and set up public key/private key access as a regular user and then use su or sudo to do any root operations required. My sshd_config looks like this: [16:54 ecstasy:~] # nc /etc/ssh/sshd_config AllowGroups family GatewayPorts yes X11Forwarding yes Port 22 #NOTE: you can move ssh to a high port and eliminate script kiddies) Protocol 2 PasswordAuthentication no ChallengeResponseAuthentication no UsePAM yes X11Forwarding yes Subsystem sftp /usr/lib64/ssh/sftp-server AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT AcceptEnv LC_IDENTIFICATION LC_ALL All password and challenge/response authentication is disabled. Then to provide access, I create ssh keys. For this example, I'll call the box you want access to [box 1] and the client you will access [box 1] from, [box 2]. So this will get passwordless access from [box 2] --> [box 1]. The process is simple. First on [box 2]: ssh-keygen -t dsa Which creates a dsa private key under ~/.ssh/id_dsa and a public key as ~/.ssh/id_dsa.pub. Next, in order to gain access to [box 1] you need to either ssh or rsync [box 2]:~/.ssh/id_dsa.pub into [box 1]:~/.ssh/authorized_keys Basically, I do something like this: rsync [box 2]:~/.ssh/id_dsa.pub into [box 1]:~/tmp/id_dsa.pub.box2 Then on [box 1] cat ~/tmp/id_dsa.pub.box2 >> ~/.ssh/authorized_keys You can now shutdown all challenge/response authentication on [box 1] and ssh [box 2] --> [box 1] without a password. Works like a champ. I keep a single directory with all public keys for my boxes and create and distribute a global authorized_keys file as I add or update public keys. I just make sure all the keys have the default id_dsa.pub.boxname format and use a small script (attached) to update the global authorized_keys. Nothing special, but it works. I just put it in the same directory I store my public keys in. You can get around the need to use sudo or su to operate as root on most occasions by copying the authorized_keys file to /root/.ssh on [box 2]. This will allow root on [box 2] to ssh into [box 1] with 'ssh {user}@[box 1]'. Of course there will be some occasions when actually operating as root on box 1 is required. In that case, you can either ssh and sudo or su, or just create a reverse set of keys that allows passwordless logins from [box 1] --> [box 2]. The above can cover 99% of all access needs. 100% if you don't mind the times when you have to do a 2-step ([box 2] rsync--> [box 1/temp] cp--> [box 1/final]). Otherwise, you will just have to enable root logins. Thankfully, I have been able to avoid that during the past 9 years though. Hope this help. I know you already know this stuff, but sometimes looking at it from another perspective help a lightbulb or two blink on;-) -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com #!/bin/bash # ## Check for root # ROOT_UID=0 E_NOTROOT=67 if [ "$UID" -ne "$ROOT_UID" ]; then echo -e "\nYou must be root to run this script.\nUser: $USER, UID: $UID can't!\n" exit $E_NOTROOT fi # ## Backup Authorized_Keys file # for ((i=3;i>0;i--)); do let NEXT=i+1 case "$i" in "3" ) if [[ -w "authorized_keys.3" ]]; then rm "authorized_keys.3"; fi;; * ) if [[ -w "authorized_keys.${i}" ]]; then mv "authorized_keys.${i}" "authorized_keys.${NEXT}"; fi;; esac done if [[ -w "authorized_keys" ]]; then mv authorized_keys authorized_keys.1 fi # ## Create New Authorized_Keys File # for i in $(ls id_dsa.pub.*); do cat ${i} >> authorized_keys done # ## local copy and set key ownership # cp authorized_keys /root/.ssh/ chown david:dcr authorized_keys cp authorized_keys /srv/www/dcr/backup/ cp authorized_keys /home/david/.ssh/ # ## rsync to local lan # rsync -auv authorized_keys david@alchemy:/home/david/.ssh/ rsync -auv authorized_keys david@ecstasy:/home/david/.ssh/ rsync -auv authorized_keys david@kidsdell:/home/david/.ssh/ rsync -auv authorized_keys david@killerz:/home/david/.ssh/ rsync -auv authorized_keys david@nemesis:/home/david/.ssh/ rsync -auv authorized_keys david@nirvana:/home/david/.ssh/ rsync -auv authorized_keys david@zephyr:/home/david/.ssh/ rsync -auv authorized_keys david@zion:/home/david/.ssh/ # ## rsync offsite servers # rsync -auv authorized_keys david@providence.rbpllc.com:/home/david/.ssh/ rsync -auv authorized_keys david@bonza.rbpllc.com:/home/david/.ssh/ exit 0