Basic Administrative Access -

[Sicinthemind]

Step 1: Grant yourself administrative privileges
There's some controversy that I'm not even stepping into or even dipping my toes into the water to test the temperature on this debate.

The root user is simply for configuring a server... no need to go beyond that. You often will find yourself making administrative changes where you do not need to be root. Especially if you're not trying to send root authentication all over the network.

So first we'll configure the system you do most of your work on to avoid using root all the time.

[steve@station ~]$ su -
password...
[root@station ~]# echo steve   ALL=(ALL)       ALL >> /etc/sudoers
[root@station ~]# exit
[steve@station ~]$

In doing that, you can now sudo everything you need to do administratively. Switching users with the -, implies you want to use that users profile settings in your shell session in bash. Notice the ~ still applies instead of /home/steve when I su to root with the heifen. On top of that, I want to also add... you may not want ALL commands. So review your man pages, /usr/share/doc, or google for the correct syntaxes to limit the amount of sudo commands as you may just want to get to the other system and su to root anyway just to make sure your user can connect. Obviously you can customize this the way you want to but this is just for the example.


Step 2: Preparing for remote administration.
When you prepare to remotely administer your systems, you don't want to be bothered with tons of prompts for a password. So this is your method to avoid this...

First we need to generate a key pair. A private key implies non-repudiation that you are without a doubt, the originator of the keyset and you are who you say you are. The public key, can decrypt the message from the private key. You don't want your private key all over the place. Since you're not using PKI solutions, this is your way of setting up and deploying your keyset to servers that you want to trust you.

This also assumes that you already created a user on the servers for yourself...

Generate The Key Pair
[fedora] denotes the key passphrase I used in this example

[steve@station ~]$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/steve/.ssh/id_rsa): [enter for the default offering]
Enter passphrase (empty for no passphrase): [fedora]
Enter same passphrase again: [fedora]
Your identification has been saved in /home/steve/.ssh/id_rsa.
Your public key has been saved in /home/steve/.ssh/id_rsa.pub.
The key fingerprint is:
21:21:91:55:60:55:25:06:be:9e:9d:e1:47:c5:44:a3 steve@station.itj-sk.com
[steve@station ~]$

Distribute the Your Public Key

[steve@station ~]$ ssh-copy-id -i .ssh/id_rsa.pub server1
15
steve@server1's password: [fedora]
Now try logging into the machine, with "ssh 'rhstation1'", and check in:

  .ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.
[steve@station ~]$ ssh server1
Enter passphrase for key '/home/steve/.ssh/id_rsa': [fedora]
Last login: Fri Nov 11 12:08:04 2010 from station.itj-sk.com
[steve@server1 ~]$

Now that we copied our public key to the server... we no longer require a password. Now lets eliminate the passphrase to a "sort of" single sign-on.


Step 3: Implementing that "sort of" single sign-on
Now... this part requires some of the GUI for ease... but you can do this manually as well.
Using the GUI, in the system menu, under preferences, and more preferences, you will find "Sessions." In Sessions, on the startup tab. On the startup tab, you will add an entry for "ssh-add"

It will add this entry in your ~/.config/autostart directory.

[steve@station ~]$ cat .config/autostart/ssh-add.desktop
[Desktop Entry]
Name=No name
Encoding=UTF-8
Version=1.0
Exec=ssh-add
X-GNOME-Autostart-enabled=true
[steve@station ~]$

Once you have this entry... log off and log back in.. or ctrl+alt+backspace. It pretty much does the same function as logoff. Once you log back in, you will receive a prompt to enter your passphrase. Enter your passphrase this one and single time after you enter your password.

Now open a shell and ssh.

[steve@station ~]$ ssh -X server1
Last login: Fri Nov 11 12:08:04 2010 from station.itj-sk.com
[steve@server1 ~]$

For those who do not know, -X will invoke the automatic transfer for X Server to your desktop. So if you execute for example, "firefox" while ssh -X session is open to the server... Firefox will appear on your desktop. but will have caption next to "Mozilla Firefox" at the top that specifies that its from Server1 as its appearing on your desktop at Station.

All you need to remember is to ssh-copy-id to each system you want to SSH to without being questioned for your password. Here is a verbose look at ssh -v server1.

[steve@station ~]$ ssh -v server1
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to server1 [192.168.1.101] port 22.
debug1: Connection established.
debug1: identity file /home/steve/.ssh/identity type -1
debug1: identity file /home/steve/.ssh/id_rsa type 1
debug1: identity file /home/steve/.ssh/id_dsa type -1
debug1: loaded 3 keys
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'server1' is known and matches the RSA host key.
debug1: Found key in /home/steve/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Unknown code krb5 195
debug1: Unspecified GSS failure.  Minor code may provide more information
Unknown code krb5 195
debug1: Unspecified GSS failure.  Minor code may provide more information
Unknown code krb5 195
debug1: Next authentication method: publickey
debug1: Offering public key: /home/steve/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
Last login: Fri Nov 12 12:29:13 2010 from station.itj-sk.local
[steve@server1 ~]$

Next step is to repeat step 1 on the servers to create your entry in sudoers. Then you have a standadized way of performing functions on all of your systems.
You can ssh bounce in between servers like nothing with your ssh-agent providing your key to all the servers you copied your public key to.

I hope this helps anyone looking for a single sign-on like function to manage their infrastructure.


Feel free to send me a private message or email for any suggestions for new how-to's from myself.
Have a great thanksgiving all!!!

[hellork]

