Linux/ssh

[zahc]

I have a laptop and a desktop. Both of them are connected to the tubes wirelessly, using the 2wire router that came with my ATT subscription.

I want to be able to grab files from my desktop, no matter where I am with my laptop, and vice versa if the laptop is on. I understand they have this new thing called ssh that enables this, but I don't know enough about the intertubes, ports, security, and so on to set it up. Security is fairly important to me, but I'm tired of emailing files to myself or having to kick my wife off the desktop so that I can get at something.

[Vodka7]

SSH is great, but setting it up for yourself securely is not easy.  If you're on Ubuntu, they probably have some GUI that runs you through it with OK settings, but there's a lot you really should be doing yourself (disabling passwords for keyauth, setting timeouts, etc.)

How many files are we talking about?  I keep most of my home directory in my Dropbox folder, and just run Dropbox on my two desktops.  Any time I change a file on one PC, it syncs it with the Dropbox servers, then with my other PC.  Brain dead easy, nothing to remember to run.  Everything's encrypted going to and from their servers.

Only downside is the free service is limited to two gigs (storage, not transfer.)

If you sign up using this link, we both get an extra 0.25 gigs - https://www.dropbox.com/referrals/NTIxNTI1NzI5

If you don't care about being able to access the files outside of your home network, you can always consider SAMBA or NFS for filesharing.  Much easier to set up--setting up SAMBA in Ubuntu shouldn't take more than five minutes.

[Nick1911]

Both machines are linux, right?

Is SSH not enabled by default?  At least for me, all I've ever had to do is fire up putty (from a windows box), and give it the IP of the linux box.  Enter valid system credentials, and viola!

[Nitrogen]

Ubuntu desktop does not install sshd by default.  sudo apt-get install openssh-server will get you there.

You need to tell us what OS each computer has so we can give you better info.

Assuming they are both ubuntu, that'll get you started.

The next thing you'll need to do is set up port forwarding on your firewall to the linux box at home.  Cant really help you there unless you tell us about your 2wire firewall box.  Reading the docs there should help you.

As far as security, run the following command:
egrep -e "(Protocol|PermitRootLogin|PermitEmpty)" /etc/ssh/sshd_config

and make sure it returns like so:

Code: [Select]

celiac:5:~$ egrep -e "(Protocol|PermitRootLogin|PermitEmpty)" /etc/ssh/sshd_config
Protocol 2
PermitRootLogin no
PermitEmptyPasswords no

Protocol can be 2,1, but for max security, set it to "2" only.

Also, make sure any account you have has a good password on it.

Another thing you can also do is change the port that ssh will be redirected to on your firewall.  For personal stuff at home, I change mine, makes it a tad harder to mess with, but not much.


If none of these things make sense to you, you'll want to reconsider doing this until they do.

[mtnbkr]

Simpified steps:

1.  Install sshd if it isn't installed already

2.  Configure sshd to only allow the user(s) that need ssh access (this is for security)
in /etc/sshd_config/ add the appropriate user name(s) to the AllowUsers line.  Only allow those that NEED ssh access.  I recommend a nonroot user.  Once you log in, su to a more powerful user.

3.  Configure port forwarding on your router to forward any port 22 traffic to the appropriate box.  Then, when away from home, you'll ssh to the public ip of your internet router.  That IP will change periodically, so you'll need to get set up with a dynamic dns service (I use dyndns.org).  Then, you'll want to set up a script to automagically check your IP and update the dns record if it has changed. 

If you are just moving files, you can use scd to move them.  It's like ftp, but based on ssh, therefore more secure.

For more security, enable iptables and use the following statement:
iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH -j DROP

This is the statement from my system, you'll need to change eth0 to match your LAN adapter (the one that will be receiving ssh requests).

