Mark Goldstein wrote:

Are you sure you changed the default /etc/ssh/sshd_config and enabled root login (PermitRootLogin yes)? It is disabled by default.

All three /etc/ssh/sshd_config files have the "PermitRootLogin line commented out with a Yes by it. The comment at the top says it provides the defaults. (whatever that means). But the "PermitRootLogin yes" line is commented out in all 3 hosts. It seems to vary based on util whether the comment represent the alternate value or the default value, but seeing as they are the same on all 3 hosts, I'd expect logins between the two old systems (A(10.3)<->B(11.0)) to fail if that was the case. Unless the default changed in 11.1? But why would the change on 11.1 affect both ways i.e. C(11.1) <--//-->> <A|B>(10.3/11.0)? 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. So C, when logging into "A" would use the same sshd_config file as when "B" logs into "A" (i.e. the sshd_config file on "A"). So what you say maybe true, but then something is overriding that in the interactions between (the two old systems A10.3 & B11.0). It seems like there may be some other setting that is being looked at (especially since the prob is bidirectional). ??? No? Logical? Shouldn't be working in any case? :-) That's not comforting. :-) Linda -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

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 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Sat, Apr 18, 2009 at 3:20 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Try setting explicitly PermitRootLogin to yes (and when keys work, set it to "without-password":

    PermitRootLogin             Specifies whether root can log in using ssh(1).  The argument             must be “yes”, “without-password”, “forced-commands-only”, or             “no”.  The default is “yes”.

Yes, I've forgotten... Commented out options in sshd_conf and ssh_conf are the defaults. And I re-checked that on my systems with PermitRootLogin yes commented out I have no problem logging in as root (both on 11.0 and 11.1). So Linda's right, it is something other than PermitRootLogin. I do not use non-interactive login on my systems, so I can't check your scenario (maybe I'll give it a try later). -- Mark Goldstein -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

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

On Mon, Apr 20, 2009 at 3:56 AM, Carlos E. R. <robin.listas@telefonica.net> wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Sunday, 2009-04-19 at 17:25 -0500, David C. Rankin wrote:

...

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

I suggested so.  O:-)

As I wrote, I checked on 2 systems (11.0 and 11.1) that with PermitRootLogin yes commented out I coud log in as root without any problem. Carlos cited manpage that says default is "yes". I remembered that general approach in SSH configuration file to show default values as commented out options. So the problem is different. I thought maybe it's firewall, but Linda wrote that she can log in as normal user, so firewall should be OK. -- Mark Goldstein -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org