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: Decrypting an ssh session knowing the private key?
I would like to write a program that could deycrypt ssh communication by using the private key of the server computer. This should be possable right? I don't believe that is the case. SSH uses its private key only to certify its identity to the client. So knowing the private key lets you do a monkey in the middle attack, but not to decrypt a captured stream. Keying material is derived using the Diffie-Hellman algorithm, which uses randomly generated secrets at both ends. You'd have to know the transient Diffie-Hellman secret used by either the server or client. Regards Mark
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 > > > > > > > > > > > >
RE: Restricting sftp commands
Probably the most robust thing would be to use file-system ACLs to restrict users to the desired actions. They could always try a "get" command, but it would fail if they tried to download a file to which they lacked read permissions. That would also have the advantage of working regardless of what means they used to access the server - sftp, ssh, console, etc. Regards Mark -Original Message- From: m l Sent: December 21, 2005 07:36 To: secureshell@securityfocus.com Subject: Restricting sftp commands I've install OpenSSH_4.2p1 with RSSH on Solaris 10. It only accept "sftp" . I block SSh and the others. But the user still able to do commands like "chmod" "put" ,"get" etc..under sftp. Is there any way, when the user is in sftp prompt, to limit him to only use for example "PUT" command ? Martin "Do, Or do not. There is no try." -YODA- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.
RE: Some servers do not forward X11, but I do not know why.
Interesting... Do you have lsof available on the hosts where you can't get X forwarding? lsof -i should tell you all the processes with ports open, you can verify if there is some process hogging all 999 ports... If not, some versions of netstat can also show you the PID of the process that has the socket open. Regards Mark -Original Message- From: Christopher L. Barnard [mailto:[EMAIL PROTECTED] Sent: December 8, 2005 13:23 To: secureshell@securityfocus.com Cc: Christopher L. Barnard Subject: Re: Some servers do not forward X11, but I do not know why. On 12/6/05, Christopher L. Barnard <[EMAIL PROTECTED]> wrote: > > I have two identical Sun Solaris 9 servers. Both are running OpenSsh > version 4.2p1. Both have identical ssh_config and sshd_config files. > One allows me to run X programs and they are displayed back on my desktop. > The other one reports > > Error: Can't open display: > > What am I missing to force this server to set the DISPLAY variable so > that > X11 will be forwarded? As I say the ssh_config and sshd_config files > are identical with a server that works, and in particular ssh_config: > > ForwardX11 yes > > and sshd_config: > > X11Forwarding yes > X11UseLocalhost no > To add some information: not only is xhost not used, the binary is deleted if it exists every night on all servers by cron. Xhost is Evil (tm). Xauth is not the issue. It is in the same place on all servers. I have figured out what the problem is, but not how to solve it. Running the daemon in 3-layer-deep debug mode (-ddd) I discovered that the reason the server is responding "Error: Can't open display:" is debug2: bind port 6260: Address already in use repeated 999 times, for the 999 ports from port 6000 to port 6999. Then the two messages Failed to allocate internet-domain X11 display socket. debug1: x11_create_display_inet failed. I am ssh-ed in, but I do not have X. The server is busy, with about 200 ssh connections to it, but nowhere near the 999 maximum X tunnelling number... +--- + | Christopher L. Barnard O When I was a boy I was told that | | [EMAIL PROTECTED] / \anybody could become president. | | (312) 347-4901 O---O Now I'm beginning to believe it. | | http://www.cs.uchicago.edu/~cbarnard--Clarence Darrow | +--PGP public key available via finger or PGP +keyserver-+ This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.
