Tag: ssh

rsync logs with restricted ssh

Posted by – 15/04/2009

SSH is really the Swiss Army pocket knife of sysadmin tools. When I needed to periodically synchronize log files from an old server (old as in customer-would-never-update-it-or-install-anything-new), I built a simple and secure solution using rsync and ssh. This is what I did:

(I will call “remote” the system where the logs I want to retrieve are, and “local” system where I want them to be copied to) First I created an account with a restricted shell (ideally this should be a system account, but we’ll get there!):

remote# adduser --ingroup nogroup --shell /bin/rbash rlogs

Then locally, I created a new, password-less ssh key pair, copying it to my remote system:

local$ ssh-keygen
>>> When asked where to save it, I chose a different name, like .ssh/rlogs
local$ ssh-copy-id -i .ssh/rlogs.pub rlogs@remote
>>> You can delete the password of user rlogs, so it, effectively,
>>> cannot log-in with it (almost like a system user).
remote# passwd -d rlogs

Now you should be able to run password-less rsync already (note that I use -e option to point to a different key):

local$ mkdir logs
local$ rsync -av -e "ssh -i $HOME/.ssh/rlogs" rlogs@remote:"logs/" logs/
receiving file list ... done

But even with a restricted shell, I wanted even less possible things to happen. That’s what command= directive is for… It will only allow that command to be run in a session started by that key. Since rsync translates a lot of its command-line options, I run it again with a dirty ps-in-a-loop in the remote host, just to see what running rsync locally causes remotely:

remote$ while 1; do ps wp $(pgrep rsync); sleep 1; done
local$ rsync -av -e "ssh -i $HOME/.ssh/rlogs" rlogs@remote:"logs/" logs/
>>> in the remote loop you should be able to get the command:
 6183 ?        Ss     0:00 /usr/bin/rsync --server --sender -vlogDtpre.i . logs/

Here comes the authorized_keys magic. At the remote host I edited .ssh/authorized_keys to add a command= line with what I found out in my dirty loop. Also, I added a couple of directives to restrict it even further (they are pretty self-explanatory):

rlogs@remote$ cat .ssh/authorized_keys
command="rsync --server --sender -vlogDtpre.i . logs/",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-rsa (...) myuser@local

Now everything is set. I just added the rsync command to the local crontab and it’s done.

Maceio – took some days off

Posted by – 09/03/2009

I finally took some days off. Those are most needed, since I spent carnival on call at the hospital (argh!)… So Brenda and I decided to spend those days at Maceio, capital of Alagoas state, and a very anticipated vacation. They have a lot of sun and beautiful beaches, enough to fill our week (and get some tan also).

This picture was taken at “Praia do Gunga” (Gunga’s Beach), a charming place with a calm shore, almost like a pool, protected by natural reefs. As you can see, I am having a bad time right now 🙂

Food is excellent, so are the people. But there are some inconveniences (as always). Beaches around downtown are not proper for bathing… They’re fighting a long fight against pollution (and loosing, if you ask me)… Also, Alagoas is a poor state… Our guide said alphabetization covers less than 70% of the people…

Also, network connection is expensive in hotels. Ours charges BRL 1,00 every 5 minutes! And the speed is not the best. They have one of those systems requiring a web authentication before you go. I’ve seem people complaining about this kind of system in Planet Debian before (reference please!) and suggesting Tunneling over DNS as a “fix”. I’ve noticed it would work in our hotel, but I decided to try another approach I’ve already written about: just a quick tunnel over an ssh connection.

I know I told you I needed an authentication before, but that is for the first connection! Yes, once the connection is established, I could just log out (thus stop the charging). No new connections could be made, but the tunnel was already up, so just put everything through the tunnel and I should be fine right? Wrong. I got bitten by a drawback of the technique already pointed in a comment when I first wrote about it: in an error-prone network, TCP-in-TCP slowly dies of attempting to correct itself over and over… and I was using a poorly connected wi-fi (loosing almost 30% of the packets!).

So, I was left with the set-up of a not foreseen tunnel using DNS as the only option… This would take time (and money)… So I decided for a simpler approach: SOCKS proxy. Yes, everything I would do could be done through a SOCKS! So a simple:

bash$ ssh -D 8888 my.remote.location

