Hello Richard, I've had this kind of trouble before, taking over the maintenance of a web server with openssh installed in its default configuration. The problem here is that password logins are permitted by the SSH configuration, and the ssh server is configured to listen on the default port 22. What you need to do is a combination of things. 1. Use a different port than port 22. Change the setting for Port in /etc/ssh/sshd_config on the *remote* side to a high-numbered port, numbered above 1024 (the default privileged ports range is from 1-1023), and restart the OpenSSH server. For example, to set SSH to listen on port 3418: # ------------ snip ------------- # Port 22 Port 3418 # ------------ snip ------------- This prevents automated brute force attacks using a dictionary from easily finding the server listen port. 2. Enable public key authentication. This takes three steps: a. Add these lines to your /etc/ssh/sshd_config: # ------------ snip ------------- RSAAuthentication yes PubkeyAuthentication yes # ------------ snip ------------- b. Generate a public key pair, by executing these commands from your command line. If you are logged in as your regular, unprivileged user, say, rchapman, and you want to generate an 8192 bit RSA key (8192 bits is a bit overkill, some might say; typically people would use values between 1024-4096): # ------------ snip ------------- rchapman@~] mkdir -p ~/.ssh rchapman@~] chmod 700 ~/.ssh rchapman@~] rsa-keygen -t rsa -b 8192 (you'll be asked to save two files, one with a .pub extension) # ------------ snip ------------- You need to transfer the public key half (rsa_key.pub) to the target server somehow, say on a USB stick, or over the wire. You keep the private half (rsa_key) on the machine from which you connect to remote_side. Concatenate the public key half (in this example, called rsa_key.pub) to the file ~/.ssh/authorized_keys on the target server: rchapman_remote@remote_side] # cat rsa_key.pub >> ~/.ssh/authorized_keys c. To connect to the server named "remote_side" using the private key half you've kept on your local machine, you need to create the file ~/.ssh/config, adding these lines: # ------------ snip ------------- # Local OpenSSH config file in /home/rchapman/.ssh/config Host remote_side Port = 3418 IdentityFile = ~/.ssh/rsa_key Protocol = 2 User = rchapman_remote # Note that rchapman_remote is the username on the remote side # # ------------ snip ------------- c. Do an ssh login to the remote side, as your local user: rchapman@~] # ssh -v remote_side The "-v" enables verbose logging to your console, of the status of protocol negotiation. Hope this helps. avahilario@xxxxxxxxx On Friday 02 May 2008, Richard Chapman wrote: > Hi > I don't now much about ssh - but I use it to connect to my centos server > with nx. Normally - I only do this on our local network and have port 22 > disabled in the internet firewall. > Recently - I was away from the office - and enabled port 22 on the > firewall - so I could access the centos server remotely. I thought ssh > had pretty good security - and nx uses a key to allow access. > > However - after only a day with port 22 enabled - I had some sort of > attack reported by the firewall - and I had the following in my logwatch... > > --------------------- pam_unix Begin ------------------------ > > smtp: > Unknown Entries: > authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= : > 155 Time(s) check pass; user unknown: 155 Time(s) > authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= > user=richard: 1 Time(s) bad username [!]: 1 Time(s) > bad username [*]: 1 Time(s) > > sshd: > Authentication Failures: > unknown (60.12.1.158): 1581 Time(s) > root (60.12.1.158): 82 Time(s) > sshd (60.12.1.158): 4 Time(s) > mysql (60.12.1.158): 3 Time(s) > richard (60.12.1.158): 3 Time(s) > gopher (60.12.1.158): 2 Time(s) > halt (60.12.1.158): 2 Time(s) > mail (60.12.1.158): 2 Time(s) > mailnull (60.12.1.158): 2 Time(s) > max (60.12.1.158): 2 Time(s) > nfsnobody (60.12.1.158): 2 Time(s) > nobody (60.12.1.158): 2 Time(s) > postgres (60.12.1.158): 2 Time(s) > squid (60.12.1.158): 2 Time(s) > adm (60.12.1.158): 1 Time(s) > ais (60.12.1.158): 1 Time(s) > apache (60.12.1.158): 1 Time(s) > bin (60.12.1.158): 1 Time(s) > daemon (60.12.1.158): 1 Time(s) > ftp (60.12.1.158): 1 Time(s) > games (60.12.1.158): 1 Time(s) > gdm (60.12.1.158): 1 Time(s) > haldaemon (60.12.1.158): 1 Time(s) > lp (60.12.1.158): 1 Time(s) > named (60.12.1.158): 1 Time(s) > news (60.12.1.158): 1 Time(s) > nscd (60.12.1.158): 1 Time(s) > ntp (60.12.1.158): 1 Time(s) > nut (60.12.1.158): 1 Time(s) > operator (60.12.1.158): 1 Time(s) > pcap (60.12.1.158): 1 Time(s) > piranha (60.12.1.158): 1 Time(s) > postfix (60.12.1.158): 1 Time(s) > rpc (60.12.1.158): 1 Time(s) > rpcuser (60.12.1.158): 1 Time(s) > rpm (60.12.1.158): 1 Time(s) > shutdown (60.12.1.158): 1 Time(s) > smmsp (60.12.1.158): 1 Time(s) > sync (60.12.1.158): 1 Time(s) > tim (60.12.1.158): 1 Time(s) > uucp (60.12.1.158): 1 Time(s) > webalizer (60.12.1.158): 1 Time(s) > Invalid Users: > Unknown Account: 1581 Time(s) > > > Can anyone tell me what is going on here. It looks like someone is > trying to find usernames by just testing a list. They appear to have > found 3 of our usernames - but hopefully not the passwords. > > > How much of a security issue is this? If they did guess a password - > would they have full shell access? If so - how is this any better than > (say) telnet? > > Are there any settings I can and should do to restrict access further? I > have blocked port 22 in the firewall for the time being. Can I set up a > shared private key or similar? > > Many thanks > > Richard
