Wednesday, April 19, 2006

Five-Minutes to a More Secure SSH

Note: Updated (twice) below

Here is a quick way to drastically improve the security of your OpenSSH server installations. Apart from past flaws in the OpenSSH daemon itself that have allowed remote compromise (very rare), most break-ins result from successful brute-force attacks. You can see them in your firewall, system or auth logs, they are an extremely common form of attack. Here is an excerpt from the /var/log/messages file on a CentOS Linux box (the attacking hostname has been obfuscated). You can see multiple attempts to login as users root and ftp. Also note the time between repeated attempts - one second or less, much too quick to be a human. This is an automated attack.

Apr 9 09:34:51 server1 sshd(pam_unix)[1511]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=host52-182.foobar.pl
Apr 9 09:34:52 server1 sshd(pam_unix)[1513]: check pass; user unknown
Apr 9 09:34:52 server1 sshd(pam_unix)[1513]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=host52-182.foobar.pl
Apr 9 09:34:53 server1 sshd(pam_unix)[1515]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=host52-182.foobar.pl user=ftp
Apr 9 09:34:53 server1 sshd(pam_unix)[1517]: check pass; user unknown
Apr 9 09:34:53 server1 sshd(pam_unix)[1517]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=host52-182.foobar.pl
Apr 9 09:34:54 server1 sshd(pam_unix)[1519]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=host52-182.foobar.pl user=root
Apr 9 09:34:55 server1 sshd(pam_unix)[1521]: check pass; user unknown
Apr 9 09:34:55 server1 sshd(pam_unix)[1521]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=host52-182.foobar.pl
Apr 9 09:34:56 server1 sshd(pam_unix)[1523]: check pass; user unknown
Apr 9 09:34:56 server1 sshd(pam_unix)[1523]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=host52-182.foobar.pl

From personal experience with clients over the years, I have found that most administrators tend to install an SSH server and leave it at its default settings, typically to allow password authentication and root logins. Many don't even know that there is an alternative (key-based authentication), or they think the alternative is too hard to use. It is not - it takes all of five minutes to configure key-based authentication and disable root logins, and the security gains are enormous. Below, I'll step you through the process. I add comments where a step may not be needed.

Configuring and Testing Key-Based Authentication

This is not really a hard as it seems. By default, all recent OpenSSH configurations allow public key authentication. You just have to generate a pair of SSH keys on the client, and append the generated public key to a file named authorized_keys on the server. This works on any Unix/Linux with OpenSSH, or even under Windows with Cygwin's OpenSSH port (I won't mention it further here, but If you are stuck on a Windows client without Cygwin, use PuTTY and check out Using PuTTYgen).

Let's say you routinely use SSH to login from your home workstation, sshclient, as user obiwan, to a remote SSH server as user vader. For consistency's sake, we'll call the remote server sshserver. I'm assuming you have working password authentication already.

On sshclient, log in under your user account obiwan, and run the following three commands.

obiwan@sshclient:~$ ssh-keygen -t dsa

This first command generates the public/private key pair for you, assigns a passphrase to the private key, and stores both keys in the directory ~/.ssh by default. Just accept the defaults, and enter a passphrase when prompted.
obiwan@sshclient:~$ cat ~/.ssh/id_dsa.pub | ssh vader@sshserver "cat >> .ssh/authorized_keys"

This command appends your public key, which is stored in ~/.ssh/id_dsa.pub by default, to the authorized_keys file on the remote host. One caveat, you may not have a '.ssh' directory on the remote server in vader's home directory. Create it if needed.
obiwan@sshclient:~$ ssh vader@sshserver chmod 600 .ssh/authorized_keys

This last command changes the permissions on the remote authorized_keys file to be more secure, and to prevent a common problem that prevents key-based authentication.

Now, test SSH login to 'vader@sshserver'. You should be prompted for a passphrase this time, not a password. Enter the passphrase you chose when you created your keys, and you should be logged in.

Disabling Password Authentication

Once key-based logins are working, disable password authentication. Find your SSH server's configuration file. This is usually in /etc/ssh/sshd_config. Find the line that says:

