Secure Shell and selective passwordless root logins

[Darrell Tschakert]

Hi,
I recently loaded Secure Shell 03.81.002 on four 11.0 HP-UX systems.

Prior to loading Secure Shell, these four HP 9000's servers were configured in such as way that any of the four HP's could log into any of the other three HP's as root without seeing the string "Password:" and without having to enter a password. I would just enter "rlogin ammio3" and I jumped from whatever HP I was on to ammio3. The four HP's were able to login to each other as root but no other hosts were able to log in to them as root.

After installing Secure Shell, I was able to configure the four HP's to be able to login to each other without passwords. I just enter "ssh root@ammio" and I am in. I use the RSA Authentication. Other hosts, of course, still have to enter passwords to login.

I want to continue to be able to allow the four HP's to log into each other as root without requiring passwords. But, I do not want to allow any other hosts to login to these HP's as root. Other hosts should be able to login to the four HP's as non-root users but with passwords required.

Can anyone tell me how to do this?

Thanks,

Darrell Tschakert

[RAC_1]

You need to set ssh authentication to "exchange of public/private keys" Procedure attached. Check it and set accordingly.

Using H/P's Secure Shell & Secure Copy


Purpose:

As we migrate to more secure systems, convenient utilities such as FTP and TELNET will be replaced with more secure systems. Secure Shell (ssh) and Secure Copy (scp) are the standard replacements for these. Over time, the insecure utilities will be completely blocked from use, so all users with HP Unix accounts will need to become familiar with these. Because of the authentication and encryption, making a connection initially is slower than the insecure systems. But once the connection is made, they are equally as fast and convenient.

Authentication & Encryption

