Submitted by “This guide describes how to generate and use a private/public key pair to log in to a remote system with SSH using PuTTY. PuTTY is an SSH client that is available for Windows and Linux. Using key-based SSH logins, you can disable the normal username/password login procedure which means that only people with a valid private/public key pair can log in. That way, there is no way for brute-force attacks to be successful, so your system is more secure.”
What kind of psycho is going to use key-based logins from a Windows machine?
You gotta be out of your mind, son.
Edited 2006-12-10 18:45
why not? If you are a paranoid security freak, then go for it.
‘course, if you are a paranoid security freak, you wouldn’t be running windows…
Windows wouldn’t be the only OS you wouldn’t run..
You don’t seem to understand what this article discusses.
If you follow the procedures listed here, anyone with access to your session on a Windows box could login to your servers without a password.
Getting access to someones session on a Windows machine isn’t exactly hard or uncommonly done by hackers.
You do know that the private key can be encrypted right?
Some people probably opt to not encrypt it because they would figure if it was encrypted and they have to enter the password everytime, what’s the point of doing this as opposed to standard login (of course failing to see that it still takes brute force attempts out of the picture)
“If you follow the procedures listed here, anyone with access to your session on a Windows box could login to your servers without a password.”
Hey, just like they could on a *nix box if you run ssh-agent and don’t lock your X session. Or leave your terminal session logged in with ssh-agent running.
“Getting access to someones session on a Windows machine isn’t exactly hard or uncommonly done by hackers.”
You have a lot of hackers roaming freely around in your home?
What kind of psycho is going to use key-based logins from a Windows machine?
I would.
On my only server that has SSH available to the outside network, I have the firewall settings permanently banning any IP with 2 consecutive invalid SSH login attempts. I’m sure there is some way to still brute-force using public/private keys, it would just take an amount of time greater than anyone has (unless they get a truly massive distributed network) – firewall rules are only way to really prevent brute force, and its possible to brute force if they manage to again get a massive distributed network of systems on different IPs, but at that point you start to wonder if its really worth it.
I have the firewall settings permanently banning any IP with 2 consecutive invalid SSH login attempts.
Got a link to a howto or guide for that?
I threw together a quick and dirty on how to do this (though it blocks once a single invalid attempt comes in) – the server I did the 2 consecutive attempts on is at work, but its similar to this with a couple of changes in the regex (plus different variable names
)
http://home.earthlink.net/~valiantsoul/pf.html
NOTE: This will only work on a system with the PF firewall (BSDs only?)
This is the one I use on Linux
http://denyhosts.sourceforge.net/
I locked myself out once when setting it up (always read the manual
but after that I’m golden.
Is there any Java app that can do the same on a non windows smartphone? I have an old nokia 9300 and would love to be able to access to my servers. midPSSH doesn’t seem to support keys.
Browser: Opera/8.01 (J2ME/MIDP; Opera Mini/3.0.6306/1528; en; U; ssr)
good article!
not bad article for newbies…
but the step described under “Attach The Private Key To The PuTTY Profile” is unnecessary, because PuTTY can communicate with Pageant to get the private key from the agent to authenticate
Edited 2006-12-10 21:22
I’ve been doing this for years now, and it works great. I have a Mac running 10.4.8, Sun Ultra 5 running Solaris 10, a Fedora 6 PC, and a Windows Vista laptop. With SSH/SCP on the others, and PuTTY/WinSCP3 on the Windows machine I can access a terminal and move files from any one to any other.
One gripe I have, is who would go through ALL this trouble in the name of security, and then allow remote root logins? Imagine the disaster that could happen if you walked away from a computer with pageant up, and the ability to log straight in remote as root. All one vengeful ahole has to do is double click putty, connect, cd /, rm -rf *, and you’re out of business.
I don’t know if he was using root because he was lazy, because it was just an example, or that’s what he does in real life, but to teach people the wrong way is not good.
Even if you did something so horribly stupid as leave pageant up and walk away from your computer, at least if you login as a regular user the damage should be limited…
Set this up for a user account, and while disabling password authentication, do yourself a favor, and also disable root logins with ‘PermitRootLogin no’ in your sshd_config.
Edited 2006-12-10 22:00
“All one vengeful ahole has to do is double click putty, connect, cd /, rm -rf *, and you’re out of business.”
Unless, of course you’re a responsible admin who makes daily backups that you can roll back to.
But then again, someone that organized would probably know how to do everything from a limited privilege account.
I use this system to get my Windows boxes to execute some scripts locally (mostly dumping DHCP information), then I scp them across to my GNU/Linux boxes securely. You lock the remote side down to a very secure account (ie, restricting what commands can be run), voila – secure way to send data from a to b without needing a password, good for scripting say at 12:00 am in the morning. I could use FTP etc, but what’s the point – scp is much better for this situation. I don’t fancy leaving unencrypted passwords in my script.bat files.
SSH Bruteforce attacks really picked up in recent history. Enter Fail2Ban:
http://fail2ban.sourceforge.net
Quite simple to set-up. It can monitor the logs of any daemon — not just SSH — and ban an IP after X failed atttempts, either by using hosts.deny or iptables.
Also, these SSH attacks aren’t very sophisticated — Changing the port number SSHd listens on is a great way to minimize the noise. There’s also the added bonus of seeing attacks on a nonstandard port and realizing they are much more personal than some of these stupid bots. Nice to know when folks are taking special interest in your server, on port 22 that kind of gets drowned out.
As someone said: “good for newbies”
but what is the big deal? is something has been there for ages (for people who cared to use it), so what is the big news?
some of you linux noobs might find this useful
deny root login to ssh
http://www.linux-noob.com/forums/index.php?showtopic=1013
how to vnc to another pc via ssh
http://www.linux-noob.com/forums/index.php?showtopic=615
ssh rate limiter (ip based)
http://www.linux-noob.com/forums/index.php?showtopic=1829
change default ssh port from 22 to another port
http://www.linux-noob.com/forums/index.php?showtopic=646
stop ssh sessions timing out
http://www.linux-noob.com/forums/index.php?showtopic=645
cheers
anyweb
Well, I use SSH everyday for lots of stuffs so I learned nothing, but it is interesting for new users.
However… I am a bit disappointed that the author used the “root” account as an example. The article is about security in a way, and EVERYONE will tell you that the first thing you must do with SSH is to disable the possibility to login as root through SSH.
“However… I am a bit disappointed that the author used the “root” account as an example. The article is about security in a way, and EVERYONE will tell you that the first thing you must do with SSH is to disable the possibility to login as root through SSH.”
You’re right. Just for the fact, “root” connections are disabled for FTP by default. It should be done with SSH in an analog way. Especially new users should know they should not use “root” for logins; if the SSH session is active for a !root user, the connection is encrypted after login and su can be used.
On pages 2 and 4, the editor vi is mentioned. Not good for newbies. they might get frustrated! 🙂
Finally, I like the article because the combination of SSH and authentification is illustrated in an easy way.