PasswordAuthentication yes
and change it to

PasswordAuthentication no
You should also disable challenge-response authentication, in case your version of OpenSSH is using PAM to authenticate (see updates below for an explanation):

ChallengeResponseAuthentication no

Disabling Root-Logins

Finally, disable root logins. Kudos go to NetBSD and FreeBSD, whose default configurations do not allow root logins, so there will be nothing to do for you to do in this step if you are using a recent version of either one. OpenBSD and most Linux distributions allow root logins by default. Again in /etc/ssh/sshd_config, find the line that reads

PermitRootLogin yes
and change it to

PermitRootLogin no
Reload your SSH server's configuration with /etc/init.d/ssh reload (Debian Linux-based), service sshd reload (Red Hat Linux-based), /etc/rc.d/sshd reload (NetBSD/FreeBSD) or just send sshd a HUP signal, usually with something like kill -HUP pid, where pid is the process ID of the SSH server, you can get it quickly on any Unix platform by running something like ps ax | grep sshd.

That's it. There is much more to OpenSSH configuration and security, but these few, simple steps will go a long way towards preventing brute-force attacks and letting you sleep at night. Repeat the above steps on all your SSH servers, copying your SSH public key to each server as needed (it may not be obvious if you've never used key-based authentication before, but don't regenerate your keys for each host).

Update:

One Digg reader commented that if UsePAM were set to 'yes', that this would override the 'PasswordAuthentication no' setting. This is not quite true (see below). I did some poking around, and it turns out this is true, but only if your version of OpenSSH was compiled with PAM support. Of the OS's I looked into for this article, only FreeBSD enables PAM support in OpenSSH, and has UsePAM default to 'yes' by default (since version 4.x? Anyone know for sure?). NetBSD and OpenBSD don't include PAM support in OpenSSH, and in Debian/Ubuntu/Red Hat, UsePAM defaults to 'no'. So be sure to check your sshd_config for a UsePAM directive, and change it to 'UsePAM no' if needed.

Update II:

Thanks to Darren Tucker, one of the OpenSSH/OpenBSD developers, who has commented and clarified the 'UsePAM' directive. It turns out that you need to set 'ChallengeResponseAuthentication' to 'no' in order to disable PAM authentication. He correctly points out that while OpenSSH with PAM support may allow password auth (among others), it uses a different method internally as compared to standard OpenSSH password authentication. The latest FreeBSD man pages have this to say, which may help to clarify the situation a bit:

Note that if ChallengeResponseAuthentication is 'yes', and the PAM authentication policy for sshd includes pam_unix(8), password authentication will be allowed through the challenge-response mechanism regardless of the value of PasswordAuthentication.

Technorati Tags: , ,

63 comments:

Keith said...

This is primarily quite a simple setup, by changing the script configure for SSH server. This may be more secure, but it may not be helpful for administrators who need to administer remote machines, and having SSH Rootlogin disabled.

centyx said...

My personal favorite for ease of administration is the option 'PermitRootLogin without-password' which allows root login via key-based authentication.

Also, don't forget to disable SSH Protocol version 1, unless you absolutely need it.
Change the line "Protocol 2,1" to "Protocol 2."

Scott said...

I've found that just changing the default SSH port (22) will stop the brute force attacks. I used to see entries like that daily and since going to a different port I haven't seen one.

Anonymous said...

I just installed libpam-opie and I think it's the final solution. No keys to use on untrusted system (as it happens when I connect to my server from customer's PC), neither I worry about keylogger and so on. Easy to install and to use with a free OPIE password generator written in java on my cellphone.

twowordz said...

I do not permit root login and I use denyhost for my servers.

Denyhost is a daemon that will log failed logins and add the attacker's address to hosts.deny automaticly.

Changing SSH port is security by obscurity, not a good practice if you ask me.

Mordac said...

A nice script for temporarily blocking IP's of brute force attacks is at:

http://mr.uue.org/projects/skds/

It requires python and shorewall. I needed to adjust the regex to match the log entries Debian produces.

I'm very happy with it. Now instead of hundreds of entries I see three and they're blocked.