Very helpful. Thanks! What I like about your ssh auto login is it makes it easy to browse remote servers with Nautilus. The ssh browsing used to require installing fuse-sshfs, but it seems to work without it in F14. Before logging in with ssh or anything, just open Nautilus and type CTRL-L and in the address bar type ssh://server1 and it will open up the remote server's folders. You can drag and drop, copy, back things up to and from remote machine, bookmark remote folders, etc.

Now go here and set up avahi: http://fedorasolved.org/Members/fenr...tworking-avahi on all the computers that need to print things.
Then set up any printers to be shared thru cups: http://printserver1:631
Presto! All the printers on the network automatically detected and set up. That's zero configuration.

With avahi set up you can browse to servers by name without a hosts file or typing the IP address, e.g. ssh://server1.local if local is the domain.

[Sicinthemind]

Thanks for the feedback Hellork!

I'm working on setting up some video instructionals in RHEL5/6. Just working on the scripting portion of video making because nothing is more aggrivating than stumbling on some words while you're trying to explain a process while recording.

[pete_1967]

Could admin change the title of this thread, removing 'the right way' because that implies that these are generally accepted best practises - which they aren't.

A note to key based authentication: the instructions do NOT disable password or root logins nor it necessarily enable the key based authentication either. You need to ensure that your sshd_config is correctly configured. In addition, it is preferable to configure sshd to look for authorised_keys outside user's home directory, e.g. in /etc/ssh/authorised_keys/ to ensure that if user's account is compromised on server (e.g. his private keys is copied - and it being password-less, makes crakers dream come true - or if you only do as instructed above, password is crakcked), the intruder can't add their own keys or change the user's disabling the access for the legitimate user. Of course, adding user to sudoers with blanket permissions makes that moot because user then has all rights - in other words, NEVER grant all privileges to the user on a remote machine (on on a desktop either), only allow privilege escalation with sudo when absolutely necessary.

If you wish to avoid entering your key password every time, you can easily add it to the keyring with ssh-add [path_to_key] for the session - add it once until you log out and even if key is then copied, it is useless unless password is cracked.

[Dangermouse]

Could admin change the title of this thread, removing 'the right way' because that implies that these are generally accepted best practises - which they aren't.

Agreed and Done

[DBelton]

agreed Dangermouse.
adding to what pete_1967 above stated, directly editing the /etc/sudoers file is not the correct way to add things to it, either.

[Sicinthemind]

DBelton,

Visudo is simply a streamline text edit only to the sudoers file. Implementation of a pipe has no bearing on right or wrong way to add sudoers. If the end result is the same, there's no right or wrong way of getting from Point A to Point B.

Granted, yes, there are some files that shouldn't be just directly modified without comprehension of the file or its relationship with other components in the operating system, however, we're discussing modifications made to files in a file based operating system.

Vim for a new user is fairly difficult to explain in a single post. Explaining full use of vim and its features would require its own chapter of detail.

Pete,

Your input is very valid and respected. However, your criticism is on the advanced topics where this is simply a basic instruction set.

There's a best practice method and just getting it done. This is just getting it done in an example format. Also if you note, I simply stated that this was a basic administrative access. There was no suggestion that this was the best practice, but simply an example of correct configurations. For obvious reasons you would not want ALL commands to be accessible via sudo for any user but root.

While your comprehension in linux may be advanced, for those who aren't advanced in Linux, this is some good grounding for them to get the general idea. I'm pretty sure I don't goto forums to lookup chapters of information on how to manage a linux system. I purchase technical guides or self-paced training material for this... So this is just the basic instruction set.

[pete_1967]

Originally Posted by Sicinthemind

Pete,

Your input is very valid and respected. However, your criticism is on the advanced topics where this is simply a basic instruction set.

There's a best practice method and just getting it done. This is just getting it done in an example format. Also if you note, I simply stated that this was a basic administrative access. There was no suggestion that this was the best practice, but simply an example of correct configurations. For obvious reasons you would not want ALL commands to be accessible via sudo for any user but root.

While your comprehension in linux may be advanced, for those who aren't advanced in Linux, this is some good grounding for them to get the general idea. I'm pretty sure I don't goto forums to lookup chapters of information on how to manage a linux system. I purchase technical guides or self-paced training material for this... So this is just the basic instruction set.

Which is fair enough, but bear in mind that people not so technically experienced are usually ones to follow guides like this, and by following your instructions they actually make their system less secure simply because they assume that that's all there is to it.

Think a person not understanding what they are doing, following your advice, they may be having a weak passwords and root login allowed in their server but they think they now have only key authentication enabled and are bomb proof. Things like password-less keys should only ever be used in cases where you are not able to enter the password every time key needs to be read (e.g. enabling ssl on a server) and it is no more difficult to teach people to use ssh-add during the session than it is to teach them how to create private key without password - difference being that 1st option is (more) secure than second. They are the ones who, after following your tutorial, assume that their system is now more secure than it was. Omitting info on proper sshd configuration, especially disabling password and root logins is dangerous for example.

In the end of the day, your tutorial is more fitting to experienced users (who know all the stuff already) who know and understand the dangers your instructions are from security point of view rather than to someone who barely understand difference between root and regular user.

It's better to teach people how to do things the right way first (it's no more difficult for a newbie to follow a step by step guide for the right way than it is for the wrong way), they can then make educated decision to do things wrong way rather than teach them bad habits first and then try to make them learn the right way. At least without big flags warning them about the dangers of doing things the "lazy" way (which I think yours is) - which was the main reason I flagged the most serious security issues in my post.