Showing posts with label Linux. Show all posts
Showing posts with label Linux. Show all posts

Making a custom sudoers file

2 comments
For a sysadmin, allowing access to sudo is nerve-wracking, particularly if you work in an environment where you seem to be the only one concerned about security, where passwordless accounts are abundant and all users are made administrators for ease of access. This is most common in OS X clusters, as Linux does not permit empty passwords by default. A properly configured sudoers file is very important.

This assumes you have already sorted your users into appropriate groups, such as removing guests from the 'wheel' group.

Defining command and user aliases
The first section to edit will be # Cmnd alias specification. You can define groups of commands such as:

Cmnd_Alias SYS_COMMANDS = /sbin/unmount, /sbin/mount

Cmnd_Alias SERVICES = /bin/ls, /bin/cat, /sbin/halt, /sbin/reboot,
/sbin/shutdown

Cmnd_Alias ADMIN_TOOLS = /usr/bin/passwd, /bin/chmod, /bin/chown, /bin/chgrp

Cmnd_Alias EDITING = /usr/bin/vi

Cmnd_Alias STORAGE = /sbin/fdisk, /sbin/sfdisk, /sbin/parted,
/sbin/partprobe

You can also append options to the commands; for example, creating an alias for /usr/bin/su - Guest, meaning that it is permissible to use sudo su - Guest, but not sudo su - some-other-user.

User aliases operate using the same syntax:
User_Alias      GUESTS  = guest, user, bob
User_Alias ADMINS = joe, alice
Limiting and denying commands to users and groups
Next, edit the # User privilege specification section. A % denotes a group, while a string without indicates a user:
# root and 'wheel' group users can run all commands as long as they authenticate
with their passwords
root ALL = (ALL) ALL
%wheel ALL = (ALL) ALL

# only bob can use storage tools
bob ALL = STORAGE

# ADMINS can use chmod, chown, chgrp and passwd, but they can't change root's password
%ADMINS ALL = ADMIN_TOOLS !/usr/bin/passwd root

# 'admin' group users can use all commands in the EDITING alias with a password, and
all commands in SYS_COMMANDS and SERVICES without authenticating; but can't use any
other commands
%admin ALL = EDITING, NOPASSWD:SYS_COMMANDS,SERVICES

# Guest users, who don't have passwords, can only mount and unmount drives
%guest ALL = NOPASSWD:SYS_COMMANDS

# joe can authenticate to use any command in /bin except for chmod, chown, chgrp,
chown and vi, but he can use /bin/find without authenticating (there is no real
usefulness to NOPASSWD in this case)
joe ALL = /bin, NOPASSWD:/bin/find, !/bin/chmod, !/bin/chgrp,
!/bin/chown, !EDITING

# alice can su to any user except for root, but without flags (su - user is not allowed)
alice ALL = /usr/bin/su [!-]*, !/usr/bin/su *root*

# everybody needs to be able to kill a program when it hangs without authenticating
ALL ALL = NOPASSWD:/bin/kill


Defining default settings
A few useful Defaults specifications:

# only allow one failed password attempt
Defaults passwd_tries += "1"

# the message when a user types an incorrect password
Defaults badpass_message += "And just what do you think you're doing, Dave?"

# this prevents sudo from being used in a script; the user must be logged in
Defaults requiretty


Read Full Post

Enable root login from LAN only

1 comments
Having SSH access to the root account can be catastrophic if someone ever does succeed in breaking into your machine. While the majority of sysadmins turn into rabid wolves upon mention that your machine allows root access, at times it may be necessary.

This should work on any UNIX-based operating system running OpenSSH 4.3p or later. You may determine the version of OpenSSH by using ssh -V.

On Linux, edit /etc/ssh/sshd_config. On Macs, edit /etc/sshd_config. Locate the line that defines PermitRootLogin, uncomment if it is commented out, and change its value to no.

On a separate line, add the following:
Match Address 192.168.2.*,127.0.0.1
      PermitRootLogin yes

This will allow root to login exclusively from your LAN, while denying all attempts from outside.

