Archive for the ‘Techie Stuff-Linux’ Category

X11 Forwarding problems with Ubuntu 10.04 when IPV6 disabled

Thursday, August 30th, 2012

I had problem hunting down a “Error: Can’t open display:” bug with X11 forwarding today. There were many fixes suggested online but none that solved my problem. Assuming you have setup X11 forwarding on the remote machine end (i.e. /etc/ssh/sshd_config) has entries such as:


X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes

Logging in to this remote machine from a local PC/MAC with ssh -X or ssh -Y should work. Wrong (for me). Here is what I saw happen on Ubuntu 10.04 and Ubuntu 10.10 because I had IPv6 disabled.


$xclock
Error: Can’t open display:

I decided to verify whether the request was being indeed passed on to the Remote_computer by turning on the debug messages with -v.

From Local Machine:

$ssh -v

I saw this among many other debug lines:


debug1: Requesting X11 forwarding with authentication spoofing.

Looks good. So, what’s the problem?

At Remote Machine:


$ vi /var/log/auth.log

I saw this at the bottom of the log pile.


Aug 30 19:03:40 sshd[2306]: error: Failed to allocate internet-domain X11 display socket.

Hmm, it turns out that the daemon was unable to create a display socket. Why? I had disabled IPv6
on the remote machine in some other context. You can verify if this is the case with you by:


cat /proc/sys/net/ipv6/conf/all/disable_ipv6

A return value of 0 means IPv6 is enabled, a value of 1 means disabled.

I had disabled ipv6 earlier by the following changes in /etc/sysctl.conf


#disable ipv6
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

Simple solution. On Remote Machine, we have to explicitly say that we want to bind to the IPv4 family.


$sudo vi /etc/ssh/sshd_config

AddressFamily inet
Port 22


That’s what was needed. service sudo ssh restart didn’t do the trick. I simply restarted the machine and tried again.

Making Net::SCP work (CPAN, FTP_PASSIVE, sudo, visudo)

Wednesday, April 11th, 2012

This is a short note regarding the motions I had to go through to make the perl module Net::SCP work. This is a note to self.

Step 0 -  CPAN’s documentation is pretty straight-forward. http://search.cpan.org/~ivan/Net-SCP-0.08/SCP.pm
Step 1 - Installation


$cpan
install Net::SCP

Oops.. Needs sudo permissions to perform make install


$sudo cpan

What!! Can not fetch LWP/FTP. Why? It just did it. FTP_PASSIVE is set as an environment variable (see my previous blog). Now what’s wrong.

Turns out sudo filters out most environment variables (FTP_PASSIVE not picked up). The fix is to edit /etc/sudoers


env_keep = ..... FTP_PASSIVE .....

So, I tried : sudo /etc/sudoers Read-only - Er.. For Root? Oh that’s a security feature, so let’s try : sudo visudo Err visudo doesn’t exist. It’s not in $PATH. All right sudo /usr/sbin/visudo.

Problem solved. Now sudo cpan can make install in peace and I can get around pesky firewall’s with passive FTP as root.

Oh and a code dump of what I was testing.


#!/bin/perl
use strict;
use warnings;
use Net::SCP;

#used ssh-keygen -t rsa to generate key on local machine
#used ssh-copy-id -i ~/.ssh/id_rsa.pub [remote_username]@[remote_machine] to share public key from [local_machine] to [remote_machine]

#otherwise replace Net::SCP->new("[remote_machine_name]“,”PASSWORD”);

my $scp;
$scp = Net::SCP->new(”[remote_machine]”);
$scp->login(”[remote_username]”);
$scp->put(”[what to put]”,”[where to put]”) or die $scp->{errstr};

This was pretty straight-forward.

Giving a Root User Remote Access to a mySQL database

Thursday, March 29th, 2012

I happen to be within a firewalled environment and I wanted to simply login as the root user for a mysql server from a development machine. Well, security purists would scoff at the idea, but I needed it (running some scripts as root from the dev machine).

The issue is mysql out-of-the-box is configured to explicitly dis-allow root from log in from anything other than the local machine.

Enabling remote access for any user is easy. Most of us have gone through this as part of mysql setup :

Step 1: On the mySQL server:

sudo vi /etc/my.cnf

Look for the line that says

bind-address=YOUR-SERVER-IP

Change that to:

bind-address=YOUR-SERVER-IP

Step 2: Restart mysql service

sudo /etc/init.d/mysql restart

All’s well. As long as individual users have been given permissions to a database through something like:

GRANT ALL ON *.* TO foo@bar IDENTIFIED BY 'PASSWORD';

Now what if I want the same for root? We need to update the allowed permissions for root on the server side with the following simple steps.

mysql -uroot -p

To Check what’s the current state of user,host login permissions we’ll lookup the default mysql table elegantly named: mysql.


mysql> use mysql;
mysql> select host, user from user;
+—————+——————+
| host | user |
+—————+——————+
| myhostname | root |
| localhost | root |
| % | myusername |
| myhostname | myusername |
+—————+——————+
3 rows in set (0.00 sec)

It seems that a non-root user ‘myusername’ was indeed allowed to login from anywhere. This is not the case for root. Now I’ll update the ‘myhostname’ entry to use the wildcard ‘%’, and then issue the command to reload the privilege tables.

mysql>update user set host=’%’ where user=’root’ and host=’myhostname’;
mysql>flush privileges;