was all that I needed. That and setting my Firefox to use a SOCKS proxy on localhost:8888 and all went fine. I paid to set-up the tunnel then, once established, I logged out and kept using my tunnel all this time. Simple and effective, and I got some time left to blog about it. 🙂

Git basics: reversing the ‘git sucks’ effect

Posted by – 19/02/2009

I’ve been using git this last few days and I am still working on a workflow for my projects. Unfortunately, as others have noticed, git violates POLS is so many ways, it ends up being hard to get.

Creating a remote repository seems to be the first thing to bite a developer switching to git (mainly if coming from a centralized SCM). I have not decided which is the best way of doing it, but I’ve been using git-daemon via inetd and a path in my remote hosting holding all my repositories for public pulling, and ssh for pushing. Here is how to create it:

local$ ssh spectra@remotehost
remotehost$ mkdir /var/git/myproject.git
remotehost$ cd /var/git/myproject.git
remotehost$ git --bare init
remotehost$ logout
local$ cd myproject
local$ git remote add remotehost spectra@remotehost:/var/git/myproject.git
local$ git push remotehost master
otherlocal$ git clone git://remotelocal/myproject.git
otherlocal$ cd myproject
otherlocal$ git remote add remotehost spectra@remotehost:/var/git/myproject.git
(hack hack hack)
otherlocal$ git push remotehost master

Now everybody can pull your repository at git://remotehost/myproject.git and you can push and pull to it via ssh. Note that you have to setup git-daemon, which is pretty straight forward. I am using it as an inetd daemon, but you can use it as a standalone one. Debian has a package which does just that.

Now, some people think logging in a remote server just to create an empty repository is too much. Well… repositories are just .git directories. It happens that you can “push” for the first time by rsyncing your .git with a remote host:

local$ cd myproject
local$ rsync -a .git/ spectra@remotehost:/var/git/myproject.git
local$ git remote add remotehost spectra@remotehost:/var/git/myproject.git
(hack hack hack)
local$ git push remotehost master

(Apparently you can “push” using rsync every time, but it’s regarded as wiser to keep your – probably – crappy local repository commits separated from the public repository… otherwise commit messages like “Please, don’t use this code” are likely to pop up everywhere 🙂 ). Now, I don’t know if this have side effects, but it works 🙂

Another thing to notice is that git is more directed at pulling than pushing. This may be because of its designer: the way Linus works is by pulling changes from others’ repositories and not by letting others push’em into his one. And this is another violation of POLS for most of the people, who is used to “commit” their changes into some remote repository. Rather than that, people using git would expose their own repositories in order to have it pulled by others.

I also agree with most of the git critics wrt git commands… There’s a lot of examples – and I am not going deeper in this – but I think it was a bad choice calling “checkout” what git does when told to “checkout”, for instance. Yes, I know… different tools, different ways of seeing it… but everyone was already used to what centralized SCMs call their operations, and I think it would only help git adopting same names for the same operations, and inventing new ones for those proper of decentralized operations. Anyway, once you get it (and I have not completely got it yet), it seems all flow as expected. If this adaptation fails, there’s still Easy Git to the rescue!

One last thing that I think contribute to the “git sucks” effect: git-svn. This is a great tool, but it was built from git’s point of view… Given it’s intended as a glue for Subversion newcomers, it would benefit more from being built from svn’s point of view. This was mentioned by a colleague developer in my company, when he just couldn’t understand why one have to git svn rebase instead of a simple update. So git-svn also suffers of the “bad command naming habit” git do. Of course, that given that you came from this environment (I am sure git and git-svn makes perfect sense for Linus & cia 🙂 ). I have not tried yet, but yap seems to be targeted on providing an alternative to git-svn.

Quick and Dirty VPN with pppd and ssh

Posted by – 12/01/2009

This is just to keep a reference (so I don’t have to google it again 🙂 ): One can create a “quick and dirty” VPN using pppd and ssh:

bash$ /usr/sbin/pppd noauth pty 'ssh -x -t -e none remote_user@remote_server /usr/sbin/pppd passive noauth'

This assumes both users (local and remote) have permissions to run pppd (some sudo trickery may become very handy) and that no password is asked by ssh (password-less key authentication).

Quite handy, ain’t it?

As old as good: One Time Passwords

Posted by – 12/09/2008