This will drop any host that sends more than 2 ssh requests to your system in 60seconds or less.  Why is this important?  Because hackers will find your open ssh port and they will hammer it mercilessly.  I see it in my logs every night (I get certain stats email to me daily).  This will at least force them to take a break after two attempts within a minute.  I rarely see the same IP come back after those two attempts.  To them, it appears the host has gone offline.  If you want to allow more attempts, change "hitcount 3" to whatever number you want.  The number will be 1 more than the number of allowed hits.  If you want to allow 10, use 11.

There's  more you can do, but that gets you started.

Chris

[mtnbkr]

Nitrogen is correct about using a nonstandard port for port forwarding to your system for ssh.  I don't do that because I sometimes ssh into my box at home from work and using a standard ssh port makes it easier.  A nonstandard port might get blocked (ssh should be blocked too, but it wasn't).  His other suggestions are spot on as well.

Oh, this will all fail if your ISP doesn't allow inbound connections through your router.  Some do, some don't.  Some only block certain ports (Verizon FIOS doesn't allow port 80/httd, but does allow ssh).

Chris

[mtnbkr]

Here's the output from last night's security report, the one that gets emailed to me daily:

Invalid Session Attempts
Feb 13 15:17:22 server sshd[11858]: Failed password for invalid user root from 222.68.194.69 port 46474 ssh2
Feb 13 15:17:27 server sshd[11860]: Failed password for invalid user root from 222.68.194.69 port 46817 ssh2
Feb 13 17:00:10 server sshd[11924]: Failed password for invalid user root from 82.77.21.38 port 45406 ssh2
Feb 13 17:00:13 server sshd[11926]: Failed password for invalid user root from 82.77.21.38 port 45791 ssh2
==================================================================================
Sessions Not Allowed By Policy
Feb 13 15:17:20 server sshd[11858]: User root from 222.68.194.69 not allowed because not listed in AllowUsers
Feb 13 15:17:25 server sshd[11860]: User root from 222.68.194.69 not allowed because not listed in AllowUsers
Feb 13 17:00:07 server sshd[11924]: User root from 82.77.21.38 not allowed because not listed in AllowUsers
Feb 13 17:00:11 server sshd[11926]: User root from 82.77.21.38 not allowed because not listed in AllowUsers

Notice a few things?  First, they're blocked because of an invalid password.  There's no root account. Second, they're blocked because the user account they're using isn't in AllowedUsers.  Finally, they only get 2 attempts each because of the iptables statement I showed you above.

Chris

[mtnbkr]

You can also set up iptables to add failed IPs that fail certain tests to a blacklist. I would do that, but if I have trouble logging in for some reason, I don't want to put the IP I'm coming from on the blacklist.  My current methods work well enough.

Chris

[tyme]

iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH -j DROP

This will drop any host that sends more than 2 ssh requests to your system in 60seconds or less.  Why is this important?  Because hackers will find your open ssh port and they will hammer it mercilessly. 

I don't particularly like the iptables recent module.  I prefer the hashlimit module for an iptables-only solution, but even that is not very flexible.

I like sshguard.

[mtnbkr]

I don't particularly like the iptables recent module.  I prefer the hashlimit module for an iptables-only solution, but even that is not very flexible.

I like sshguard.

Why do you not like the RECENT module?  Not trying to be argumentative, I'd like to know more. 

Thanks for the sshguard link.  I've never heard of that. Dunno if I'll change anything, I've had my solution in place for over a year and it works for me, but it's always good to learn new methods, right? :)

OP might consider a "knock knock" system if he really wants to tighten things: http://aplawrence.com/Security/sshloginattack.html

I read about a similar method in Linux Journal a couple months ago.  It could be problematic if you're coming from a network that doesn't allow all sorts of random crap to traverse the firewall outbound (or whatever port you use to "knock"), but would work fine if coming from another residential ISP connection or some such.

Chris

[tyme]

