X11 Forwarding Broken on Solaris
If you’re running Solaris 8 or 9 and an upgrade results in broken SSH X11 forwarding, the problem may be Sun’s socfs bug. The symptom will be SSH’s failure to set the $DISPLAY variable and an error in your system log looking something like this:
Jun 3 09:40:24 servername sshd[26432]: [ID 800057 auth.error] error: Failed to allocate internet-domain X11 display socket.
To fix this, you can either install Sun’s latest socfs patch for your version of the OS, or simply force sshd into IPv4 mode by doing the following:
Edit you sshd_config file, adding the following:
# IPv4 only
ListenAddress 0.0.0.0
Edit your sshd startup script to issue a “-4″ to sshd on start:
case “$1″ in
’start’)
echo ’starting ssh daemon’
/usr/local/sbin/sshd -4
;;
Restart sshd, and that should pretty much do it… Enjoy.
Blank Window When SSH Forwarding X11 Sessions
There are a number of applications running on our servers that have GUI’s that I need to display on the Mac in my office. While the traditional method of exporting the server-side display to my desktop works, it is inherently insecure because the entire session, including any passwords that may be sent are all transmitted in clear-text.
Better to use SSH X11 forwarding. This way the entire session is encrypted and nobody can snoop your passwords. The process of using SSH X11 Forwarding goes something like this:
On the server-side (the machine from which you want to forward the display, make sure this line is in your /etc/ssh/sshd_config file:
X11Forwarding yes
If you had to add it, restart the sshd service.
/sbin/service sshd restart
Now, from the client-side (the machine on which you want to display the forwarded X11 application) connect to the server-side machine with the -X flag. Like so:
ssh -X username@remoteserver
Now you should be able to start X applications and have them display on your client machine through an ssh tunnel. If you are like me, however, some Java applications will not display correctly. Instead of popping up a window with the full application in it, I would only see a totally useless blank window. This frustrated me for months until I found this article at kraftek.com that details how to resolve the problem.
It turns out that all you have to do is put this line in the ssh_config file on your client-side:
ForwardX11Trusted yes
After logging out and back into the server-side machine, everything worked perfectly.
Disable SSH Root Logins on RHEL
For one reason or another RHEL does not disallow incoming ssh connections as root. This is, of course a glaring security problem which should be addressed for all systems that allow ssh connections to be made from any but the most restricted networks.
The best practice, of course, would be to make the initial ssh connection as an unprivileged user and then use the “su” command to promote yourself to root. This way, even if an attacker managed to get into the system, it would be as an unprivileged user and they would not able to do much harm. Allowing incoming ssh connections at root leaves you much more exposed to attack. Granted your root password is still protecting you, but it becomes your only layer of defense.
Ok, so how do we disallow incoming ssh connections as root on our RHEL box?
First, edit “/etc/ssh/sshd_config”
Find the section of the file that looks like this:
# Authentication:
#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
Change this line:
#PermitRootLogin yes
To this:
PermitRootLogin no
Restart sshd:
/sbin/service sshd restart
Changes to Solaris ssh_config for Password-less SSH Login
Zach over at NoSheep has written a really nice article about how to configure a SSH trust relationship on UNIX systems. By doing this, you can prevent the system from prompting you for a password, thus allowing the user to use scripted solutions to move files around with sftp, etc. He didn’t mention, however, that to get this up and working correctly under Solaris, you have to uncomment the following lines in your /usr/local/etc/ssh_config file:
RSAAuthentication yes
And one of these lines. In most cases the Identity File will be id_rsa.
# IdentityFile ~/.ssh/identity
IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
