Tag Archives: ssh

Change the default SSH port and alter SELinux context to match

Security through obscurity is not something one would generally recommend. But to thwart the effort of automated scanners changing the default OpenSSH port will yield you less pain in every day life. This will not fend off directed attacks or nullify vulnerabilities or bad security design.

Should you see an error message such as

shd[14221]: error: Bind to port 9898 on 192.168.0.50 failed: Permission denied

it indicates that the system prevented the daemon to bind that port. Most likely SELinux.

The instructions provided will be valid on Fedora 14/15, CentOS 6, RHEL 6, Scientific Linux 6 and newer versions.

To change the default SSH port you need to do the following.

  • Stop the SSH daemon
  • Alter the /etc/ssh/sshd_config with your new port
  • Alter the SELinux context with semanage
  • Start the SSH daemon

Stop the SSH daemon

# service sshd stop

Alter the /etc/ssh/sshd_config with your new port

Alter the configuration file with your favorite editor, in my case “nano”.

# nano /etc/ssh/sshd_config

Alter the port configuration parameter change the following line

Port 22

to

Port 9898

Alter the SELinux context with semanage

# semanage port -a -t ssh_port_t -p tcp 9898

Initially you would think the following would work. But it will not. For it to work you would have to alter the policy in the selinux-policy package, rebuild and install it. So skip it, but now you know why.

# semanage port -d -t ssh_port_t -p tcp 22

Start the SSH daemon

# service sshd start

// CrashMAG

Public key authentication with SSH. Both with and without a password.

This article will run through quick and easy examples for setting up public key authentication with SSH. I will include one example that requires a password and one that does not. Typically used for scripts.

I will assume you know why you want to either use the one or the other. Public key authentication can only be set up on a per user/system basis, keep that in mind.

Public key authentication without a password

This the least secure option. It all boils down to how well secured your private key is. (.ssh/id_dsa)

  1. Create a key pair. (Private & public key)
  2. Copy the public key to the remote system.
  3. Log on the remote system.

Create a key pair

[user@localsystem ~]$ ssh-keygen -t dsa

Here’s what you’ll see when you run through this procedure. (“Press [ENTER]” are my comments)

[user@localsystem ~]$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_dsa): Press [ENTER]
Created directory '/home/usr/.ssh'.
Enter passphrase (empty for no passphrase): Press [ENTER]
Enter same passphrase again: Press [ENTER]
Your identification has been saved in /home/user/.ssh/id_dsa.
Your public key has been saved in /home/user/.ssh/id_dsa.pub.
The key fingerprint is:
29:d1:34:6c:53:2b:96:e6:ea:28:fd:c5:3a:cb:0f:65 user@localsystem
The key's randomart image is:
+--[ DSA 1024]----+
|       .o..      |
|       o+o .     |
|      ..*..      |
|       = o       |
|      . E        |
|       *         |
|   .  o o        |
|  . .+.+         |
|   ...*+.        |
+-----------------+

Copy the public key to the remote system

[user@localsystem ~]$ ssh user@remotesystem

If you don’t set the permissions in this step SSH will refuse the public key even if it’s there due to bad ownership.

[user@remotesystem ~]$ mkdir .ssh
[user@remotesystem ~]$ touch .ssh/authorized_keys
[user@remotesystem ~]$ chmod -R u=rwx,go= .ssh
[user@remotesystem ~]$ exit
scp ~/.ssh/id_dsa.pub user@remotesystem:.ssh/authorized_keys

Enter your password when asked, and you’re done.

Log on the remote system

[user@localsystem ~]$ ssh user@remotesystem

Public key authentication with password

This is the route you want to go. Once done, you should also disable logins with passwords only. Do this by editing the /etc/ssh/sshd_config file and add/modify the following parameter “PasswordAuthentication no”. Also make sure “PubkeyAuthentication” is set to “yes”.

  1. Create a key pair. (Private & public key)
  2. Copy the public key to the remote system.
  3. Log on the remote system.

Create the key pair

[user@localsystem ~]$ ssh-keygen -t dsa

Here’s what you’ll see when you run through this procedure. (“[Your Password]” and “Press [ENTER]” are my comments)

[user@localsystem ~]$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_dsa): Press [ENTER]
Created directory '/home/usr/.ssh'.
Enter passphrase (empty for no passphrase): [Your Password]
Enter same passphrase again: [Your Password]
Your identification has been saved in /home/user/.ssh/id_dsa.
Your public key has been saved in /home/user/.ssh/id_dsa.pub.
The key fingerprint is:
29:d1:34:6c:53:2b:96:e6:ea:28:fd:c5:3a:cb:0f:65 user@localsystem
The key's randomart image is:
+--[ DSA 1024]----+
|       .o..      |
|       o+o .     |
|      ..*..      |
|       = o       |
|      . E        |
|       *         |
|   .  o o        |
|  . .+.+         |
|   ...*+.        |
+-----------------+

Copy the public key to the remote system

[user@localsystem ~]$ ssh user@remotesystem

If you don’t set the permissions in this step SSH will refuse the public key even if it’s there due to bad ownership.

