Blue Flower

Sunday, 05 July 2015 12:59

Shell Shortcuts

Written by

There are a few different tricks I use for using the Shell. The first thing I would do is change your shell to TCSH. Run the following command as root:


# chsh user

Drop down to the Shell line and make it look like the following line:

Shell: /bin/tcsh

Save and Exit. Now type exit again and login again as that user. You should now have a Prompt.

Now the next thing I like to do is I like to know the full path of the directory of where I am at. It makes it easier to know where you're at without having to type pwd all the time. The first thing you will want to do is to edit your .cshrc in your home firectory so lets do that:


# vi ~user/.cshrc

Scroll down to the line that looks like this:

# An interactive shell -- set some stuff up

Comment out the set prompt line already in there by putting a # in front of it and then create a new line by hitting the O key on your keyboard. Now put this line in:

set prompt="[%B%/%b] user@host# "

Exit and save. Now type


# source ~user/.cshrc

You should now see a prompt like so:


[/home/user] user@host#

What I would suggest doing next is doing the same thing for your root account:


# vi ~root/.cshrc

Scroll down to the section where it says "# An interactive shell -- set some stuff up" and go down where it has a set prompt section and delete that line. Add the following line:

set prompt="[%B%/%b] root@host# "

Then save and exit. If you are root now, Just type


# source ~root/.cshrc

and you will now see a custom root prompt. Nice job!

The last thing I do to my .cshrc is add a ton of different shortcuts. I still like using the old dos commands like dir and stuff. Add the following line to your .cshrc:

alias wtf echo "I dunno"

so if you do


# source ~user/.cshrc

and then you type "wtf" at the prompt, It will reply "I dunno".

Here is a list of the different aliases I use in my ~root/.cshrc

alias wtf echo "I dunno"
alias tgz "tar cvzf"
alias sendfilter "tai64nlocal < /var/log/qmail/qmail-send/current"
alias smtpfilter "tai64nlocal < /var/qmail/supervise/qmail-smtpd/log/main/current"
alias popfilter "tai64nlocal < /var/log/qmail/qmail-pop3d/current"
alias sslfilter "tai64nlocal < /service/smtpssl/log/main/current"
alias dropfilter "tai64nlocal < /var/log/maildrop/current"
alias tinydnslog "tai64nlocal < /service/tinydns/log/main/current"
alias portsearch "sockstat -l | grep "
alias mcdrom "mount_cd9660 /dev/acd0 /cdrom"
alias ucdrom "umount /cdrom"
alias space "du -hs"
alias h history 25
alias j jobs -l
alias la ls -a
alias lf ls -FA
alias ll ls -lA
alias dir "ls -laG"
alias remove "rm -dfr"
alias i "make install clean distclean"
alias up "/usr/libexec/locate.updatedb &"
alias sup "cvsup -g -L 2 ~root/stable-supfile"
alias pup "cvsup -g -L 2 ~root/ports-supfile"
alias chkdsk "df -h"
alias qstat "qmailctl stat"
alias proc "ps -auxw | grep "

"UseDNS no" speeds up login times since sshd does not perform reverse
DNS on the connecting IPs. Edit the following file


# vi /etc/ssh/sshd_config

and look for the UseDNS setting and uncomment it and change yes to no. Then you'll want to restart ssh in order for the changes to take effect.


# killall -HUP sshd

Thats it for Shell Customizations!

How to backup via rsync/ssh from one server to another

Required: You need to have rsync and ssh installed

Part of this documentation was taken from http://jms1.net/ssh.shtml and also http://www.qmailinfo.org/index.php/ExampleRsyncScripts

The server in this document is the box that has all files needed to backup
The client in this document is the box the files are being backed up to

Setting up the ssh keys on the server

On the server, Open up /etc/ssh/sshd_config and add PermitRootLogin without-password. Then you will want to restart sshd by running killall -HUP sshd. You will get kicked out of your terminal. If all is well, You should be able to login again. Root is now allowed to login only via a ssh key. Don't worry, there is some added security in the document as well.

Generating the key on the client

The first thing we will want to do is generate the key on the backup machine. Run the following command:


# ssh-keygen -t ed25519 -b 1024 -f id_dsa_backup -C 'Some comment'

When you see 'Enter passphrase (empty for no passphrase):' Just hit enter and then when you see the confirmation that says 'Enter same passphrase again:' just hit enter again. After a few seconds, it should give you an output similar to the following:


Your identification has been saved in id_dsa_backup.
Your public key has been saved in id_dsa_backup.pub.
The key fingerprint is:
88:da:e8:4c:50:5d:c5:95:b9:1e:6e:8f:96:82:c0:19 Some Comment

Now, the id_dsa_backup.pub is the file we need to ssh over to your server. Here are the steps you will want to follow to get this over to your server to allow root logins via ssh:

This part you will want to do on the Server:


# scp user@backup:/path/to/id_dsa_backup.pub .
user@server's password:
id_dsa_backup.pub |********************| 0 0:00
# cat id_dsa_backup.pub >> ~root/.ssh/authorized_keys2
# chmod 600 ~root/.ssh/authorized_keys2
# exit

