Domain: sublimation.org
Stories and comments across the archive that link to sublimation.org.
Comments · 10
-
Re:encryption alone
Thank you. I have seen scponly though. What I dislike about it is summarized by this quote from its installation page:
installing scponly with chroot could incur some pretty hairy troubleshooting. The binaries and libraries must be set up properly in the chroot subdirectories properly.
-- from here
It seems to me (though I wouldn't mind if I were wrong) that this is essentially just a way to do #2 in my list (prev. post) for versions of sshd that do not support restricting the commands that users can execute, or built-in chrooting. So, haven't new versions of sshd made scponly unnecessary?
FYI, #1 in my list was referring to this approach (found URL since last post). This does not actually use a chroot; it just makes sshd-server behave as though it were in one by modifying the way it handles file paths. I don't know how it plays with symlinks.
-
Re:encryption alone
Have a look at http://sublimation.org/scponly/wiki/index.php/Main_Page for providing sftp sessions in a restricted shell.
-
scponly
This functionality was already available through an add-in called "scponly" http://sublimation.org/scponly/wiki/index.php/Main_Page. Sounds like it'll be easier to deal with when it's directly implemented in OpenSSH, though.
-
Re:Oh thank god
Well, I'm not sure about logging, but you could always use scponly. I've got a friend who uses it on several servers and has been quite happy with it.
-
Here's what you need:Here's what you need, scponly. No need to recompile openssh or anything, just compile scponly, copy a few libs to your user's dir, change the user's shell to scponly and you're done. It even works with Solaris 9's version of openssh. I've used it a bit and I'm happy with it.
As to the discussion - nerds generally have low self-esteem and poor social skills. It's makes them friggin' fabulous to communicate with.
:/ Good luck. I suspect you've already solved the problem above anyway. -
For the love of Freshmeat...
I've wondered about this myself, but ages ago. Since then I've found that in my particular situation it's not needed (VPN/SSH/WEBDAV). But a quick check on Freshmeat shows at least 2 possibilities: scponly, rssh.
I get that using a wrapper program like either of these is kind of cockeyed, but SFTP *is* the most commonly supported secure transfer protocol (webdav/ssh, but not nearly as drop-in for Dreamweaver users, etc).
Anyway, I think it's safe to say the *nix community is now big enough that most itches have at least been attempted to scratch. And FTR, there are assholes in every community, sounds like you just had a spot of bad luck. -
Re:AgentForwarding AS AN OPTIONAL FEATURE
Actually...
Rather than assume anyone^H^H^H^H^H^Heveryone on slashdot has any brains when it comes to Securing SSH let me give you some tips I/Other people have
Restricted ssh shell for scp/sftp http://sublimation.org/scponly/
Patch to lock out IPs brute forcing passwords http://ethernet.org/~brian/src/timelox/
Can add restrictions to authorized_keys file
from="hostipaddress",command="/usr/local/sbin/ssh_ command_allow_rsync",no-port-forwarding,no-X11-for warding,no-agent-forwarding,no-pty ssh-rsa AA...= backup_key
Securing sshd in /etc/ssh/sshd_config
Protocol 2
PermitRootLogin without-password
PasswordAuthentication no
ChallengeResponseAuthentication no
ClientAliveInterval 60
ClientAliveCountMax 30
The first line says to stop using the old, lower security ssh protocol-1.
The second line is a hedge that says never allow root logins using the unix password -- always use some other authentication.
The third line says don't allow skey authentication. It is a good idea to turn this off if you aren't using skey at this time. (Skey implements a series of non-reusable, one-time passwords. If you were using it you would know.)
The fourth and fifth lines simply make sure that any connection to a client that doesn't respond at least once each half hour gets closed. After editing the sshd file, restart sshd or reboot for the changes to take effect.
31-12-2004: new rate-limiting feature in -current. This would block hosts that exceed 10 connections per 60 seconds.
pass in on $ext_if proto tcp to $ext_if port ssh flags S/SA \
keep state (max-src-conn-rate 10/60, overload )
block in on $ext_if proto tcp from to $ext_if port ssh
Also my previous post to do with limiting user connections to SSH during the scarey SSH port scanning days of not so long ago...
http://it.slashdot.org/comments.pl?sid=156058&cid= 13084357
Repeated here for your convenience:
Ways around SSH Brute forcing (Score:1)
by meridian (16189) on 11:06 AM July 17th, 2005 (#13084357)
(http://www.thief.net/)
There are esentially three ways to fix this problem.
The first is to patch sshd which is probably the least preferable way as you would need to continually keep patching with each upgrade. But this seems effective allowing you to exec a system command such as iptables.
http://ethernet.org/~brian/src/timelox/ [ethernet.org]
The second is to use iptables to limit connection attempts from an IP address. One problem with this is people who use scp alot may quickly rack up that connection limit.
Here is a recent example from the iptables mailing list
iptables -A INPUT -p tcp --dport 22 -s ! $My_Home_Firewall_IP -m state --state NEW -m recent --name SSH --set --rsource -j SSH_BF
iptables -A SSH_BF -m recent ! --rcheck --seconds 60 --hitcount 3 --name SSH --rsource -j RETURN
iptables -A SSH_BF -j LOG --log-prefix "SSH Brute Force Attempt: "
iptables -A SSH_BF -p tcp -j DROP
The best in my opinion is a pam module found at http://www.kernel.org/pub/linux/libs/pam/modules.h tml [kernel.org] called pam_abl
This does not have the problem of the IPTables method that may mistake multiple fast scps etc as an attack attempt, and will not require coninutal repatching of the kernel such as the timelox patches. -
Re:Any news on chroot support?
An application I've used which does what you want is called scponly.
Features include chrooting to home directory, and full sftp, unison, and optional rsync compatibility.
-
Re:what's the point?
I'm not sure what your issue is but wildcards work fine on my sftp servers.
There are some shells that have worked on supporting tab completion (zsh, etc.) but that is a spotty solution at best. There are several GUI clients that support sftp and the completion issue is non-existant that way. This still only solves a small part of the issue. There was also a patch to put that functionality into OpenSSH but not much seems to have come of that (yet).
You can use the yafc ftp client since it uses sftp and has tab completion. The commands aren't exactly like ftp but it is very similar. I prefer using scp/sftp for transfering files in conjunction with the scponly shell. -
Re:My one bugbear
You might want to check out scponly.
Be aware of the colour scheme on that site though, it's hard on the eyes.