Hi, while discussing with friends how to 'hide' an ssh-entry to a system (using uncommon ports, "knocking" on a sequence of ports with telnet, etc) we saw the problem you need all that ports open on the client side as well. But maybe on the client side you are just a guest and those ports are locked for a good reason. So we had another idea: using a sequence of login-names directly to the ssh-server. If someone gives the right sequence of accounts, the IP will be accepted for "real" logins for a while. If the sequence is wrong, the IP can be logged in syslog and locked out totally from the system by another tool with a firewall. This could be a nice feature for people that need to have access to their system from varying clients all over the internet. Additionally when a hacker tries to hack the ssh he could be locked out from other services as well. Is it possible to put such a feature in sshd? Could it be a patch or external addon? What do you think? Bye! Emil 'nobs' Obermayr Braunschweig, Germany -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050807/50952442/attachment.bin
Emil 'nobs' Obermayr wrote: [...]> So we had another idea: using a sequence of login-names directly to the > ssh-server. If someone gives the right sequence of accounts, the IP will be > accepted for "real" logins for a while. If the sequence is wrong, the IP can > be logged in syslog and locked out totally from the system by another tool > with a firewall. > > This could be a nice feature for people that need to have access to their > system from varying clients all over the internet. Additionally when a hacker > tries to hack the ssh he could be locked out from other services as well. > > Is it possible to put such a feature in sshd? Could it be a patch or > external addon?I doubt it. It's of very limited use and it's a DoS waiting to happen. If you're using an external authentication system such as PAM or BSDAuth then you can implement whatever policy you want at that level.> What do you think?It would be trivial to implement this with some kind of external log-watching process: create a group such as "sshallowed", then put "AllowGroups sshallowed" into sshd_config. The exeternal process could then add/remote the appropriate user(s) to and from that group based on the activity in the log. Just because it's possible doesn't make it a good idea, though. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
Why would you place this functionality at the application layer, why not use port knocking at the firewall layer? It's a lot simpler to implement (even if you have to set it up manually via the services and inetd.conf files), than to change the code for sshd. A couple of lines in an inetd.conf and services file can make an easy to use port knocking to open an SSHD daemon on a port the knocker specifies. Then after 30 seconds, the listener closes. If there's interest, I can submit an example.