Packetmonger said...

While I like the idea of using PK's for authentication, and use it when I can, some situations exist where allowing key-based auth is a bad thing.

At my office, I run an SSH gateway. I have a user community that has a large number of advanced Linux developers, including a few you would recognize.

Now, most of these folks are nice, and they are bright. And they sometimes even listen.

That said, some of them don't listen, or are sure they know better than others.

Some, not all, but some, insist on using private keys without passphrases.

I know this is convenient for them, but it makes me just a bit nervous, since they also seem to get frustrated when I disable SSH V1.

I think at one point I managed to get a configuration that required both a Key and a password, but that just ends up causing an unreasonable support level. We auth to a Radius server, so when I get budget I'll be deploying a SecureID type solution.

Anyway, just pointing out that sometimes it isn't clear that one way is always better than the next.

Now, if only someone could point me to a good guide/toolkit for implementing a padded shell, I would be happy.

Michael said...

I agree twowordz, DenyHosts is an excellent tool for blocking these attacks.

Anonymous said...

"Changing SSH port is security by obscurity, not a good practice if you ask me."

but changing the SSH port as well as the other security measures in 'security in depth', which is good practice

Doug said...

Thanks for the comments. This is a rather simple setup, and there is much more that can be done, but I wanted to make it quick, yet also effective. Security is all too often set aside for convenience (I'm guilty of it myself). If a solution is too hard, most admins won't use it.

One interesting solution is port-knocking, which allows the server port to remain closed until a specified sequence of packets hit it.

Doug

Anonymous said...

I suggest using R-fx Networks APF in conjunction with BFD. APF is a software firewall and BFD is a Brute Force Detection program. They work together to log incoming SSH, FTP, POP3 connection attempts. If there are too many failed attempts from a specific IP address the IP gets blocked and all further traffic is dropped by APF.

gullevek said...

I use key auth only if I have a user that needs to login automatically for a script (backup, etc). The rest hast to type in their passwords. Plus users who have keys can only login from the box where their key is, so they would need to take this key to all the other boxes where they want to login. Not very convenient for me.

Furthermore, you should always add the users to the Allow Users list to have just a small user list who is actually allowed to login.

Root login has to be off, there is no excuse and no need to allow root login, this can all be done through a user (login, fileupload, etc)

reverendtimothy said...

Cheers dude. I get brute attempts quite frequently, and being new to SSH, this is just what I needed.

folded space said...

using only key-based authentication is fine as long as you always access the server from known machines. one huge advantage of SSH is that it's one of the few reasonably secure ways to access a machine from an arbitrary location with a minimum of hassle. the Java version of SSH loads into a browser and it has saved my bacon more than once when i had to get into a system to solve a problem but didn't have my blessed laptop with me. all i needed to do was borrow a browser window and bingo - ssh session into server and problem solved.

Anonymous said...

You don't need shorewall or anything fancy, the kernel has all you need to block these repeated automatic connections.

iptables -A INPUT -p tcp --dport 22 -m recent --set --name ssh --rsource
iptables -A INPUT -p tcp --dport 22 -m recent ! --rcheck --seconds 60 --hitcount 4 --name ssh --rsource -j ACCEPT

The first rule says to record the IP of the sender whenever someone tries to connect to port 22. The second rule checks to see if the source has attempted t connect 4 or more times in the last 60 seconds. If not, allow the packet (since my policy is DROP, this is the only way the packet can get through).

Anonymous said...

I second the recent module of iptables. When I first started seeing these brute-force attempts, I went looking and found that, and it works like a charm. Sure they can still get an attempt or three at your passwords, but if you require strong passwords, and dont have services such as finger turned on (who still does anyway??) they are guessing at usernames as well as passwords, and the chances of them hitting both at the same time become about as likely as them logging in by spoofing a key. If you are uber-paranoid, combine this with a simple port-knocking setup (also easy to do with the recent module) and they dont even get a single chance.

Anonymous said...

If you can't lock down access via entries in hosts.allow then Port knocking is an excellent alternative.

There are 65536 ports, and knocking 3 in the right sequence to open up Port 22 works real well. Especially if you reset the checks on ports surrounding the 3 key ports. That way on sequential scans, they will never figure out your combination.

Port knocking is great cause when you are using a public computer or at some wifi point, you will be able to SSH into your box without worrying about opening up 22 to everyone.

Anonymous said...

There's a somewhat unclear bit - this command:

obiwan@sshclient:~$ cat ~/.ssh/id_dsa.pub | ssh vader@sshserver "cat >> .ssh/authorized_keys"

I see now that it's all one line, but because of the limited column width of this page, it looked like TWO commands:
obiwan@sshclient:~$ cat ~/.ssh/id_dsa.pub | ssh

vader@sshserver "cat >> .ssh/authorized_keys"

Maybe I'm just slow, but the user@host bit on the second part made my lazy brain think I was looking at a bash prompt *on Vader*.

Anonymous said...

An easy method is to use no obvious usernames (like: jason, bob, admin), good passwords and the AllowUsers directive in your sshd_config

Anonymous said...

Another trick that isn't always appropriate, but sometimes is:

Setup your firewall to only allow ssh connections from known ip addresses.

But be careful that you always have two distinct routes in, as if one machine dies you don't want to be locked out of your box.

Anonymous said...

If you want a really good video on how to do this (the video is for a mac but the technique can be applied to any ssh install), view the "How to use your mac from anywhere" video. http://howto.diveintomark.org/remote-mac/

Anonymous said...

DenyHosts has already been mentioned as an excellent tool to stop brute-force attacks on SSH logins. With a little hack it is even possible to run it on a per-login base so that any repeated login attempt from the same IP address gets blocked after exactly n failed attempts. Setting n in DenyHosts to 3 for unknwon users and to 5 or more for known users works very well. For details please see: http://tdot.blog-city.com/securing_ssh_with_denyhosts.htm

Anonymous said...

I would also like to recommend OPIE (or S/Key which is a better-known version), just the another anonymous poster did a few posts back. It offers even better protection, because it protects against keyloggers, and even theft of RSA keys. Remember: an RSA key can be stolen too. Especially if you carry it around on a USB key and plug it into public computers in an internet cafe.

OPIE protects against all that. It works a bit similar to RSA SecureID, you use a calculator program on a separate device (such as your java-enabled phone) to encrypt a password using a different sequence ID every time. It then returns a sequence of 6 short words (4 chars max each) which you type as your password. Even if your phone gets stolen it's still useless because you have to enter a password into the calculator to use it.

This, combined with DenyHosts (www.denyhosts.org) to block IP's after a specified number of login failures and running SSH on a different ports, is in my opinion safer than using RSA keys.

The only problem with it is that it's a bit of work to enter everything but fortunately most OPIE calculators will remember the sequence and seed number so you only have to re-enter your password.

1337 hax0R said...

scott: 3Y3 M s0 g0nna p0r+scan u d00d

Anonymous said...

While there are a lot of people posting solutions that involve either hosts.deny, or firewall rules, I usually avoid these methods, since it is possible for somebody to either spoof connections or interfere during the login process by implementing a mitm which corrupts the login process. While these attacks would be unusual, they could effect a DOS attack where you as a legitimate user cannot log back into your system.

As Kaminsky said; I love when people give me remote access to control their iptables firewall.

Essentially, SSH is highly secure for a reason. Pick a good passphrase and/or password and the brute force attacks are moot anyways. If they make you nervous, then you have placed too much trust in your users.

Robert Fisher said...

"This may be more secure, but it may not be helpful for administrators who need to administer remote machines, and having SSH Rootlogin disabled."

It's just crazy to not have root login via ssh disabled. Administrators should have to login under their actual user name first & then su (or sudo) to root. Then you've got more of a trail to follow when something unusual happens.

It is *occasionally* annoying if you ever need to scp some stuff to a directory that only root has access to, but that's easy enough to deal with when it comes up.

For the vast majority of administration, though, having root login disabled is not a hassle at all.

(Of course, it's even better to have a less monolithic scheme for administration permissions.)

Anonymous said...

Key authentication is not more secure as password authentication. In fact, if you get access to the client filesystem (http, samba, ...) and get access do the id_dsa (private) key, you get a whole bunch of servers compromised.
Key authentication is very usefull (scripts, frequent servers) but should be used with EXTREME caution.

Anonymous said...

Key authentication is not more secure as password authentication. In fact, if you get access to the client filesystem (http, samba, ...) and get access do the id_dsa (private) key, you get a whole bunch of servers compromised.
Key authentication is very usefull (scripts, frequent servers) but should be used with EXTREME caution.

Doug said...

Very true about the dangers of your private key(s) being compromised. However, if you use a passphrase when you create the keys, even if someone acquires your private key, they still can't use it directly. You are just back to the case where they need to do a brute-force attack to gain access to your other systems. More dangerous, I suppose, would be leaving an unsecured agent running with a cached passphrase.

Doug

Anonymous said...

what about a configurable delay, like 5 minutes after 5 bad password attempts?

wouldn't that slow things down enough to make brute force impractical?

Uzik said...

My firewall only allows ssh
from ip addresses where I personally
would be present to connect from.
Allowing ssh from the entire world
is an invitation to being hacked,
as you've seen. If you're forced
to have it open to large swaths
of ip addresses you're better off
installing a chroot jail or putting
up a virtual server.

Anonymous said...

To Doug: You're right about passwords on private keys, they do prevent abuse to some degree when they are stolen. However there are 3 factors that make it easier for them to be abused:

1) Allowing RSA key authentication by your users enables them to turn off the passwords of their keys without you knowing about it.

2) A keylogger can be installed on a compromised client machine off which the key is stolen.

