Re: /tmp rather than /home, attacks?
On 13 Mar 2007 00:41:45 +0100, Thomas Hafner wrote: Hello, having an option like ControlPath ~/.ssh/control/[EMAIL PROTECTED]:%p is probably not a good idea, if the user's home directory is shared by different machines (name collision for similiar outgoing SSH connections). Something like that ControlPath /tmp/[EMAIL PROTECTED]:%p should be better, because the directory /tmp is always local to the machine. But will that enable symlink attacks? (e.g. somehow is guessing the name before and creates an appropriate symlink to a file to be corrupted.) Or is there another, better solution? I'm using that version (ssh -v): OpenSSH_4.3p2 Debian-5ubuntu1, OpenSSL 0.9.8b 04 May 2006 Regards Thomas I've got the impression that you can't create a unix domain socket on an NFS mounted file system - so if users' home directories are under NFS, I have an impression that the control socket would not be created at all. I could be quite mistaken though. Also, as I understand it, anyone on the client machine who can have access to the unix socket at ControlPath, can become the user on the server machine - so attacks that do something tricky with permissions could also become a possibility. You can always put %l into the ControlPath, so it would identify both the local and remote machines. Then only if you have two machines that think they have the same hostname should there be a problem. Regards Mark
Re: TCP_NODELAY
It can also be set per socket with setsockopt(2). How to do something similar in an ssh subsystem, I'm afraid I don't know Regards Mark On 1/15/07, olaf weiser wrote: Hallo to all, so far I know, this is a system wide parameter You could set this per interface or for all connections in AIX , this is an option set by the no command you can verify by no -a or no -L and set by no -o at least , that's what we do... cheers olaf Chris Nystrom wrote: Hello, I have an interactive application including mouse events that I want to be secure. I have configured the system to use an openssh subsystem and it works well except that we have noticed some inconsistent performance. We have fixed this on a plain socket connection by setting TCP_NODELAY. I have looked at the man pages and the e-mail archives and as far as I can tell there is no way to set this for an ssh subsystem. Am I correct? Thank you, Chris
Re: How to restrict remote forwarding ports in SSH2?
You're quite right. Netcat is included in most unices (to get full bidirectional port forwarding, you would actually need two shell commands a pipeline). Socat is quite a bit more versatile, and would do the forward in a single command. I think it's available by default in some unices, and should compile on nearly anything you're likely to encounter. Netcat is of course also available as a Windows binary, although doing a bidirectional port forward is a bit trickier (does anyone know how to do the equivalent of mkfifo in Windows?). Cheers Mark On 11/24/06, Derek Martin wrote: If I understand what you're asking, it's probably worth pointing out that it's already possible to do this kind of port redirection in general with TCP/IP without dealing with SSH's port redirection... there's not much you can do to prevent it. Anyone capable of writing socket code in C can write a program to redirect any port to anywhere in maybe a couple of dozen lines. ... Someone's probably already written a free program to do this kind of port redirection, which can be downloaded freely. It might even have pre-comiled binaries for your platform(s).
Re: Scp sftp with no shell access or restricted access
I have a feeling that might not be very robust if you're allowing sftp or scp to anywhere a user normally has access to - a user could then download their own authorized_keys file, edit it to give themselves shell access, and then upload it. Another option might be to use the Match option in OpenSSH 4.4. I haven't had a chance to play around with 4.4 yet, so please experiment with this. But, something like Match User restricted-user ForceCommand /usr/libexec/sftp-server The advantage here is, you do this once to /etc/sshd_config - the file you're editing is not under a user's control, unlike their authorized_keys file. You'd probably need to add other options in there, disabling port forwarding and such... I have one concern with the above - the forced command is executed with the user's shell, with the -c option. If I'm not mistaken, this will prevent bash from reading any scripts that could be under the user's control. But you'd have to carefully examine the man page for every shell in /etc/shells, and ferret out ways a user might run commands. Maybe either remove shells from /etc/shells, or prevent users from changing their shells altogether. For example, on my OS X system, tcsh still runs the user's ~/.tcshrc, even when run with a -c option. Although I wasn't able to try it with ssh ForceCommand. Perhaps someone else on the list has more complete knowledge of this? Regards Mark On 11/14/06, Greg Bell [EMAIL PROTECTED] wrote: ssh lets you restrict the command a user is allowed to run in the authorized_keys file. mostly unknown feature but very handy. i have found this useful for allowing users to do just one or two things (eg. rsync a particular dir). see http://www.hackinglinuxexposed.com/articles/20030109.html ~gb
Re: Need some education: Man-in-the-Middle Attacks
On 8/29/06, Christ, Bryan wrote: All, Please pardon my naivete. I was looking at the diagram on the URL listed below and contemplating how host fingerprinting prevents MITM attacks. http://www.vandyke.com/solutions/ssh_overview/ssh_overview_threats.html So my question is this... Given the illustration in the URL above, what prevents Eve from *first* contacting Alice to obtain a fingerprint which then gets passed to Bob on the first connection attempt? The server passes the client its public key; the client generates a fingerprint of this public key, and verifies that it matches a known one from previous connections. Eve can pass Alice's public key to Bob, but she doesn't possess Alice's private key, so she has no way to interfere further with the communications (beyond tampering at a network level - introducing delay, dropping the connection, etc.) Only if Eve gets in the way of the very first connection attempt, can she pass her own public key off as Alice's, without Bob detecting it. On the first connection, he'd have to either trust what he sees, or verify the fingerprint offline somehow. On subsequent connections, the mismatch would be obvious.
Re: X11 tuneling: a hard to fix problem
No, don't use xhost + The entire point of using ssh for X11 forwarding is that the ssh connection comes from a local process - you don't have to accept outside X11 connections. xhost + is used specifically for accepting X11 connections that _don't_ come from a local process (e.g not over your SSH session). If for some reason the X11 connections are failing to be forwarded over the SSH tunnel, xhost + will fix X11 functionally, but it will do it by bypassing the entire SSH tunnel. Mark On 4/18/06, Jason Mitchell [EMAIL PROTECTED] wrote: Hi Nader, on the host you're ssh'ing from try issuing xhost + prior to ssh'ing, eg: yourdesktop # xhost + yourdesktop # ssh -X [EMAIL PROTECTED] Regards, Jason Nader Amadeu wrote: Hi all, I've googled for more than a week trying to fix this SSH X11 tuneling problem. I appreciate some help and thank you in advance. I have a remote Solaris 9 with the following options in /etc/ssh/sshd_config: X11Forwarding yes X11DisplayOffset 10 ForwardX11Trusted yes Then I ssh it from my local desktop: (only most important lines here) [localdesktop]% ssh -vvv -XY [EMAIL PROTECTED] OpenSSH_4.2p1 FreeBSD-20050903, OpenSSL 0.9.7e-p1 25 Oct 2004 debug1: Reading configuration data /etc/ssh/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to remoteserver [ip.address.here] port 22. debug1: Connection established. debug1: Remote protocol version 1.99, remote software version OpenSSH_4.2 debug1: match: OpenSSH_4.2 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.2p1 FreeBSD-20050903 debug2: fd 3 setting O_NONBLOCK debug1: Authentication succeeded (publickey). debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Entering interactive session. debug2: callback start debug2: x11_get_proto: /usr/X11R6/bin/xauth list :0.0 . 2/dev/null debug1: Requesting X11 forwarding with authentication spoofing. debug2: channel 0: request x11-req confirm 0 debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 0 debug2: channel 0: request shell confirm 0 debug2: fd 3 setting TCP_NODELAY debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 Now in the remoteserver: [EMAIL PROTECTED] % echo $DISPLAY DISPLAY: Undefined variable [EMAIL PROTECTED] % netstat -a remoteserver.sshlocaldesktop.51899 66608 47 66608 0 ESTABLISHED Even if i setenv DISPLAY to localhost:10, 11, 12 ... it does not work. And from this netstat output I cannot find the X11 tuneling channel. In another attempt below I have the following different debug messages: [localdesktop]% ssh -vvv -o ForwardX11Trusted no [EMAIL PROTECTED] debug2: x11_get_proto: /usr/X11R6/bin/xauth -f /tmp/ssh-9xszkw26hB/xauthfile generate :0.0 MIT-MAGIC-COOKIE-1 untrusted timeout 1200 2/dev/null debug2: x11_get_proto: /usr/X11R6/bin/xauth -f /tmp/ssh-9xszkw26hB/xauthfile list :0.0 . 2/dev/null debug1: Requesting X11 forwarding with authentication spoofing. debug2: channel 0: request x11-req confirm 0 and again DISPLAY is an undefined variable. Could anyone help me to get this X11 tunelling work? Thanks all very much, nader