Tips: Extra security features to go along with this would be:

- Denying usage of 'sudo su'
- Disabling passwordless, guest, or otherwise anauthorized users from using 'su'
- Using the above Match Address syntax to only allow root to login using a publickey, not passwords
Read Full Post

Streaming audio between Linux machines

0 comments
My laptop, being my mobile machine, contains all of the music I listen to on a daily basis. At home, it's nice to hook it up to my stereo so I can hear it throughout the house. However, while there is music playing, the laptop is no longer mobile and stuck within a three-foot leash of the stereo.

Having recently resurrected an old desktop to function as a MythTV, DVD-watching and backup machine and wired it into the stereo, it was extremely simplistic to stream the audio wirelessly from my laptop and have it be received on the desktop, to be piped into the stereo.

For this guide, I am utilizing Fedora 9 on the laptop (client) and freshly-installed Fedora 12 (server) with glibc on the desktop, although this should work on any Linux distro. You will need the following packages on both machines:
pulseaudio
pulseaudio-module-zeroconf
paprefs
padevchooser

Setting up the sound server

First, on the server, launch paprefs from the terminal. It can also be accessed through the PulseAudio Device Chooser (located in Applications -> Sound & Video), under "Configure Local Sound Server." In the Network Server tab, check all applicable boxes:



You may also enable Multicast/RTP, although this is not required for a simple sound server.


Now, start up padevchooser. An alert should appear notifying you of a new sound server.










Select the new server as the default.














Setting up the sound streamer

Now launch padevchooser on the client, and select the same server.







Configure your sound properties to use PulseAudio as the audio output. This will vary by distribution and by version, as the pictured F9 gnome-sound-properties dialog does not exist in F12.






















In some cases, such as XMMS, you may have to configure its output manually, in addition to the system-wide output.

In fact, if possible, it is far safer to configure individual programs to use Pulse if it is not already your sound device -- those of us using OSS or ALSA for system-wide sound, for example.















You do not have to have padevchooser open all the time. You can close it once the default server has been selected. Although the client's volume does not communicate to the PulseAudio server, the individual applications should, (such as XMMS's native volume control) as well as the volume on the server.

You may have to open ports 4713 and 59352 on both machines before the audio will connect.
Read Full Post

Copy-pasting on the Linux command line

0 comments
On Mac OS X, since the Apple key is used for copying instead of Ctrl, copy-pasting works within the Terminal. On Linux, Ctrl-c sends an interrupt signal.

Instead, use Ctrl-Shift-c to copy within a terminal, and Ctrl-Shift-v to paste. Other similar commands are:
  • Ctrl-Shift-t : Create a new tab
  • Ctrl-Shift-w : Close the tab
  • Ctrl-Shift-q : Close the entire window, tabs and all
  • Ctrl-Shift-n : Create a new window

Read Full Post

Fixing a slow SSH prompt

1 comments
For owners of multiple Linux machines, it's happened to all of us -- the machine in the living room responds immediately to SSH; but it takes forever to log in to the one in the closet, although it does succeed eventually.

This happens because of the SSH client attempting various authentication methods. Using ssh -vvv user@host, the output of a slow connection will look something like this:

debug3: check_host_in_hostfile: filename /home/drsavoye/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 11
debug1: Host '192.168.2.107' is known and matches the RSA host key.
debug1: Found key in /home/drsavoye/.ssh/known_hosts:11
debug2: bits set: 499/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/drsavoye/.ssh/id_rsa (0xb7f541a8)
debug2: key: /home/drsavoye/.ssh/identity ((nil))
debug2: key: /home/drsavoye/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug3: Trying to reverse map address 192.168.2.107.
debug1: Unspecified GSS failure. Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure. Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure. Minor code may provide more information


debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/drsavoye/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/drsavoye/.ssh/identity
debug3: no such identity: /home/drsavoye/.ssh/identity
debug1: Trying private key: /home/drsavoye/.ssh/id_dsa
debug3: no such identity: /home/drsavoye/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
root@192.168.2.107's password:


In this case, GSSAPI is failing alongside publickey-authentication, but unlike publickey, takes much longer to give up. To disable it, edit /etc/ssh/sshd_config and remove or comment out the lines #GSSAPIAuthentication yes and #GSSAPICleanupCredentials yes.
Read Full Post

Use VNC on an existing X display

0 comments
VNC can be incredibly useful, particularly in a work environment where a troubled coworker could be in an entirely separate subdivision of the building. Mac OS X's proprietary implementation of VNC, known as Screen Sharing, will allow control of whoever is logged in at the moment, while under Linux starting a VNC server will create an entirely new X session independent of anyone already using the machine.

In order to use VNC on Linux in the same way as Screen Sharing, we can use a small VNC server called x11vnc. This link is a standard tarball; there may also be a binary distribution available at the x11vnc website.

To start the VNC server, use:
x11vnc -rfbauth ~/.vnc/passwd -display :0 -auth guess

If you have used VNC before, ~/.vnc/passwd will already exist. If not, you can use vncpasswd to generate one.

The auth switch will depend on your display manager. If you are using xinit, -auth guess should be able to detect the current session cookie, but if you are using GDM you will have to provide it manually.

If you are using xinit and x11vnc cannot detect the cookie, running ps auxw | grep serverauth will return something similar to
xinit /etc/X11/xinit/xinitrc -- /usr/bin/X :0 -auth /home/drsavoye/.serverauth.3033
/home/drsavoye/.serverauth.3033 will replace the guess parameter.

If you are using GDM, the cookie can be found by running ps auxw | grep cookie, which will return
/usr/bin/Xorg :0 -br -verbose -auth /var/run/gdm/auth-cookie-XX756E9U-for-gdm -nolisten tcp
/var/run/gdm/auth-cookie-XX756E9U-for-gdm will replace the guess parameter.

Now, on the client side, you can use whichever VNC viewer you choose.
Read Full Post

Disabling / enabling SSH timeout

0 comments
Read from remote host ariel.localhost: Connection reset by peer
Connection to ariel.localhost closed.


There are two ways to prevent SSH from timing out when left idle. The first is on the server, the second on the client. Both require editing the SSH config file.

The configuration is split between two files: On Linux, /etc/ssh/ssh_config and /etc/ssh/sshd_config. On OS X, they tend to reside in /etc/ssh_config and /etc/sshd_config. ssh_config is the configuration for the SSH program itself on the client, while sshd_config is the configuration for the SSH daemon on the server.

On the server machine uncomment, or add if it does not exist, the line:
ClientAliveInterval 60

On the client side, the line is:
ServerAliveInterval 60

The interval is in seconds, so you may specify any time period you like. On the server side, this defines the timeout interval after which no data has been received from the client that it should send a quick poke to request a response from the idle client. If the interval is set to 0, or the line does not exist, these messages will not be sent.

Similarly, on the client side, the interval is how often it should send a message to the server indicating that the connection is still active.

You must restart the sshd daemon after editing the file.
On Linux:
/etc/init.d/sshd restart

and on OS X: launchctl unload /System/Library/LaunchDaemons/ssh.plist and
launchctl load /System/Library/LaunchDaemons/ssh.plist

You can also restart sshd on OS X by unchecking and rechecking the box in System Preferences:


Read Full Post

How to enable text-only boot in newer Fedora versions

0 comments
Upgrading for the first time to Fedora 10, I was disappointed to see that my runlevel settings did not seem to carry over through the upgrade, and had to hit Esc in order to see the kernel messages.




Fedora 10+ distributions have replaced the anaconda bootloader with plymouth, which is not affected by /etc/inittab, although setting the runlevel will still determine the appearance of the login prompt. In order to disable this bar, you must instead edit /etc/grub.conf or /boot/grub/grub.conf, the former being a symbolic link to the latter.

