Showing posts with label OpenSSH. Show all posts

Tuesday, April 2, 2013

Transfer Files From One UNIX Server To Another Server Using Windows / Linux Desktop

Transfer Files From One UNIX Server To Another Server Using Windows / Linux Desktop

Linux SCP Command explained

How do I securely transfer files from one UNIX / Linux server to another UNIX server using Windows or Linux desktop clients without using ftp client?

You need to use secure sftp or scp client for Windows XP / Vista / 7. Under Linux or Apple Mac OS X desktop you can use regular OpenSSH scp / sftp client to transfer files.

Windows SSH Client

You can use free SFTP, FTP and SCP client for Windows called putty or winscp.

Linux / UNIX / OS X SSH scp Client Examples

Use the following command from the server to which you want the files to go. In this example, transfer all files (/var/www/html) from remote server called server1 to local directory called /backup:
scp -r user@server1:/var/www/html/ /backup
In the following example, transfer all files (/var/www/html) from remote server called server1 to another server called server2:
scp -r user@server1:/var/www/html/ user@server2:/var/www/html/

Say hello to rsync

I recommend using rsync command which will only push or download updated files. It can copy locally, to/from another host over any remote shell, or to/from a remote rsync daemon. In this example, copy files from remote server called server1 into /backup directory:
rsync -avz -e ssh user@server1:/var/www/html /backup

Friday, March 15, 2013

Authenticating in PHP using SSH

For a good couple of years now I've wondered if there was a way to write an authentication system in PHP that utilized SSH instead of the widely-breakable database and flatfile methods. After doing some research I found its possible after installing a PHP extension. This guide will detail the methods used to do this, with the intent of hopefully having this a more versatile option.

Requirements
Before we begin, there are a few things that are needed. The first is obviously PHP, with this guide written for 5.3.6. My system has Suhosin already installed and it causes no issues so you should be fine too if you have those patches installed. The next thing you'll need is the PECL extension SSH2. There other libraries out there that you can use that people have written but I decided to stick with officially supported releases. You can install this by simply running the following command:

pecl install ssh2

I cannot guarantee this but it is better safe than sorry, your PHP should be compiled with OpenSSH libraries.

Configuration File
I've already written all the code for both the configuration and actual authentication, and I'll provide those links at the bottom of this. But, basically the configuration file will store this information:

Host - The FQDN or IP of the SSH server (usually localhost is okay)
Port - The port which the host is listening on (standard is 22)
Key path - The path to the private key (used for public key authentication only)
Fingerprint - The fingerprint, or unique ID, of the host. If the fingerprint doesn't match the server's, authentication will be refused regardless
Authentication mode - Tells the system whether to use password or public key (default)

Now, if you're wondering why the fingerprint is so important, here's a scenario. Let's say you are using this to authenticate users for a banking system. Someone compromises the server and reroutes incoming port 22 packets to a different server (thus with a different fingerprint). If the fingerprint in the config file does not match the fingerprint of the attacker's SSH server when the script tries to establish a connection, the connection will die. This ensures that accounts are not compromised and sensitive data is not stolen. We add an extra layer of security to this by enforcing public key by default.

Authentication Class
I'm sure this is what you're probably wondering, so I'll address this first. There is a function available (SSH_GetFP()) that lets you get the fingerprint of the server. Here is a list of the functions available and what they do (all prefixed with SSH_):

Conn() - Creates a connection to the SSH server based on host & port.
Exists() - Determines whether the extension is installed or not.
FP() - This does the fingerprint checking of the config file against the server.
GetFP() - Function to get the fingerprint of the server (should ONLY be used to get the fingerprint...and never used in production)
AuthKey() - Authenticates a user by public key. Takes 3 arguments: username, public key file and the passphrase. If no passphrase is provided the function will fail.
AuthPass() - Authenticates a user by password.

Using These Files
After you properly set up the configuration file, do this to get the fingerprint of the server:

require_once('auth_ssh.php');

$ssh = new Auth_SSH();
echo($ssh->SSH_GetFP());

Every function calls SSH_Conn() due to a connection resource being needed, so you do not have to call it directly. As long as your host and port are correct, Get_FP() will establish the connection and get the fingerprint for you. Now you just need to add that to your configuration file.

To authenticate a user, its pretty easy. For passwords:

if(!$ssh->SSH_AuthPass("username", "password")){
    echo("Fail");
} else{
    echo("Success.");
}

To use the public key method, its a little bit trickier. You can either have the person upload their public key to the server or store them on the server along with the private key. My recommendation on this would be to have them upload their public key. To use this method, call it like so:

if(!$ssh->SSH_AuthKey("username", "/path/to/pub/key/file.pub", "passphrase_for_keyfile")){
    echo("Fail");
} else{
    echo("Success");
}

The reason why the passphrase is mandatory is, besides it being good security practice, is that in case someone does compromise the server and steals the public key, they still cannot log in without the passphrase.

Conclusion
Is this a flawless method? No. However, I strongly believe two-factor authentication is the wave of the future (which public key authentication is when provided with a passphrase). The source for these files are open to the public. If you use it, credit is welcome but not mandatory.

Also, you'll see looking through auth_ssh.php that $this->msg is filled a bit. This is used for debugging purposes. Functions themselves only return true or false (except for SSH_Conn() which returns a resource ID). While I try my best, I cannot guarantee this will work for you, but it does work for me.

FIles
auth_ssh.php - https://github.com/SecurityForUs/CodeDump/blob/master/auth_ssh.php
auth_ssh_config.php - https://github.com/SecurityForUs/CodeDump/blob/master/auth_ssh_config.php

OpenSSH

Working with OpenSSH
Back when the Internet was a big, happy family with only a hundred or so university servers connected to each other, it was practical and feasible to login to a remote computer using an plain-text protocol like telnet. This is, for reasons that should be obvious to most all Internet users, no longer advisable. For the most part, nobody logs in to a remote computer this way. They use a tool like OpenSSH.

What is OpenSSH?
OpenSSH is a free version of SSH Communications Security's SSH protocol. It is essentially a suite of tools for making secure connections. First, there is a daemon, sshd, which listens for connections from outside and performs authentication of those connections. There are three main client programs, ssh, the client shell, scp, a command-line program for copying from one machine to another and sftp, another program for copying in an ftp-like manner. There are also various programs to manage encryption keys that are used by clients and server.

Installation of OpenSSH
So that your system can both receive and make connections via OpenSSH, you need to have the following packages installed:

openssh
openssh-server
openssh-clients

All major distributions have these packages. In fact, they are normally installed by default.

OpenSSH Configuration
The main configuration file is /etc/ssh/sshd_config. There are a few changes that you should make to this file before you open up your machine to connections from the outside world.

First, its not a good idea to permit root logins to any machine. So that this cannot occur, make sure to change the file (or uncomment the line) so that the following line appears:

PermitRootLogin No

You may also want to allow remote machines to open X sessions. To do this, change the file (or uncomment the line) so that the following line appears:

X11Forwarding yes

* Most administrators feel that a Linux machine providing services like FTP, mail and Apache should not be running X. As a general rule, the more services a machine runs, the more risk of exploits. If the server isn't doubling as a workstation, it really shouldn't be running X. This will also save on resources as well.

Bending the Rules
Normally, to use 'ssh' or 'scp', you'd have to enter a password. There is a simple way to get around this. You may be asking yourself, however: why would you want to get around this? One reason is for sending backup copies automagically to other machines. Here's how to use scp without a password to send files:
First, create a user account on one machine. For this example, let's call it 'bkups'. Then login as 'bkups' and create a public key:

ssh-keygen -t rsa

To this, just press ENTER to everything. This will have created two files: id_rsa and id_rsa.pub in the directory /home/bkups/.ssh. Now, login to the other machine and create another user called 'bkups'. Now, go back to the to the first machine, from where you want to send the backup files. You now need to copy the file /home/bkups/.ssh/id_rsa.pub back to the other machine. For best results, this should not be done as the 'bkups' user. It is easiest to to this as 'root', but if you can't 'scp' it as root, then have root make a copy and chown it to a normal user and 'scp' it to the other machine. Then login to the other machine and get 'root' privileges.

Copy the file to /home/bkups/.ssh/authorized_keys and chown it to the 'bkups' user. Now, go back to the first machine again and try to use 'scp' to copy a file from 'bkups' on this machine to 'bkups' on the second. The first time it will ask you if you want to connect, but it won't ask for your password. Every subsequent time it will just copy the file without asking for a password. This makes automating your backups very easy.

OpenSSH

openssh
openssh-server
openssh-clients

PermitRootLogin No

You may also want to allow remote machines to open X sessions. To do this, change the file (or uncomment the line) so that the following line appears:

X11Forwarding yes

ssh-keygen -t rsa

SSH: The VPN No One Remembers

For anyone that doesn't know about VPNs, its basically the ability to use your server's resources (drives, bandwidth sometimes, etc...) remotely. So, for example, say you want to mount your server's /dev/sda6 partition to your home PC. You can use a VPN to do this, and you'll be able to browse all of those files from the luxury of your home PC.