3) A brute-force attack on a private key password is an offline attack, whereas an attack on a normal SSH password is an online attack. E.g. if someone wants to brute force your private key passphrase, they just need to run a program on their own computer (or worse, a network of bots) to try lots of keys quickly. They don't need to connect to your server every time they want to check a possible password. This makes it much quicker, and also you will never know it's happening because they can do it entirely offline. You also won't be able to block it after a few attempts, with software such as denyhosts. Therefore short passwords (6-8 characters) are not that tough to crack on an private key.

Because of this (most importantly my last point), I still believe that OPIE keys are more secure.

Doug said...

1) Allowing RSA key authentication by your users enables them to turn off the passwords of their keys without you knowing about it.

I agree this is a risk. More to my original point about single-factor auth is that users who choose weak passwords are also a risk, but a more severe one, as there is one step to compromise vs. two with keys. I'll grant that you can control this to some extent, as in using PAM to enforce password strengths, something you can't do with keys.

2) A keylogger can be installed on a compromised client machine off which the key is stolen.

This is a good point, but a keylogger would not only grab their passphrases, but their passwords as well, perhaps even their root password, and lots of other stuff.

3) A brute-force attack on a private key password is an offline attack, whereas an attack on a normal SSH password is an online attack.

Agreed, the brute-force attack is much easier offline - but the online attack can potentially succeed remotely in only one step, whereas there must be a local compromise *first* in order to even get to the situation where a private key can be compromised.