Remove rhgb quiet from the boot parameters:
title Fedora (2.6.27.5-117.fc10.i686)
root (hd0,9)
kernel /boot/vmlinuz-2.6.27.5-117.fc10.i686 ro root=LABEL=/ rhgb quiet
initrd /boot/initrd-2.6.27.5-117.fc10.i686.img

Fedora 10+ also comes with a pretty animated boot sequence instead of the progress bar. To enable it, you must add vga= with the appropriate framebuffer resolution to the boot parameters. To find the framebuffer resolution, use the following table:

Colours   640x480 800x600 1024x768 1280x1024 1600x1200
--------+---------------------------------------------
256 | 769 771 773 775 796
32,768 | 784 787 790 793 797
65,536 | 785 788 791 794 798
16.8M | 786 789 792 795 799
To enable the graphical boot in in plymouth, add the vga resolution to /etc/grub.conf. vga=792 is the standard resolution for most modern monitors. Although the xrandr command can show your current screen resolution if you don't know it or it isn't listed, I have had trouble getting plymouth to accept non-standard resolutions, such as those on widescreen laptops. However, the resolution you set will affect only the boot screen and not the GDM/X11 display, so it is purely aesthetic entertainment while you wait for it to boot.
title Fedora (2.6.27.5-117.fc10.i686)
root (hd0,9)
kernel /boot/vmlinuz-2.6.27.5-117.fc10.i686 ro root=LABEL=/ rhgb quiet vga=792
initrd /boot/initrd-2.6.27.5-117.fc10.i686.im

Read Full Post

Why does SSH refuse my RSA publickey?

0 comments
After successfully generating RSA keys and copying the public key to the remote authorized_hosts, I have encountered many times a message like this when trying to ssh in:

Executing: program /usr/bin/ssh host
office-minimac, user (unspecified), command scp -v -t
~/.ssh/authorized_keys
OpenSSH_5.1p1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to office-minimac [192.168.2.103] port 22.
debug1: Connection established.
debug1: identity file /home/drsavoye/.ssh/identity type -1
debug1: identity file /home/drsavoye/.ssh/id_rsa type 1
debug1: identity file /home/drsavoye/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1
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 'office-minimac' is known and matches the RSA host key.
debug1: Found key in /home/drsavoye/.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
No credentials cache found

debug1: Unspecified GSS failure. Minor code may provide more
information
No credentials cache found

debug1: Unspecified GSS failure. Minor code may provide more
information


debug1: Next authentication method: publickey
debug1: Trying private key: /home/drsavoye/.ssh/identity
debug1: Offering public key: /home/drsavoye/.ssh/id_rsa
debug1: Authentications that can continue:
publickey,gssapi-with-mic,password
debug1: Trying private key: /home/drsavoye/.ssh/id_dsa
debug1: Next authentication method: pa
ssword
drsavoye@office-minimac's password:


This happens when the permissions of the .ssh directory or any of its items are incorrect. Commonly the mode of the .ssh directory itself will be set to 775 or 777; setting group write permissions on any of the files will cause this effect. The correct permissions of the .ssh directory:
~/.ssh{drsavoye@ushuaia} pts/4$ ls -la
total 40
drwxr-xr-x 2 drsavoye drsavoye 4096 feb 26 08:31 .
drwxr-xr-x 143 drsavoye drsavoye 20480 feb 26 08:31 ..
-rw-r--r-- 1 drsavoye drsavoye 408 feb 25 22:01 authorized_keys
-rw------- 1 drsavoye drsavoye 1671 feb 25 22:01 id_rsa
-rw-r--r-- 1 drsavoye drsavoye 405 feb 25 22:01 id_rsa.pub
-rw-r--r-- 1 drsavoye drsavoye 810 feb 25 22:01 known_hosts

If they differ, use chmod 755 ~/.ssh and chmod 644 ~/.ssh/* to correct them.

Tip: using ssh -vvv {host} will return this verbose output.
Read Full Post

Test Post

0 comments
blal
fklsfksdfsdlfksd lfmskld mfkls mklsmdfksmd kl
s fsdm fklsm fkmsk mf sfmls fsldmf mslfmsd

skfs
Read Full Post