Re: [opensuse] Re: ssh & root logins special? in 11.1?

Linda Walsh wrote:
Mark Goldstein wrote:
On Fri, Apr 17, 2009 at 10:17 PM, Linda Walsh <suse@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx:/home/david/.ssh/
rsync -auv authorized_keys david@xxxxxxxxxxxxxxxx:/home/david/.ssh/

exit 0

Relevant Pages

  • Re: setting a password less ssh connection
    ... hicham wrote: ... I've found lot on the web about exchanging public keys but i still ... Are you trying to log in as root, or as a user using key pairs? ... remote backups even if root login is normally not allowed). ...
    (Fedora)
  • Re: setting a password less ssh connection
    ... I've found lot on the web about exchanging public keys but i still ... Are you trying to log in as root, or as a user using key pairs? ... public key authentication will be allowed, ... remote backups even if root login is normally not allowed). ...
    (Fedora)
  • Re: setting a password less ssh connection
    ... I'm having trouble to set a passwordless ssh connection between many ... I've found lot on the web about exchanging public keys but i still ... Are you trying to log in as root, or as a user using key pairs? ... use rsync to keep a backup machine in sync with the main machine. ...
    (Fedora)
  • Re: setting a password less ssh connection
    ... I'm having trouble to set a passwordless ssh connection between many ... I've found lot on the web about exchanging public keys but i still ... Are you trying to log in as root, or as a user using key pairs? ... use rsync to keep a backup machine in sync with the main machine. ...
    (Fedora)
  • Recent getty(8) changes clobbers w(1)
    ... After the recent gettychanges wwill now show root logins on ... the same ttys if you use su. ... after logging out the root ...
    (freebsd-current)