md5sum * | md5sum

This will return an md5sum which will look something like
9277826461d2cb19731f6201c6b2c6b3 -

Run it in 2 directories, if the sums of the sums match, the files are identical.
If not, you may want to rsync between them with something like
rsync-avz -e ssh localdir/ user@remotehost:/remotedir/
or
rsync-avz -e ssh user@remotehost:/remotedir/ localdir/

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

In light of an increase in ssh attacks , vulnerabilities and scans I am writing this guide to help you keep unwanted people from connecting to your server via SSH.

If you have generated any of your SSH keys on a Debian or Ubuntu system they are likely very vulnerable to guessing, e.g. someone could login to your box if they know the name of one of your users that you allow in via ssh within 30 minutes!
See here for more info: http://metasploit.com/users/hdm/tools/debian-openssl/

This applies to any PAM enabled Linux (or other PAM-enabled *nix like OS)

This guide will walk you through configuring your OpenSSH server to only allow public key authentication and limit that to specific users and groups. Errors in this guide or mistakes or differences in system configurations could lock you out of your own systems, be very careful and do not proceed unless you understand and assume the risk you are taking.

I assume no responsibility for YOUR actions. This guide was tested on Ubuntu 7.10 and fairly recent Gentoo system.

1. Limit SSH access to public/private keys only, deny X11 and TCP forwarding, and deny root ssh access
Step 1 Discussion:
Public/Private keys are not necessarily more secure than passwords, but it’s harder to guess a private key, and if your users put passwords on their keys then an attacker must have or guess 2 things, the key and its password.

