Posts Tagged ssh
LCOD – 5.26.10 – Compare 2 directories
Posted by Jon Zobrist in Linux, Linux Command of the Day, Uncategorized on May 26, 2010
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/
LCOD – 5.17.08 – Locking down ssh access
Posted by Jon Zobrist in Linux, Linux Command of the Day on May 17, 2008
Warning: htmlspecialchars_decode() expects parameter 1 to be string, NULL given in /home/content/m/d/x/mdxdoug/html/jonzobrist/wp-includes/compat.php on line 113
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/
LCOD – 6.6.07 – Simple SSH remote command execution
Posted by Jon Zobrist in Linux, Linux Command of the Day on June 6, 2007
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.
LCOD – 8.10.05 – How to net backup/restore using tar|ssh|dd
Posted by Jon Zobrist in Linux, Linux Command of the Day on August 10, 2005
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
| Code: |
| mkdir /mnt/disk mount /dev/hda3 /mnt/disk mount /dev/hda1 /mnt/disk/boot cd /mnt/disk tar -zcvf – * | ssh user@192.168.0.X dd of=/home/user/backup.tar.gz |
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
| Code: |
|
mke2fs /dev/hda1 mkreiserfs /dev/hda3 mkswap /dev/hda2 |
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..
| Code: |
| mkdir /mnt/disk mount /dev/hda3 /mnt/disk mkdir /mnt/disk/boot mount /dev/hda1 /mnt/disk/boot swapon /dev/hda2 cd /mnt/disk ssh user@192.168.0.X dd if=/home/user/backup.tar.gz | tar -zxvpf - |
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
| Code: |
|
chroot /mnt/disk /bin/bash grub root (hd0,0) setup (hd0) |
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
| Code: |
|
exit cd / umount /mnt/disk/boot umount /mnt/disk swapoff /dev/hda2 reboot |
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.
When imaging systems with server services, specifically SSH, is that you should change your server key, in fact, it’d be best if you deleted your keys BEFORE you created your image, so that when the server boots up it’ll generate its own keys upon starting SSH. Having your SSH private keys in any type of unsecure location is a BAD idea…
to delete your keys simply
| Code: |
| /bin/rm /etc/ssh/*key* |
LCOD – 4.25.05 – Howto get out of hung SSH sessions
Posted by Jon Zobrist in Linux, Linux Command of the Day on April 25, 2005
~.
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.