Now, here’s the catch: It’s important to update the entry where host=’myhostname’. Inserting a fresh row will not work. Now you should be able to login from a remote machine (say a development box) to the mysql server as root. Any perl scripts will work fine. If this is not enabled on the remote machine, mysql command-line or any scripts for instance will look for ‘root’@'the-development-machine’ instead of ‘root’@'myhostname’. Thereby confusing the heck out of you.

$mysql -u root -h myhostname -p

This simple fix gave me a headache for sometime. So, this is a note to self.

Passwordless Log in to Linux

Saturday, November 5th, 2011

I was annoyed with having to enter passwords across multiple machines multiple times. this is something straight-forward..

On the Server (Machine to connect to):

Ensure PublicKeyAuthentication and RSA Authentication is accepted


vi /etc/ssh/sshd_config

Uncomment lines:


RSAAuthentication yes
PubkeyAuthentication yes

Restart SSH server


CentOS / RHEL / Fedora / Redhat Linux Restart SSH
# /etc/init.d/sshd restart
OR
# service sshd restart

Debian / Ubuntu Linux Restart SSH
# /etc/init.d/ssh restart
OR
# service ssh restart

FreeBSD Restart SSH
# /etc/rc.d/sshd restart

UNIX Restart SSH
# kill -HUP `cat /var/run/sshd.pid`

On the Client (Machine to connect from)

Create public/private keypairs (~/.ssh/id_rsa and ~/.ssh/id_rsa.pub)


ssh-keygen -t rsa


Generating public/private rsa key pair.
Enter file in which to save the key (/home/aalap/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/aalap/.ssh/id_rsa.
Your public key has been saved in /home/aalap/.ssh/id_rsa.pub.

Although it is very much possible to copy the contents of ~/.ssh/id_rsa.pub (on the client) to ~/.ssh/authorized_keys (on the server), it is easier to do it from the client side using ssh-copy-id


ssh-copy-id -i ~/.ssh/id_rsa.pub username@remote_host

Okay, I have multiple machines to connect to: What should I do? Use the same key-pair?
Yes, you probably can, what that means is that if its gets compromised you will have to go to each and every system you use the same shared key on and revoke the public key manually. There is a security risk but it works fine.

Setting up SSH-RSA with Putty - No Password necessary

Monday, August 2nd, 2010

[Source]

SSH Protocol

SSH (Secure Shell) is a network protocol that provides secure access to a computer (mostly Unix based).  When you want to connect to a remote Unix server, SSH is one way of accessing the server. SSH is very powerful by combining both security of the data transmitted over network and accessibility to the remote system. SSH protocol works between two computers by a client-server architecture. When a client computer connects to the server, the server requires the client to authenticate itself. There are different ways a client can authenticate itself to the server. A typical authentication mode will be to enter a password when logging into a remote system. In this howto we can explore another mode of authentication in which server doesn’t require a password to be entered by the user. This mode will be very useful if you are connecting to a remote system frequently and dont want to enter the password everytime.

Before we see the steps, just to give a background on the components involved:

SSH SERVER

When you need to connect to a remote computer via SSH, that computer should have a SSH server running on it. All Unix based distributions ( Linux, Mac OSX etc.,) includes a ssh server. For Windows based systems Cygwin can be used as an SSH server.

SSH CLIENT

Assuming your remote computer has an SSH server running on it, to connect to that computer you would need a SSH client on the local computer. On Unix based systems, SSH clients are available as command line utilities. For Windows based systems, putty is an excellent client. Check here for more information about putty.

CONFIGURATION

  1. We start the configuration at the client windows computer. Download the latest version of Putty.exe and Puttygen.exe from here. Using the Puttygen tool we have to generate an authentication key. This key will serve as a substitute for the password that will be entered during login.
  2. Start puttygen.exe by double clicking on the executable. The following window opens up.
  3. Leave the default ‘SSH-2 RSA’ selection and click on the ‘Generate’ button. The following window opens. Move mouse randomly over the empty space below the progress bar to create some randomness in the generated key.
  4. Don’t enter any key phrase. Click on ‘Save private Key’ button. Click ‘Yes’ on the window asking for confirmation for saving the key without a password.
  5. Save the key file to a safe location (Let us assume you will be saving it as C:\Personal\SSHKey\Laptop.ppk).
  6. Now you can close the Puttygen window.
  7. Open the Laptop.ppk file in a notepad. Copy the four lines under ‘Public-Lines’ section to windows clipboard.
  8. Now open putty and connect to the remote system using the user id you want to use for future no password connections. (Let us assume you will connect to the remote machine using user name ‘ubu’. This time when you login, you have to provide the password at the prompt. Future logins won’t require this password.
  9. Under the logged in user’s  home directory there will be .ssh directory, under that create a new  file called authorized_keys using a text editor such as vi. (In our case the file will be created under /home/ubu/.ssh/authorized_keys).
  10. Type the word ” ssh-rsa ” (including  spaces on both ends of the word) and paste the 4 lines copied from step 7. Remove the carriage return at end of each line, merging four lines into one single line. Be careful not to delete any characters while doing that.  Final output should like the following window.
  11. Now we have configured SSH server, its time to test our setup.
  12. On the local system, open Putty, enter the ip address details of the remote system.
  13. Now from the left navigation, select Connection -> Data. Enter ‘ubu’ as ‘Auto-login username’ on the right panel.
  14. Again from the left navigation menu, scroll down and select Connection -> SSH -> Auth. Enter the path of the saved private key file ( In our case C:\Personal\SSHKey\Laptop.ppk ). Leave other defaults as such and press open button.
  15. Now the putty connects to the remote SSH server and there won’t be any password prompt here after :-).