The root user is GOD on almost every Linux/*nix system out there, and nobody should be able to login directly as root remotely. In addition it’s a very common user, on almost every Linux/*nix system.

TCP and X11 forwarding is one of the coolest features of an ssh server. Unless you want people to be able to use your ssh server like a full access vpn to your local network, or any other network (bounce their attacks through your server), then you want this disabled. And X11 forwarding is great, but I never run an X11 server on something that is a “production” environment. If something requires an X11 server, like Oracle, then I run vncserver and allow ssh port forwarding so people can connect via ssh. I make sure to have full deny by default firewalls on all machines like this, limiting outbound access.

Step 1 HOWTO
Edit /etc/ssh/sshd_config
Make sure the following lines are not commented out, and don’t say something different

Protocol 2
PermitRootLogin no
UsePAM yes
PasswordAuthentication no
PubkeyAuthentication yes
RSAAuthentication yes
PermitEmptyPasswords no
ChallengeResponseAuthentication no
AllowTcpForwarding no
X11Forwarding no

2. Create an ssh remote users group and add users to it who need remote ssh access
Step 2 Discussion:
The main reason I want to limit who has remote ssh access is because there are frequently system accounts or other automatically created accounts that I don’t want to have to monitor to make sure the installer didn’t just make a new user with a simple password or key. I want to have the default be nobody can ssh, and then I’ll add ssh permissions to users who need it.

Step 2 HOWTO:
Let’s call our remote ssh users list rsshusers, we create it with the command
groupadd rsshusers
Now let’s say we have a user named mikey already setup, let’s add him to our new rsshusers group, with the command
usermod -a -G rsshusers mikey
Do this for every user you want to have ssh in remotely. Note that if you’re used to logging in remotely as root and are going to stop doing that, make sure you user can su to root with the command su.
Login as the user, run
su
Put in your root password, if it accepts it and you are root (run whoami to verify) then you’re good to go. If it fails to let you su and you’re sure you have the password right you may need to be in the wheel group to us (default on FreeBSD and Gentoo).
Back as root run the following command to add your user (again, mikey in this example) to your wheel group.
usermod -a -G wheel mikey

Now we’re going to edit 2 files to limit remote ssh users to the group we made called rsshusers.
First, edit /etc/pam.d/sshd (this was ssh on my Debian/Ubuntu systems)
Add the line
account required pam_access.so

This enables access accounting based on the /etc/security/access.conf file, which is the next one we are going to edit.
On both my Gentoo and Debian system this file had every line commented out.
At the end I added the following lines.

-:ALL EXCEPT root mikey:LOCAL
+ : (rsshusers) : ALL
- : ALL : ALL

Initially I tried to use a group like @rsshusers, however this didn’t seem to work, but () designates explicitly a group.

Restart sshd
Gentoo:
/etc/init.d/sshd restart
Debian/Ubuntu:
/etc/init.d/ssh restart

Now, without closing your root terminal, open a new one and make sure you can ssh in as mikey, and su to root.

Assuming everything went well you could try ssh’ing in as another user whose public key is correctly in place, but who isn’t in the rsshusers group.

Related links:

PAM:

http://devmanual.gentoo.org/tasks-reference/pam/index.html

http://linuxdocs.org/HOWTOs/User-Authentication-HOWTO/x101.html

http://tldp.org/HOWTO/User-Authentication-HOWTO/

http://www.faqs.org/docs/Linux-HOWTO/Secure-Programs-HOWTO.html

OpenSSH:

http://www.openssh.com/

http://thinkhole.org/wp/2006/10/30/five-steps-to-a-more-secure-ssh/

http://www.cyberciti.biz/tips/rhel-centos-linux-install-configure-rssh-shell.html

http://geekzine.org/2007/09/28/easy-sftp-and-chroot-sftp-with-scponly/

Misc:
Securing RedHat

http://help.unc.edu/?id=1859

Debian SSLkeys

http://wiki.debian.org/SSLkeys

Links in post:

http://www.securityfocus.com/news/11518

http://metasploit.com/users/hdm/tools/debian-openssl/

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

ssh -X -C -f HOSTNAME PROGRAM

Of course you need to be running an X server (Linux/*BSD Desktop) on your client, and you need to have
ForwardX11 yes
or
ForwardX11Trusted yes

in your CLIENT’s /etc/ssh/ssh_config file
and
X11Forwarding yes
in /etc/ssh/sshd_config
on the SERVER.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Ok, so you read the dd LCOD and tried it out, but you have a 250GB drive and only about 10GB data.. so you’d prefer if you only read the files that were actually there, and not your 100GB of deleted data.

Well, here’s what I do. On the computer to be backed up I boot a linux live cd (such as knoppix from knopper.net), and mount the disks, on say, /mnt/disk and since I use gentoo I have /boot seperate and mount it on /mnt/disk/boot, so I only have to take 1 image/backup.

Then I make sure networking is up.. it all goes something like this

Then we get the prompt to accept the key, put in our password and wait. The v in the -zcvf will give us verbose output, if you just want to wait you can omit it and not see each file as it goes. This will create a tar archive of all the files in that directory, gzip it and put it to standard out, which redirects to ssh to 192.168.0.X as user “user”, and then pipes it to the dd which puts it into the file /home/user/bakcup.tar.gz

Now, on to the restore part… So you have this image, and you want to put it onto another computer.. Well this is kind of like installing gentoo, so boot to your trusty linux cd, open a console and follow these steps..
create your partitions using fdisk (here’s an fdisk howto http://www.tldp.org/HOWTO/Partition/partition-5.html)

Now I’m going to assume you’ve made /dev/hda1 as your /boot /dev/hda2 as your swap and /dev/hda3 as your / (root) partition.

To format your disks use the mkfs commands like this

now that you have your disks setup, lets mount them, its just like above is we use /mnt/disk as the mount point, and run our restore, which is just like the above command but reversed… note you could probably use cat instead of dd… and a > instead of dd on the creating side above..

note: the – at the end of the the tar command means standard in/out

So now you’ve got your data restored exactly as the system was at last shutdown, on a new file system. If you changed your disk layout, you’ll want to update /etc/fstab and the final thing we need to do is reinstall grub so the system boots to it. To do that we need to chroot, just like a gentoo install
assuming your disks are still mounted on /mnt/disk

Assuming your disk is 0,0 (first IDE drive, slice is /boot)
You can use the tab key in grub to see what disks are available, so type root (hd
and hit tab
and it’ll say 0,1,2 or something telling you which disks are available

That’s it, now exit the shell and reboot like this

don’t forget to remove the CDROM when you reboot (knoppix will eject it and ask you to hit enter once its out)

Now you should get your old OS booted back up, FYI if you’re imaging lots of systems you may want to edit your config files for your network if you’re not using DHCP (/etc/conf.d/net on gentoo) so the machines don’t all try to come up with the same IP address.

~.

That’s it! If you’re in a system and your modem dropped, or your DSL hung, or your connection just got lost and ssh didn’t kick you back to your prompt, just hit ~. and you’ll disconnect.

Again that’s Tilde (~) and then period (.)

If you’re in multiple systems in a chain of SSH connections this will disconnect you from the one your local machine is connected to.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.