This is not the only way to get the public key file into place. You could also copy it on a floppy disk, or email it to the system administrator and have them install it for you (remember this is the PUBLIC key, there is no security risk in sending it via normal email.)

Note that you can have multiple keys listed in the .ssh/authorized_hosts2 file - this is why the public keys have comments at the end, so you can easily tell which line in the file corresponds to which key.

To add a bit more security on the server, will will want to change the /root/.ssh/authorized_keys2 to look like so:


command="/root/.ssh/rsync-key" ssh-dss AAAAB3NzaAAA4fobEeQMoC6vRInbeNy5PukQ5fAkCc+Vr...

Then this is what is in the /root/.ssh/rsync-key file:


#!/bin/sh
logger -t ssh-command "$SSH_ORIGINAL_COMMAND"
echo $SSH_ORIGINAL_COMMAND > /tmp/work.$$
if ! grep -q '^rsync --server ' /tmp/work.$$
then
logger -t rsync-key INVALID COMMAND ""$SSH_ORIGINAL_COMMAND""
exit 1
fi
rm /tmp/work.$$
exec $SSH_ORIGINAL_COMMAND

Then we need to chmod it properly so it runs:


chmod 755 /root/.ssh/rsync-key

Backing up files

Now that we have the keys in place for rsync via ssh to work, we can now setup a script to automate this for us and then we can put it into cron. Here is my script for this. I will call this backup.sh and in this example I will be backing up vpopmail:


#!/bin/sh
echo `date` starting >> /var/log/backup.log
rsync -aS --delete -e /path/to/backup-ssh root@HOST:/usr/home/vpopmail/ /backup/vpopmail/location
echo `date` done >> /var/log/backup.log

The '/path/to/backup-ssh' in the above file has this in it:


#!/bin/sh
unset SSH_AUTH_SOCK
exec /usr/bin/ssh -i /path/to/id_dsa_backup $*

Now we want to setup the chmod for the following files:


# chmod 755 backup.sh
# chmod 755 backup-ssh

Now lets give it a test!


# ./backup.sh

If all goes well, It should pause there for a minute (Or more depending on the size of vpopmail) and then it will come back to the prompt. Check your backup log in /var/log/backup.log and see if it started and stopped correctly.

Sunday, 05 July 2015 12:47

Chroot Users using SFTP

Written by

In order to secure your filesystem in the event your clients need access to their virtual or home directories, I would suggest using the chroot command available within ssh.

In /etc/ssh/sshd_config add the following at the bottom. Anyone in the chroot group will land in their home folder.

Match group chroot
ChrootDirectory %u
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp

You will now want to restart sshd

# /etc/rc.d/sshd restart

Now add a new group called chroot

# pw addgroup chroot

Add a new user and apply the following attributes:

Make sure the new user is in group chroot
Make sure the shell is set to nologin (This will allow them to scp in but NOT ssh in)
Make their home directory is set to any directory.

So when you're done you need to set the perms on the home folder and then the files within that folder.

# chown -R root:chroot username
# cd username
# chown -R username:chroot *

When your user logs in it will chroot them to their directory :-)

Once you do this it should chroot user just fine :-)

Friday, 28 October 2016 15:57

Subscription Based Articles

Written by

Hello all,

Starting November 1st, 2016 I am going to start offering premium access for members that pay monthly or yearly. This will include articles that have been specifically written and tested by me and posted on a special section on freebsdrocks.net. You will also get exclusive freebsd news as well as weekly updates from myself including what I am currently working on and I will also seek input from you on any new articles to post. I am depending on you to help me make freebsdrocks much better and possibly get some more traffic.

Pricing:

$50 a year or $5 a month

Please send donations to the paypal link to the right and reference SUBSCRIBER and your registered email address so I can setup your account to access our special features.

Thank you again for your support.

Monday, 17 October 2016 02:14

Upgrade your ssh keys

Written by

This was taken from https://wiki.archlinux.org/index.php/SSH_keys#Ed25519

The Windows SSH client PuTTY does not support ECDSA as of March 2016. One needs a PuTTY development snapshot to connect to a server that uses only ECDSA keys.

Ed25519 was introduced in OpenSSH 6.5: "Ed25519 is an elliptic curve signature scheme that offers better security than ECDSA and DSA and good performance". Its main strengths are its speed, its constant-time run time (and resistance against side-channel attacks), and its lack of nebulous hard-coded constants.[11] See also this blog post by a Mozilla developer on how it works.

It is already implemented in many applications and libraries and is the default key exchange algorithm (which is different from key signature) in OpenSSH.

Ed25519 key pairs can be generated with:

# ssh-keygen -t ed25519

There is no need to set the key size, as all Ed25519 keys are 256 bits. Also, they rely on a new key format which "uses a bcrypt-based key derivation function that makes brute-force attacks against stolen private keys far slower".

For those reasons, compatibility with older versions of OpenSSH or other SSH clients and servers may prove troublesome.

Page 21 of 23