Bruce Schneier writes about how two-factor auth can fail through MITM attacks and Trojans (he talks about this in the context of banking transactions, though).

I guess I'm still just staying 'defense in depth' is always preferable to a shallow defense. Two-factor authentication is not perfect, just preferable to single-factor in this instance.

Because of this (most importantly my last point), I still believe that OPIE keys are more secure.

No argument there. It is still possible to botch the implementation of a OTP, but I don't know enough about OpenSSH and OPIE integration to comment.

Anonymous said...

Or run my script.

Anonymous said...

One comment to make about using authorized_keys files. You need to make sure OpenSSH doesn't think the file has been compromised. i.e. the file should have permissions x00 (I'd recommend 400). The directory must not be group or world writeable, the parent directory mustn't be group or world writeable, etc. all the way upto /.

I'd say about once a month some user comes to me trying to setup keys and tearing their hair out as to why it isn't working. I fix the file and dir permissions and all is fine.

Anonymous said...

One comment to make about using authorized_keys files. You need to make sure OpenSSH doesn't think the file has been compromised. i.e. the file should have permissions x00 (I'd recommend 400)

not really needed, ssh will be happy with 0600 as well. However, if you want more power over users' access, you can make it owned by root:usersgroup with access 0440. This way you (root) have some control over key revocation and you can also play various other login-time tricks (adding restrictions on forwarding, terminals, etc, logging which key was used if the user has several, creating single-purpose keys that allow only given commands and so on) The downside, of course, is having to micromanage your users - which can become something of a pain if their number is large enough.