First of all, in the example you gave, where's the --set rule?  Hashlimit works in the opposite way: the main rule is the one that allows traffic up to a certain limit; with Recent, the main rule is the one that blocks, and it has to come first, making logging annoying -- you need a duplicate rule with -j LOG instead of -j DROP.  With hashlimit, the main rule allows legit traffic, so then the logging rule doesn't need to even load the hashlimit module (see below).

the recent module doesn't let you have a netmask for blocking.  hashlimit does.  Back when I was using that, I had it block the /24 that attacks came from.

Another thing I like about hashlimit is the ability to allow for a burst in addition to the normal rate limiting, since it's effectively a token bucket filter.

Chain ssh-ext (0 references)
 pkts bytes target     prot opt in     out     source               destination
31957 1908K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: up to 2/min burst 10 mode srcip srcmask 24
 1276 76148 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4
 1276 76148 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

That's what I used to use.  With ipt-recent, it looks something like this.

   0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           recent: CHECK seconds: 60 hit_count: 3 name: tel side: source LOG flags 0 level 4
    2   120 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           recent: UPDATE seconds: 60 hit_count: 3 name: tel side: source
    3   180 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           recent: SET name: tel side: source

That's why I think the hashlimit solution is cleaner and more flexible.  If your default policy is REJECT/DROP, and you don't want to log, then a hashlimit setup requires only one rule.  ipt-recent needs two.

The reason I ditched both of those solutions is because they're naive:  they cannot distinguish between legit traffic (successful logins) and illegitimate traffic (failed logins), at least not without an absurd amount of additional rules to remove suspect addresses when a certain threshold of --state ESTABLISHED traffic is seen from them, and re-add them if enough --state NEW traffic is seen.  If I have a script that logs in 20 times in rapid succession, it doesn't matter that it successfully logs in each time (using key auth, even).  It still gets blocked.

If you can guarantee that you never need to login a bunch of times in quick succession, then that's not a problem.


Port knocking is great if you want to set it up, but the main reason to do that is to add a layer of security against pre-login ssh security holes.  Password brute forcing is easily dealt with (first by picking a good password or disabling password auth entirely, then by using iptables to avoid having logs flooded with ssh login attempts) without resorting to port knocking.  I have a gripe about port knocking, like I have gripes about everything.  Using an iptables-only port knocking setup requires a lot of rules.  Complicated rulesets mean more chance of mistakes, potentially bringing down the entire iptables house of cards.
http://www.zeroflux.org/projects/knock

Using userspace programs like sshguard or knock is also potentially problematic, since if something happens to those processes you lose the protection they offer.  But I still like those solutions better than iptables-only.


It's also worth noting that while --rttl reduces the chances of successful DOS attempts, it also means that any attacker that has root-level access to the attacking host gets approximately 240-ish times as many guesses before being blocked, since they can change their TTL before each attempt.

[mtnbkr]

First of all, in the example you gave, where's the --set rule?

Sorry,I left that out.  Entire section below:

iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH

iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH -j LOG --log-prefix "EXCESSIVE SSH "

iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH -j DROP

The reason I ditched both of those solutions is because they're naive:  they cannot distinguish between legit traffic (successful logins) and illegitimate traffic (failed logins), at least not without an absurd amount of additional rules to remove suspect addresses when a certain threshold of --state ESTABLISHED traffic is seen from them, and re-add them if enough --state NEW traffic is seen.  If I have a script that logs in 20 times in rapid succession, it doesn't matter that it successfully logs in each time (using key auth, even).  It still gets blocked.

If you can guarantee that you never need to login a bunch of times in quick succession, then that's not a problem.

That's the case for me.  I only log in to manage the box or move files around (for example, move a file from storage to the the www directory so someone can grab it).  I've never needed more than 1 or 2 logins at a time, much less multiples in quick succession.  This is a private box at home, not a production system.

It's also worth noting that while --rttl reduces the chances of successful DOS attempts, it also means that any attacker that has root-level access to the attacking host gets approximately 240-ish times as many guesses before being blocked, since they can change their TTL before each attempt.