I'm sure everyone is aware as to what SSH (specifically OpenSSH) is, especially since there's been a lot of discussion about it on LinuxForum.com as of late. But, I don't know if many people actually realize just how powerful SSH can be. If used right, you can turn a regular SSH server into a non-resource intensive, very much free VPN server. While it won't be as robust as say, OpenVPN, its definitely better than buying a whole new server just for VPN functionality, and SSH can mount remote directories as well using sshfs.

How To Start
This guide is pretty short because the steps are rather easy. There is an assumption that you have an already-working SSH install, however. What we are going to do is take that install, and build on it.

What I did personally for my set up, because I wanted to have two different access lists, is create a new SSH config file. For this, I just did the following;

cp /etc/ssh/sshd_config /etc/ssh/proxy_config

The reason for doing this is because I wanted to leave my SSH configuration separate from a proxy (and thus have two instances of SSH running, but the footprint is very minimal). I took out all of the commented stuff from the new proxy_config. Below are the most important parts to focus on:

Port ####

Of course change the "####" part, but change this from the regular SSH server.

PermitRootLogin no

You should never have this enabled to begin with, and just in case you flub up on your proxy account creation you'll want to make sure something bad doesn't happen.

PermitTunnel yes

I'm kind of on the fence about this one personally, it used to work without needing this but now its needed. Basically this lets you bind to the SSH server and make it act as a proxy server of sorts.

AllowUsers user1 user2 etc...
AllowGroups group1 group2 etc...

You can use one or both of these, but I'd highly recommend not using neither (as then it'd mean anyone can log into it). This is the meat and bones of the ACL of this proxy system. For the joy of not breaking anything, I only used AllowGroups and set it to my proxy group. Basically what happens is that SSH checks this list for each user authentication request, and if the user (or the user isn't in the specified group), SSH says "no entry!" and refuses the connection.

Testing
Now, assuming you made the appropriate changes to your firewall(s) and created any needed accounts or groups (highly advisable to NOT assign the user a shell, by the way), you should be ready to go. You can either copy & edit the start up script in similar fashion to the sshd_config file, or simply run this command:

/usr/sbin/sshd -f /etc/ssh/sshd_proxy

Side Note
Before continuing, I'd like to say something. If you decide to go the more flexible route and just copy & edit the SSH start up script, make sure you edit the PIDFILE variable, and whatever you name the pid (i.e.: sshd_proxy.pid), make sure you copy and rename the SSH file in /etc/conf.d/sshd to that as well. For example, if the pid is sshd_proxy.pid, your command will look like:

cp /etc/conf.d/sshd /etc/conf.d/sshd_proxy

Then edit that file change the name of the SSH config file. This might sound confusing, but when you look at it, it makes a lot more sense, I promise.

Connecting Remotely
Your SSH proxy all set up? The proxy running on the correct port? Good, now the coupe de grace. Fire up a terminal, and run the following command:

ssh -fND localhost:local_port_number -p port_proxy_is_running_on proxy_username@remote_server_hostname_or_ip

Making the appropriate changes, this will run the connection in the foreground (remove the "f" to make it run in the background, this is done to make sure everything runs smoothly). If all goes well, you'll see nothing happen, as in it'll look like its hung or frozen. For local_port_number, you should choose one that isn't used, and is higher than 1024. What you do now is use hostname localhost and port local_port_number (whatever it may be) for any programs you want to connect to via proxy (browser, IM client, e-mail program, etc...).

Just like any other proxy, the data for any programs using this proxy will be fed to the proxy server, so programs will always see the proxy's IP address as being yours. So for example, say we want to use local port 5555, the proxy is listening on port 9999, the proxy username is bob, and the server IP is 255.244.222.111. The command will look like this:

ssh -fND localhost:5555 -p 9999 bob@255.244.222.111

SSH: The VPN No One Remembers

cp /etc/ssh/sshd_config /etc/ssh/proxy_config

Port ####

Of course change the "####" part, but change this from the regular SSH server.

PermitRootLogin no

You should never have this enabled to begin with, and just in case you flub up on your proxy account creation you'll want to make sure something bad doesn't happen.

PermitTunnel yes

I'm kind of on the fence about this one personally, it used to work without needing this but now its needed. Basically this lets you bind to the SSH server and make it act as a proxy server of sorts.

AllowUsers user1 user2 etc...
AllowGroups group1 group2 etc...

/usr/sbin/sshd -f /etc/ssh/sshd_proxy

cp /etc/conf.d/sshd /etc/conf.d/sshd_proxy

ssh -fND localhost:local_port_number -p port_proxy_is_running_on proxy_username@remote_server_hostname_or_ip

ssh -fND localhost:5555 -p 9999 bob@255.244.222.111