Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am in a situation where I cannot have passwordless login for ssh and ssh server could not be run over any other port other than the default port. So, I have chosen to use stunnel to tunnel ssh. On my personal pc I use stunnel on client mode and use it to login to server like so: ssh -p 8888 user@localhost. The problem is that ssl client certificate is public, so anyone can easily setup a ssl tunnel to my server. If any one queries for https://myserver.com it shows that openssh 2.0 is running on ssl port. So it has become an easiest way to break in, much simpler than running ssl server on a non-default port. So, I would like to know if it is possible to make ssl client certificate private, so that it won't be offered to anyone who does a https query on my server. And I should be able to maintain it as secret as ssl private key.

share|improve this question
    
A public certificate is not sensitive, and an SSL port that's not requiring client certificate authentication is, well.. public. Can you clarify why you're looking to tunnel an authenticated, encrypted protocol within a second authenticated, encrypted protocol? –  Shane Madden Mar 6 '12 at 6:09
    
I cannot have passwordless or key based ssh authentication. So I'm looking for a tunneling tool which is keybased and passwordless. –  nixnotwin Mar 6 '12 at 6:39
    
nixnotwin, that's what you want, not why you want it. Like Shane, I'm concerned that you've fundamentally misunderstood the nature of keypairs, specifically that one half is designed to be public and that this doesn't weaken the security. Again: could you clarify why you're trying to tunnel one secure protocol inside another, to the same endpoint? –  MadHatter Mar 6 '12 at 6:56
    
I have hundreds of ssh users with weak passwords. The LAN facing interface does not have firewall. Users login via port 22. But I cannot keep port 22 open on WAN side, because of weak passwords. Openssh-server can completely turn off password based authentication, but I cannot make all users have ssh certificates. If I want to administer the server when I'm away from office, I need to login from WAN side. So I'm looking for a way to tunnel ssh over a protocol which supports secret keybased authentication. –  nixnotwin Mar 6 '12 at 7:13
add comment

2 Answers

up vote 5 down vote accepted

So to clarify: You want passwords to be allowed from the office network, but not from anywhere else. You, however, need to be able to connect from anywhere.

On my network SSH keys are required when logging in from outside but either keys or passwords can be used when connecting from another host on the inside.

Here's how that works:

/etc/ssh/sshd_config

RSAAuthentication yes
PasswordAuthentication no

Match Address 192.168.0.*
    PasswordAuthentication yes

If you substitute your office subnet for 192.168.0.*, users will be able to use passwords to connect, but only from the office subnet. You, however, will be able to use your SSH keypair to connect from anywhere.

When an ssh client connects to the server, it is presented with a list of authentication mechanisms it can try. Typically the list is "publickey, password." In this case, when someone connects from outside, they are only presented with "publickey" so their client will not even attempt to send a password. If they attempt to authenticate with any mechanism other than an SSH public key, the connection is immediately shut down by the server. So no possibility exists for brute-forcing the passwords.

share|improve this answer
    
Assuming we've both understood your question correctly, I prefer Insyte's answer to mine as it's more elegant and requires less upkeep. +1! –  MadHatter Mar 6 '12 at 8:33
    
Your answer is exactly what I was looking for. Just two more things I wanted to clarify: 1) If I want openssh server to be on default port (22) on LAN and on a non-default port on WAN, would it be reasonable to go for iptables port redirection? Would this make it feasible to block port 22 on WAN side with iptables? 2) Can I make openssh server password authentication available on multiple LAN subnets, for e.g. 10.0.1.0/24 and 10.0.0.0/24? –  nixnotwin Mar 6 '12 at 13:59
    
1) I think iptables would be your only option. Note, though, that a brute-force attack is impossible if password auth is disabled, so there is little value to moving to a non-default port. 2) Yes, I included a single subnet for clarity but you can specify multiple comma-separated networks, like so: Match Address "192.168.0.*,10.0.0.*" –  Insyte Mar 6 '12 at 15:52
    
My openssh-server version is 5.2. I changed sshd_conf file with your settings. When I restarted the ssh server I got this error: init: ssh respawning too fast, stopped. I googled for the issue. One hack that I found was to make the server listen on 0.0.0.0. But that too failed with the same error. –  nixnotwin Mar 7 '12 at 10:59
    
Probably a syntax error in the config file. You can try shutting down the ssh server, then running "sshd -d" manually, which will run the ssh daemon in the foreground in debug mode. Hopefully that will give you a clue what's wrong. Also feel free to pastebin your config file somewhere. If nothing else, paste the "Match" block in a comment or, ideally, a pastebin. –  Insyte Mar 7 '12 at 22:07
show 3 more comments

Nixnotwin, that's a genuine problem all right, but I'm completely confused about how you think what you're asking for will help you. Let me restate the problem so we can see if I've understood it correctly.

You have an ssh server with lots of weak user passwords. You want to be able to log in remotely from offsite, but don't want to allow your foolish users to do so, for that would expose all those weak user passwords to the brute-force password guessing that goes on all the time against unprotected sshds. If you run sshd at all, it has to run on port 22.

How am I doing so far?

You clearly have two NICs, and therefore two addresses, on this server, because you're referring to "the LAN-facing interface" and "the WAN side". How about setting up two sshds, both running on port 22. One of them binds only to the internal NIC address (ListenAddress 10.3.4.5) and is otherwise unrestricted, for the use of all those local users who can't pick good passwords. The second sshd uses a different configuration file which binds only to port 22 on the external interface (ListenAddress 2.3.4.5), and which either disallows password-based authentication (PasswordAuthentication no), or only allows users who are members of a certain group to log in (AllowGroups nixnotwin)?

Would either of those solve your problem?

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.