Sharjeel said...

Let me add a couple of steps to make it even more secure
1) Install Port sentry which automatically blocks a "scanner" IP.
1) Change the sshd port from 22 to something obscure like 222.This will force the user to portscan a system to identify the sshd port which can then be tackled by port sentry.

Sharjeel
http://www.sharjeel.net

Anonymous said...

Or in Debain "apt-get install fail2ban"

Anonymous said...

I love this program:
http://denyhosts.sourceforge.net/

Anonymous said...

A simple one line addition "sleep(10)" to the SSH source code will throw off brute force password attacks: http://www.aerospacesoftware.com/ssh-kiddies.html

Darren Tucker said...

if UsePAM were set to 'yes', that this would override the 'PasswordAuthentication no' setting. I did some poking around, and it turns out this is true

Actually it's not true. What's happening is that UsePAM allows keyboard-interactive authentication. Although it may allow you to authenticate with a password (depending on your PAM configuration), from a protocol perspective this isn't the same as password authentication.

Last time I looked, the password-guessing worms out in the wild (or at least the ones that hit machines I'm responsible for) try only Protocol 2 Password authentication. That's not to say that future ones couldn't, and you can disable this by setting ChallengeResponseAuthentication no.

Doug said...

Thanks for clarifying that, Darren. Always nice to have an OpenSSH developer weigh in. I've updated the post with the new information.

Anonymous said...

i think the permission on authorized keys needs to be 755 and not 600

Doug said...

The authorized_keys file should be readable/writeable only by the owner (600). This is good practice, but is mandatory if 'StrictModes' is set to yes (although sshd will just check that the user's home directory and files are not world-writeable). Execute permissions are not necessary on a regular file.

Anonymous said...

This is all fine and good, but what if you want to see the attempts (names and such). I now have a script that bans people trying to break into my box (see http://kin.bounceme.net/recent_attempts.txt for banned people) and records the username they tried (as well as time and ip).

If you can link your syslog with ipf a system like this is not much work.

Anonymous said...

OPIE is not a final solution. OPIE uses md5 which is UNSECURE!! If you give your password with sequence number 200 to your friend, he can then guess password with sequence number 199

Anonymous said...

Another option is to use the 'AllowGroups' directive.

AllowGroups
This keyword can be followed by a list of group name patterns, separated by spaces. If specified, login is allowed only for users whose primary group or supplementary group list matches one of the patterns. '*' and '?' can be used as wildcards in the patterns. Only group names are valid; a numerical group ID is not recognized. By default, login is allowed for all groups.

Turn root login off, then only allow members of the 'user' group (or whatever your 'human' group is) to ssh in. Defining it by group has the advantage that you don't need to update it each time you add users to the system (unlike AllowUsers), and you don't have to maintain a listing of hacker's machines to deny access to (nor do your users need to know how to use SSH keys, or connect only from specific machines). Anyone needing root access should be able to log into a normal account and su from there (which means there's 2 levels of passwords that need to be cracked), and accounts like 'ftp', 'mysql', etc are disabled by the restriction to what groups are permitted to log in.

Further root access can be restricted by limiting who can su to root (e.g. admin group only), making it that much more difficult to break into the root account.

Anonymous said...

There are a lot of good suggestions here but my favorite is from the no hassle/no brainer bin:

The 2 edits to iptables that limit the number of attempts that can occur within x time works great.

Thank you Anonymous! =)

Anonymous said...

Helped me out alot. Thanks.

vps said...

Hi there,

I have tried to follow your advice but..... stdin: is not a tty

this is chinese for me.



root@vps [~]# cat ~/.ssh/id_dsa.pub | ssh root@vps "cat >> .ssh/authorized_keys"
The authenticity of host 'vps (777.77.777.77)' can't be established.
RSA key fingerprint is 53:d4:5b:f1:48:57:9b:22:49:93:5c:fc:4d:cd:6b:65.
Are you sure you want to continue connecting (yes/no)? y
Please type 'yes' or 'no': yes
Warning: Permanently added 'vps,777.77.777.77' (RSA) to the list of known hosts.
root@vps's password: -which I entered here and -
stdin: is not a tty



now the question is:

_Can I move forward with this or should I undo what the generation of the keys?

I am very concerned because I have recently been warned with BFD that some fu.....ing guy from Kansas is trying to brute force my VPS

Doug said...

"stdin: is not a tty"

Try adding '-tt' to the ssh command line. This will force a tty to be allocated.

That being said, the command I gave was just a shortcut. You can cut-n-paste the public key manually to end of the remote authorized_keys file if needed.

Doug

VPS said...

the iptables edit trick seems to be very convenient as it involves no install of any script and is very easy to do

I did issue the first line of command but received the following error:


root@vps [~]# iptables -A INPUT -p tcp --dport 22 -m recent --set --name ssh --rsource
iptables v1.2.8: Couldn't load match `recent':/lib/iptables/libipt_recent.so: cannot open shared object file: No such file or directory

Try `iptables -h' or 'iptables --help' for more information.
root@vps [~]#



I would very much appreciate any help

VPS said...

any answer ?

Doug said...

You don't need to redo your keys.

If you are connecting from root@vps -> root@vps itself then you don't need to type "cat ~/.ssh/id_dsa.pub | ssh root@vps "cat >> .ssh/authorized_keys"". Just edit the authorized_keys file on vps and copy/paste the originating host's public key to the end.

The command I gave was a shortcut to transfer a public key from a remote host, not the same one.

VPS said...

am sorry Doug, but this sounds rather like Chinese for me..

can you be a bit clearer please?

Doug said...

Sure, you don't need to use the command I posted. Take the public key (id_dsa.pub) from the box you are connecting from, and append it to the authorized_keys file on the box you are connecting to (VPS, I'm assuming? So that would be /root/.ssh/authorized_keys). Just open the authorzed_keys file in a text editor and paste the contents of the public key file at the end of it (you don't want to overwrite previous keys in that file, but if this is the only key, it doesn't matter).

Anonymous said...

i have also found this article today on the web that is interesting:

http://www.xthought.org/blog/2006/secure-ssh

wils said...

In our office, on a testing machine i was using ssh. However, while installing a 'icewm'(desktop), it is asked for a msg 'disable ssh', by mistake i did 'Yes'(thinking temporary). But now its disabled.

when me and others try to login using ssh from client side, its just prompting Login, when we enter the user name and enter for password option, this window get disappered.

please advise how do i solve this issue. help needed.

thanks
wilson

Doug said...

I'm not sure I understand what your issue is - where was SSH disabled, on the client, or server? Do you mean the desktop installed a firewall that blocks inbound SSH?

Anonymous said...

Good article and discussion. Just out of interest does anybody know how to allow allow;

userA to login from HostA only
userB to login from HostB only
userC to login from anywhere

Something that has got me a little stumped and I need.

Suggestions would be helpful.

Thanks
Ben

Doug said...

Yes, you can use the from="" in your authorized_keys file to restrict where clients can log in from. Read sshd (8) and look for "AUTHORIZED_KEYS FILE FORMAT".

Anonymous said...

Just installed DenyHosts on Fedora 6. It installed perfectly through yum, and after a few minutes tweaking the configuration options I feel much better about the security of my system. Definitely recommend this program!

Anonymous said...

I've taken to never opening SSH on the firewall. Users that need remote access bring me their laptop and I install OpenVPN. To initiate a brute force attack on SSH an attacker would first have to compromise OpenVPN.