[user@remotesystem ~]$ mkdir .ssh
[user@remotesystem ~]$ touch .ssh/authorized_keys
[user@remotesystem ~]$ chmod -R u=rwx,go= .ssh
[user@remotesystem ~]$ exit
scp ~/.ssh/id_dsa.pub user@remotesystem:.ssh/authorized_keys

Enter your password when asked, and you’re done.

Log on the remote system

[user@localsystem ~]$ ssh user@remotesystem

Tip

You can later change the password for your keys by using

[user@localsystem ~]$ ssh-keygen -p

// CrashMAG

Examples of using rsync

Some of the main features of rsync include

  • can update whole directory trees and filesystems
  • optionally preserves symbolic links, hard links, file ownership, permissions, devices and times
  • internal pipelining reduces latency for multiple files
  • can use rsh, ssh or direct sockets as the transport
  • checksum based verification

Preserving permissions, updating whole directory trees and secure transfers over ssh makes this the ideal backup tool. And it can be easily scheduled using cron. It’s also incredibly fast if you make us of the rsync daemon and not ssh.

This article will cover a few examples so that you’ll be able to quickly make use of the primary features of rsync.

Things to note when you use rsync

Copy the /home/temp folder to the remote-host

$ rsync -v /home/temp/ username@remote-host:/home/temp/

Copy the folder & the files within /home/temp to the remote host

$ rsync -v /home/temp/* username@remote-host:/home/temp/

Copy the folder & the files within /home/temp to the remote host. And recursively all the folders and files within /home/temp.

$ rsync -rv /home/temp/* username@remote-host:/home/temp/

Note: If you append the “-n” parameter rsync will simulate the operation you’re trying to do.

-n, --dry-run         perform a trial run with no changes made

All the examples were tested using the following version of rsync

rsync  version 3.0.7  protocol version 30
Copyright (C) 1996-2009 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Capabilities:
    64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
    socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
    append, ACLs, xattrs, iconv, symtimes

Example 1 – Backing up a folder and its sub-folders to a remote location

We do not preserve file permissions here. But we do use rsyncs ability to checksum to verify that the content that we copy are 1 to 1.

$ rsync -vrc /home/temp/ username@remote-host:/home/temp/

Parameters used in the above example

  • -v for verbose
  • -r for recursive
  • -c for skip based on checksum, not mod-time & size

You may also want to add information of your progress, keep partially uploaded files so they can be resumed if anything goes wrong and metric information that makes sense. Your desired command will then be as follows.

$ rsync -vrcPh /home/temp/ username@remote-host:/home/temp/
  • -P for progress during transfer and keep partially transferred files
  • -h for output numbers in a human-readable format

Example 2 – Backing up a folder and its sub-folders to a remote location preserving file permissions

This is a classical backup scenario. We’re keeping the ownership and file permissions. And copying this off to a remote location. We’re also not overwriting files that are newer on the receiver.

$ rsync -auvrc /home/temp/ username@remote-host:/home/temp/
  • -a for archive mode; equals -rlptgoD
  • -u for skip files that are newer on the receiver
  • -v for verbose
  • -r for recursive
  • -c for skip based on checksum, not mod-time & size

Example 3 – Copy folders to & from a local system

We do not preserve file permissions here. But we do use rsyncs ability to checksum to verify that the content that we copy are 1 to 1. This also serves as a way to test for faulty hard drives. We also for this enable the progress information and human-readable formats.

$ rsync -vrhc --progress  /home/importantfiles/ /mnt/externaldisk/backup_of_importantfiles/

Parameters used in the above example

  • -v for verbose
  • -r for recursive
  • -h for output numbers in a human-readable format
  • -c for skip based on checksum, not mod-time & size
  • –progress for show progress during transfer

Example 4 – View the changes between the source and destination system

To accomplish this we use the itemize-changes and recursive parameter

$ rsync -ri /home/temp/ username@remote-host:/home/temp/

You’ll then see something that could look like this

Parameters used in the above example

  • -r for recursive
  • -i for output a change-summary for all updates

It’s worth noting that “decoding” the results from rsync with “-i” requires knowledge about all the references. Those are very well documented in the man page under the “-i, –itemize-changes” section. You can also tweak the output using –out-format.

Example 5 – Backing up a folder and its sub-folders to a remote location with a bandwidth limitation

$ rsync -vrc --bwlimit=10000 /home/temp/ username@remote-host:/home/temp/
  • -v for verbose
  • -r for recursive
  • -c for skip based on checksum, not mod-time & size
  • –bwlimit=KBPS for limiting I/O bandwidth by KBytes per second

// CrashMAG

How to be a more productive Linux system administrator

Came across a nice little article at IBM developerworks today. Learned a new command and got reminded of a few things. It was worth my time reading it.

Here’s a quote of the summary of the article…

Learn these 10 tricks and you’ll be the most powerful Linux┬« systems administrator in the universe…well, maybe not the universe, but you will need these tips to play in the big leagues. Learn about SSH tunnels, VNC, password recovery, console spying, and more. Examples accompany each trick, so you can duplicate them on your own systems.

Click here to head over to developerworks for the original article

// CrashMAG