So far, I haven't seen anyone hit my box more than twice on any given night except for a couple that hit it 3-4times.  The only ports open through my router are 22 and a non-standard port for http traffic since VZ Fios doesn't allow inbound 80.

Thanks for the info though.  I just started messing around with Iptables a year ago (never used it at work since we had dedicated firewalls all over the network) when I decided I needed something to block unauthorized traffic (lots of ssh hits after getting FIOS).  Since I couldn't enumerate every IP I would be coming from, using a rate limiting technique like RECENT seemed ideal.

Chris

[lee n. field]

I have a laptop and a desktop. Both of them are connected to the tubes wirelessly, using the 2wire router that came with my ATT subscription.

I want to be able to grab files from my desktop, no matter where I am with my laptop, and vice versa if the laptop is on. I understand they have this new thing called ssh that enables this, but I don't know enough about the intertubes, ports, security, and so on to set it up. Security is fairly important to me, but I'm tired of emailing files to myself or having to kick my wife off the desktop so that I can get at something.

SSH ain't new.

Everywhere, meaning from the outside world too?

Dynamic DNS or static IP through your ISP to give you some fixed place to point to.

Install openssh server on the desktop.  Set the desktop's firewall, if enabled, to accept ssh traffic.

Static IP on your desktop, or (better) fixed assignment of a given IP address set up on your DHCP server (probably your router).

Forward port (quick google search) 22 traffic from the router to your desktop's IP.

A script something like this

cd
rsync -avz -e ssh  --recursive --delete <ip>:/home/<your uid>/mail/ /home/<your uid>/mail
rsync -avz -e ssh  --recursive --delete <ip>:/home/<your uid>/Pictures/ /home/<your uid>/Pictures
...

for whatever directories you want to copy from your desktop to your laptop.  <ip> and <your uid> changed to appropriate values.  Another script, set up likewise to sync back to the desktop.  Set the execute bit.

"ssh-keygen" on the laptop.  Copy the ~/.ssh/id_rsa.pub file from your laptop to the same location on your desktop, then append it to the ~/.ssh/authorized_keys file.  test by ssh-ing from a command line to the desktop.  If done right, you shouldn't be asked for a password.

If all you want is one file and you know what it's called and where it is, skip the script and use scp.  

This is how I sync my laptop and my desktop.  I haven't needed to set it up from the outside world, but it should work.

Is SSH not enabled by default?

ssh server isn't, not on ubuntu.

[zahc]

I have to ignore most of this thread because I don't understand it.

This is the problem I'm having. Say I've been working on a LaTeX document on my desktop. When I am home sitting on the couch with the laptop, if I want to work on that document, I have to go to the desktop and email it to myself or put it on a flashdrive. And now there are two versions of the file, and I will have to do the same thing to get the new version back onto the desktop. What I want to be able to do is cd to the directory on my desktop that has the file, and work on it remotely, cp it, edit it, whatever. Having a shared folder on the web somewhere and a script to keep it synced isn't that useful, unless it's my entire home directory, because the file I need will never be in that folder. I want to be able to use my laptop to play movies and audio files that are on my desktop. And so on.

I'm running the latest Ubuntu on both my desktop and laptop.

1.  Install sshd if it isn't installed already

done.

2.  Configure sshd to only allow the user(s) that need ssh access (this is for security)
in /etc/sshd_config/ add the appropriate user name(s) to the AllowUsers line. 

There is no such line in my file

Code: [Select]

chaz@singularity:/etc/ssh$ less ssh_config | grep Allow
chaz@singularity:/etc/ssh$


[mtnbkr]

That's because you're looking in ssh_config, not sshd_config. Two different files...

Actually, for what you want to do, using NFS (assuming both systems are Linux) or Samba (assumes the laptop is Windows) would be better.  I wouldn't use those methods over the Internet though, only over the local network (ie home).