People frequently ask me what I am doing typing on my Palm right before logging in one of my remote systems. The answer is quite simple: “generating my next password”. People always seem puzzled by that answer… Maybe I am just too old to have had only telnet sessions available to remote connections (that was the time before SSH took over)… or maybe I am just too paranoid regarding the access to my systems… Anyway, I like One Time Passwords, and here is an article I can refer to when I get asked again 😉

One Time Passwords are just that: passwords that are good for one time use. They never repeat and once used you can throw it away securely. They were quite common when the authentication was done in clear text (so that any man-in-the-middle could steal your passwords), back in the r-tools age (rcp, rsh, rlogin, rexec, etc). After the SSH-related tools took over, providing easy tunneling and remote access, MITM attacks were of much concern, so OTPs became less relevant. What a shame, for they even have a couple of standards for those!

But there’s still room for OTPs… Question: Is it easier to deploy a MITM attack or a keylogger? That’s right… We are always connecting to our remote systems in public terminals (well… at least I am – right now typing from the hospital computer), and a keylogger is so easily installed in one of those terminals, even remotely, that no one would ever get close to deploy a refined MITM attack just to steal someone’s password. One would just install a keylogger! All the security SSH provides would just be gone by then. That’s why I use SSH to connect to my remote machines, but use OTPs to authenticate myself.

It’s so easy to deploy it. In Debian you’ll find packages opie-server and libpam-opie and those are the only things you’ll need on the server side (besides SSH, obviously). OPIE means “One-time Passwords In Everything”, and combined with PAM, one can really use it everywhere.

After installing it, you’ll have to generate the password file for your account:

spectra@home:~$ opiepasswd -c
Adding spectra:
Only use this method from the console; NEVER from remote. If you are using
telnet, xterm, or a dial-in, type ^C now or exit with no password.
Then run opiepasswd without the -c parameter.
Using MD5 to compute responses.
Enter new secret pass phrase:
Again new secret pass phrase:
ID spectra OTP key is 499 ho6484

The pass phrase will be used to generate the passwords in a step before your login. Please, try not to forget it (specially if you’re following this article and playing with some remote system at the same time). Now you can edit /etc/pam.d/ssh file (or its equivalent in non-Debian systems) to require that kind of authentication. Mine just looks like this:

# /etc/pam.d/ssh
auth       required     pam_env.so
auth       required     pam_env.so envfile=/etc/default/locale
auth       required     pam_opie.so

First two lines are unrelated and just load the environment variables. Last line is where the fun is. Please, note two things: (1) I removed references to pam_unix.so, which is what would ask for my “real” password, that I want to disable (no login is allowed with that password). And (2), I declared it as required, meaning that failing it will keep one out of the system.

We are not ready yet! SSH will work by now, but will not present you the OTP challenge. Probably you could still login, but you’d have to remember which is the current password (Trust me, you would not!). To get the challenge you’ll need to enable it – in /etc/ssh/sshd_config change the following line:

ChallengeResponseAuthentication yes

That’s it. Now to login to your remote machine, that’s what will usually happen:

spectra@hospital:~$ ssh home
otp-md5 498 ho6484 ext, Response:

Voilà! It asks for password #498. By default, it starts with 500 passwords and goes down from that. Password #498 were asked, so the next will be #497. After that, #498 is not useable anymore, and #496 is not useable yet. You can generate a list of those passwords (let’s say 10), print it and keep it in your pocket. This is the command you’d use for that:

spectra@home:~$ opiekey -n 10 498 ho6484
Using the MD5 algorithm to compute response.
Reminder: Don't use opiekey from telnet or dial-in sessions.
Sorry, but you don't seem to be on the console or a secure terminal.
Warning: Continuing could disclose your secret pass phrase to an attacker!
Enter secret pass phrase:

That is not so secure, since you can loose the paper and be doomed… Luckily there are lots of small softwares that does this generation for you. Some you can use from your Palm or from some J2ME-enabled phone (such as N95). Some your can use from another (trusted) computer. Some are even online, written in javascript!

There are at least one other side-benefit of using OPIE as above: You can give away your user password (even root password – OK, probably not a Good ThingTM), that the system would still be secure, since it only allows SSH authentications via OPIE! If the session is started with a username whose opiepasswd was not activated (first step… scroll back to the beginning of the article), SSH will greet you with a bogus challenge… only “opie-activated users” will be allowed to login with the above configuration.

Easy enough, isn’t it? Now, next time you see me typing on my Palm before opening an SSH connection you’ll know what I am doing… 😉