Both ssh and scp use public/private key encryption. This document will not cover the theory behind this authentication and encryption algorhythym. This is covered in Practical Unix & Internet Security: 2nd Edition (Garfinkel/Spafford, © 1996, 1991 O'Reilly & Associates, Inc.) in considerable depth. This document will concentrate on the actual use of this technology rather than the theory.


Setting up the keys

1. It is most efficient to take the time to set up all hosts at the same time. If you have an account on 6 machines, set up all 6 at the same time. If you later are granted access to another machine, it is your responsibility to make the modifications to all of them. This is the responsibility of each user rather than a job for the systems administrator.
2. Fastest/easiest way to set up the key files.
a. Open a session on one host using CDE (Citrix Metaframe for Unix is best). Open a standard text terminal session inside the CDE desktop.
b. Also open the text editor from the CDE desktop.
c. On the terminal session, type ssh-keygen -t dsa. Press for the next 3 questions. Do NOT use a passphrase unless instructed to do so by Security, or if standard policies change.
i. The above command will create the .ssh directory under the users' home directory.
ii. It will also create 3 files, you will add a fourth, and a fifth will soon appear.
d. Change into the .ssh directory with cd ~/.ssh.
e. Next, display the public key created with the previous step: cat id_dsa.pub. This will show the lengthy public key.
f. Highlight that public key by holding the left mouse button down, and dragging the cursor down across the displayed characters. There are a LOT of them. The very last will be your user name and the host on which you're working. Make sure that they are all highlighted, but nothing else.
g. At the top of the menu bar, click Edit --->Copy. This loads the character string into the CDE paste buffer
h. Next, move the cursor into the menu bar of the text editor. Click Edit-->Paste. This writes the paste buffer into the text file. At the end of the line, type a single so that the carriage returns to the far left.
i. Return to the text terminal session by clicking on its menu bar. Ensure that your home directory has appropriate permissions. Type cd ../.. which will move up two directories in the hierarchy. List the directory with ll. On the far left, the permissions should read drwxr-xr-x. If they don't, change them with chmod 755 . The secure utilities will not work properly if these permissions are not correct.

j. Next, open a session on the next host on which you will use the secure utilities. Type ssh . You will be challenged with: The authenticity of host ' (ip address)' can't be established. RSA key fingerprint is (long hexadecimal number). Are you sure you want to continue connecting (yes/no)? Answer yes.
k. You will next see Warning: Permanently added '(hostname) (IP address) ' (RSA) to the list of known hosts. You will then be challenged for your password, as normal.
l. Close the session on remote host, return to the standard terminal session on the host. Next, either open a session on another remote host, or continue with step m below if you have completed steps c-k, above on all hosts. You will be creating a text file with the contents of the id_dsa.pub file from each host, separated by a carriage return.
m. When steps c-k have been done on all hosts, save the text file. Click on File-->Save As, and enter /(the path to your home directory/.ssh/authorized_keys. It is essential to save this file in this particular directory with this particular filename. Be sure that this path/filename is in the box near the bottom of the popup window.
n. Next, ensure that the authorized_keys file has the proper permissions. Return to the home session on the first system. Then change into the .ssh directory with cd ~/.ssh.
o. List the .ssh directory with ll. The authorized_keys files should show -rw-r--r-- on the far left. If not, change the permissions with chmod 644 authorized_keys.
p. Next copy the authorized_keys file into the .ssh directory of each remote host on which you ran steps c-k, with scp authorized_keys HOST:/(my home directory)/.ssh/authorized_keys.
q. Lastly, open a session on each host that has the authorized_keys file, with ssh . You will be challenged for a password, but if the previous steps have been done exactly, this will be the last time. You can check this by logging off (with exit or ), then logging on again. You should not be challenged for a password. If so, check permissions as above before opening a help desk ticket.
r. You might want to open a session ON each host, TO each host. Again, you should only be challenged for a password the first time. Afterwards, you may ssh or scp securely without being prompted for a password.
s. If you are later granted access to another host, you must add the contents of its ~/.ssh/id_dsa.pub file to each ~/.ssh/authorized_keys file

[Michael Selvesteen_2]

Use SSH public key authentication.

In every HP machine do the following

1. ssh-keygen -t rsa -f

2. cat file_name.pub

3. copy the public key and append it to the remote machine's /.ssh/authorized_keys2 or /.ssh/authorized_keys

Make sure that Public key authentication is enabled in /opt/ssh/etc/sshd_config.

Now you should be logging into your HP boxes without passwords. still problems
refer :
http://cfm.gs.washington.edu/security/ssh/client-pkauth/

Running the server and client in debug mode will also help.

For restricting other users you can use /etc/hosts.allow & /etc/hosts.deny.

for more info try

http://linux.about.com/library/cmd/blcmdl5_hosts.deny.htm

All the best
--
M

[Darrell Tschakert]

Michael and RAC,
I don't think you guys got the jist of my question. I ALREADY HAVE PASSWORDLESS LOGINS SET UP. Now that I have passwordless logins as root set up on my four HP 9000's, I want to have the following:
1. Only these four HP's can log into these four HP's at root.
2. No other computers can log into my four HP's as root.
3. Other computers can log into my HP's as non-root users. They will need a password to log in to my four HP's.

Any suggestions?

Thanks,

Darrell T.

[Sridhar Bhaskarla]

Hi Darrel,

//
1. Only these four HP's can log into these four HP's at root.
2. No other computers can log into my four HP's as root.
3. Other computers can log into my HP's as non-root users. They will need a password to log in to my four HP's. //

I didn't read the answers. But as long as you setup public/private key authentications for only those hosts, then the conditions 1 and 2 are satisfied. For ex., generate public/private keys for hostA's root and copy it to hostB,hostC and hostD into their authorized_keys and do the same for hostB, hostC and hostD.

If hostE tries to logon to either of these hosts as root, since there is no key present in authorized_keys file, it will prompted for the password.

For condition 3, it depends on how each individual users setup their authentications.

-Sri

[Brian Crabtree]

Darrell,

I think this might work.

Create a $HOME/.ssh/config file under your root user.

Put:

Host host1 host2 host3 host4
passwordauthentication yes

Host *
passwordauthentication no

Might work.

Thanks, Brian

[Darrell Tschakert]

Sri,
I don't quite understand what you are saying. You repeated my rules and then wrote:

## If hostE tries to logon to either of these hosts as root, since there is no key present in authorized_keys file, it will prompted for the password.##

To Review, this is what I wrote in my original posting:

## I want to continue to be able to allow the four HP's to log into each other as root without requiring passwords. But, I do not want to allow any other hosts to login to these HP's as root. ##

So, again, I don't want other hosts logging in as root whether they are "prompted for the password" or not.

Brian, I am not convinced that I should be able to insert entries similar to the ones you suggest:

## Host host1 host2 host3 host4
## passwordauthentication yes

Have you read someplace that this is possible, or have you seen a similar example. Perhaps it is possible in non-HP-UX Secure Shell. Just in case you were on to something, I took the time and effort to try it, but it just generated errors.

So far, it would appear that, no one has understood my question/problem. Again, this is the problem:

I have four HP's named hp01, hp02, hp03, and hp04.
1. Only these four HP's can log into these four HP's at root and they are currently configured to login to each other passwordless (without entering a password)
2. No other computers can log into my four HP's as root.
3. Other computers can log into my HP's as non-root users if they have the appropriate passwords. Other computers (those that are not hp01, hp02, hp03, or hp04) will NOT be allowed to log into hp01, hp02, hp03 or hp04 as root.

Thank you,

Darrell Tschakert

[Sridhar Bhaskarla]

Hi Darrel,

Well. What you are looking for is some 'user-based' systemwide configuration. Let's see some possibilities. You may need to do some research on exploring them.

1. /etc/securetty determines whether root login is permitted or not. However, it is global and will affect all the systems. So, that's not a solution for you as you want host01-04 to be able to login.

2. You can place little code in startup files (/etc/profile and /etc/csh.login) to check if the login is root and is from any of these four hosts and deny otherwise. It will work but will still ask for the password. Issue is that there are workarounds to bypass the startup files. In addition, it won't stop sftp/scp etc.,

3. /var/adm/inetd.sec is system-based access list again. So, that' won't work either.

4. Check if your 'sshd' is responsive to /etc/hosts.deny and /etc/hosts.allow. It will if it was compiled with tcp_wrappers. hosts.deny|allow allows userbased accesslists. Look at the following URL for examples.

http://unixhelp.ed.ac.uk/CGI/man-cgi?hosts_access+5

If sshd was not compiled with tcp_wrappers, then you will need to invoke it through indirect tcp_wrapping. Means specifying it in inetd.conf and accessing it via tcpd. Running sshd through inetd.conf can slow down initial connections though.

-Sri

[D Block 2]

Darrell-
do you have a "known_hosts" file setup for .ssh on your 4 nodes ?

in: HP-UX CSE: Offical Study Guide and Desk Reference, by Charles Keenan, he writes on p. 1145, (might be worth getting this recently published book!)

After I have ensured that all nodes have the complete "authorized_keys" file, I can start to establish what is known as the "known_hosts" file. This will authenticate me on the remote hosts. Initially, we will be asked for our password, because we haven't been authenticated on that node previously.

"Once authenticated, we no longer need to enter our passord to log in to the remote machine. In effect, the "known_hosts" file is acting like the $HOME/.rhosts file.

I think what Charles Keenan, points out is, for your 4 servers, each server should have this "known_hosts" file, and looking at the .ssh directory on One of the Other nodes, the "known_hosts" file is missing.

[Darrell Tschakert]

Tom Denin - As I mentioned in my original posting and then again later, I already have the passwordless logins set up. The problem was keeping the others out.

Sri - Actually it is the /etc/securetty that allowed the old system to work the way I wanted it to, even though it is global. On the pre-Secure Shell system /etc/securetty would keep all but console out as root, but then /.rhosts and /etc/hosts.equiv would let in my host[1-4] This however did not work with ssh, scp and the other Secure Shell software which appear to pay no attention to /etc/securetty.
Sri - I was not able to get what I wanted out of hosts.allow and hosts.deny. I won't go into the details as to why. HP Support tried as well but could not do it.

I have tried all the basic and reasonable things. If anyone has ever done this, please let me know.

Thanks,
Darrell T

[Darrell Tschakert]

Folks,
I finally figured it out. Quite simple really. I just added the AllowUsers keyword to my sshd_config file and followed it with something like this:

root@hst1.full.path root@hst2.full.path \
root@hst3.full.path root@hst4.full.path \
sam fredm johnd susanp oracle

Of course I had "PermitRootLogin yes" set as well.

This allows root only from host1-4 and all other users from anywhere. I can narrow the field with hosts.allow and hosts.deny

I didn't realize that AllowUsers permitted the use of host names (full path names only) as well as user names. But I know it now and won't forget it soon. I have worked for days on this.

Thanks,
Darrell Tschakert

[Steven E. Protter]

You would have to set up user by user and the invest user for example could not have root priviledges on any machine.

To force password use, simply don't do the public keyword exchange.

SEP

[Darrell Tschakert]

Steven,
I don't quite understand what you mean by "set up user by user". I added the above mentioned single long line in sshd_config and restarted sshd. Just as I indicated above and it works just like what I asked for in my most recent posting. It works just as I had hoped it would.

Darrell Tschaket