Chris

[zahc]

Well, sshd_config doesn't have such a line either.

[mtnbkr]

It's in mine:

/etc/ssh$ grep mtnbkr sshd_config
AllowUsers mtnbkr

If not, add this line (vi, emacs, etc):
#AllowUsers only allow a list of users that can ssh into your server

Then follow with:
AllowUsers <userid you wish to allow>

Save, restart sshd, and test with an allowed account and a non-allowed account.

Chris

[tyme]

svn or git or mercurial for a (text-based) document repository.  git is almost certainly the best choice.  all you need is ssh access, and you can check out and check in files from anywhere.  DO NOT use such a repository for opaque binary-ish files unless they're very small or unless you rarely change them.

setting up a remote (secure) filesystem like nfs+krb5 or samba+krb5 is possible but likely to be a PITA.  a lot of ISPs block incoming cifs connections so that option may be not be available.  I tend to use rsync (over ssh) to mirror stuff remotely and then sync it back up.  It's not seamless but it's good enough.

[zahc]

sweet...all I did was install openssh-server, and added that line to the config, and now I can run ssh chaz@mylaptop and it will prompt me for my passwords, and then I can just surf the other computer. My passwords aren't that strong though so I think I should do some of that other stuff. I didn't forward port 22 or anything; it must already have been or something. Is my computer super-vulnerable right now?

[mtnbkr]

setting up a remote (secure) filesystem like nfs+krb5 or samba+krb5 is possible but likely to be a PITA.  a lot of ISPs block incoming cifs connections so that option may be not be available.  I tend to use rsync (over ssh) to mirror stuff remotely and then sync it back up.  It's not seamless but it's good enough.

It sounds like he's doing this over the local network, so ISP issues won't be a problem.

My passwords aren't that strong though so I think I should do some of that other stuff. I didn't forward port 22 or anything; it must already have been or something. Is my computer super-vulnerable right now?

If you're on your home's local network, you don't need to forward port 22.  That's only necessary if you're trying access your desktop from the Internet (ie from Starbucks).  If you don't plan on doing that, then you're ready to go.  You might work on a better password, but between the SSH encryption and your wireless encryption, you should be "safe enough" for now.

Chris

[zahc]

Cool! Now I don't have to kick the wife off the computer to grab a file, plus I can listen to music anywhere. I reset my wireless network encrypition to WPA2 with a new passphrase and ESSID broadcast turned off. I'll worry about getting in from the outside world if it becomes something I want to do more often.

[lee n. field]

and now I can run ssh chaz@mylaptop and it will prompt me for my passwords, and then I can just surf the other computer.

Do the ssh-keygen thing from my post above, and you won't have to worry entering your password every time.

[zahc]

I'm having this issue now, where for some reason, it will not connect to ssh either between my desktop or laptop based on the name of the machine:

chaz@singularity:~$ ssh chaz@brutus
ssh: Could not resolve hostname brutus: Name or service not known

However if I go into my router and find the IP of brutus, it works

Code: [Select]

chaz@singularity:~$ ssh chaz@singularity
chaz@singularity's password:

Code: [Select]

chaz@singularity:~$ ssh 192.168.1.72
chaz@192.168.1.72's password:
Linux brutus 2.6.31-19-generic #56-Ubuntu SMP Thu Jan 28 02:39:34 UTC 2010 x86_64

...
I don't remember doing anything to change anything, why is it doing this?

I'm building a HTPC which I want to boot from a flash drive and only have it access media on my desktop, not have it locally. Will sshfs work ok? I figure I can write a script to mount the desktop's ~/video directory upon boot.

[Nitrogen]

You need to set up a name service.  Either set up a dns server, or set you /etc/hosts on each machine with each other's hostname and address.

[mtnbkr]

What Nitrogen said...or just use the IP.  With only a handful of systems, IPs works just as well as names.

Chris