By default, ssh server performs a reverse DNS lookup for authentication requests. This can be so annoying as you wait ten’s of seconds for the lookup to finish. You may experience a delay before receiving a password prompt while accessing a remote system via ssh.
This guide will show you how to disable SSH reverse DNS lookups in a Linux/Unix system. The method discussed here works for all Linux and Unix based operating systems running OpenSSH Server.
Today, I was tempted to take control of a Windows machine remotely in console mode as I’m trying to script the launch and use of VLC. A quick Google search reveleaed the existence of the sshwindows project which is a more lightweight solution than a full cygwin installation.
Here are the installation steps :
Full article here:
Installing OpenSSH on Windows 7 (World Gone Web)
The upstream openssh project sets the value ServerKeyBits to 1024, but Debian and Ubuntu currently unfortunately have a lower security setting of 768 bits. I’ve filed a bug to fix this. In the meantime, here is how to make that change now!
Full article here:
Debian and Ubuntu Linux: Set openssh SeverKeyBits to 1024 (scottlinux.com)
From the CentOS Wiki comes this list of suggestions for Securing OpenSSH. Most, if not all of them will work on other Linux distros as well.
I’ve seen this happen several times now on Ubuntu-Linux based systems that have NVIDIA graphics. What happens is that “Update Manager” pops up and tell you there are updates for your software, and you accept them. It then tells you that your system has to be rebooted. And when you do that, you get no video, or text only. What probably happened was that the updates you installed included an update to the Linux kernel, and the NVIDIA graphics driver currently installed on the system was compiled against the OLD kernel.
Note that this generally can only happen if you manually updated the NVIDIA graphics driver at some point. If you always installed it from the standard repositories for your distribution, you’ll probably never see this issue. So a word to the wise — when you finally get around to doing an upgrade of your Linux distribution, try to avoid manually installing the NVIDIA graphics driver. Instead, let the distribution pull it from its repository. After that, you should not have this issue in the future. By the way, if you currently are running Ubuntu, we recommend upgrading to Linux Mint rather than a newer version of Ubuntu. Linux Mint is very similar to Ubuntu, but leaves out some of the things that users seem to hate about newer releases of Ubuntu. More to the point, they are not currently talking about switching their base graphics system from the X window server system to a new display manager, which I have a feeling might cause problems for some NVIDIA graphics users.
But if you’re not yet ready to do a full reinstall of Linux, the fix for this problem is easy IF you had the foresight to set up SSH access to your Linux system BEFORE the trouble started. If you didn’t, and you’re not a true Linux geek, you may be kind of screwed. So if you’re reading this and your system is working fine, and you haven’t yet set up SSH access, you may want to do that. There are several sites that tell you how to do that; here are two that I found using Google:
If you didn’t do this beforehand, you may still be able to do it if you can get to a command prompt.
Anyway, the actual fix is to (re-)install the latest NVIDIA driver for your system. They will be compiled against the new Linux kernel and then everything should work fine. To find the correct NVIDIA driver, go to the NVIDIA Driver Downloads page, and use the dropdowns to select the correct driver for your system. Download it to your local system, then upload it to your Linux PC (if you have SSH access working then you can use an SFTP client, such as WinSCP or Transmit, to upload your driver file). Once you have it on your PC, from a command prompt navigate to the directory where you put the driver and then change the permissions to make it executable:
sudo chmod +x driver_upgrade_script_filename
Now try running the script (it should have a .run extension):
It should not complain that the Gnome Display Manager or KDE Display Manager is running (if it were, you wouldn’t be in a state of near-panic right now), but if you were just doing a regular update you’d have to do this when the GDM/KDM is stopped. For a guide that covers that scenario, see How To Install Official Nvidia Drivers in Linux, or just know that to stop the display manager,
sudo /etc/init.d/gdm stop
should stop the Gnome Display Manager, or if you’re using KDE then the command would be
sudo /etc/init.d/kdm stop
Most sources I’ve seen suggest that you answer yes to any questions the installer may ask. The only one I’d be cautious about is letting it create a new xorg.conf if you are using a customized one (which you may well be if you’ve used any of my previous HTPC-related articles). If you have edited xorg.conf, then I’d make sure you at least have a backup before letting the installer create a new one, so you can revert back to your custom one (or compare the two and insert your customizations into the new one) if necessary.
Under Ubuntu, you may get a message similar to “Provided install script failed”. That will happen every time you update the NVIDIA driver this way and it is normal. Just ignore it and continue the installation. If you get “Error locating kernel source”, run sudo apt-get install kernel-source from the command prompt, then run the driver upgrade script again.
When the installer has successfully finished, reboot the system and when it comes back up, hopefully you should be happy again!
This article assumes that you are already able to ssh into a remote server using a password (that is, that your account has been created on the remote system and you are able to access it). Here’s how to set up ssh public/private key authentication so you don’t have to use the password on future logins, or so you can use Public Key authentication with MacFusion.
First, open a terminal or iTerm window as we will be using it for most of the following operations. First, navigate to your home directory, and see if there is a folder called .ssh. Note that Finder will NOT show you this directory unless you have it set to show all file extensions, so since we are at a command line prompt anyway, it’s easiest to just type “cd ~” (without the quotes) to go to your home directory in Terminal or iTerm and type “ls -a” (again without the quotes – always omit the quotes when we quote a command) to see if the .ssh directory exists. If it does, go into the directory (”cd .ssh”) and see if there are two files called id_rsa and id_rsa.pub (use “ls -a” again). If either the directory or the files do not exist, you will need to create them.
ssh-keygen -t rsa -f ~/.ssh/id_rsa -C "firstname.lastname@example.org"
Replace email@example.com with your email address – this is just to make sure the keys are unique, because by default it will use your_user_name@your_machine_name.local, which might come up with something too generic, like john@Mac.local. It’s unlikely that anyone else is using your e-mail address in a key. If this process fails with a “Permission denied” error, it might be because SELinux is enabled. To check that theory, see How to Disable SELinux, which will show you how to disable it temporarily (for testing) or permanently.
Now, from your terminal window on your local system, execute this command:
You can run ssh-copy-id -h or man ssh-copy-id to see the available options, but normally you don’t need any. In the event your system does not have ssh-copy-id installed, you can instead run the following three commands from a terminal or iTerm window on your local system. Whichever method you use, replace username with your login name and remote with the address of the remote system. Note that you should NOT be logged into the remote system when you execute these – these are run from a command prompt on your local system, and you probably will be prompted to enter your password (for the remote system):
ssh username@remote ‘mkdir ~/.ssh;chmod 700 ~/.ssh’
The above creates the .ssh directory on the remote system and gives it the correct permissions. If the command fails (for example, I’ve had it complain that mkdir isn’t a valid command, even though it is on just about every Unix/Linux system), then either you have copied and pasted the above line and WordPress changed the single quotes to the “prettified” versions (so change them back) or you may have to actually log into the remote system (using a password) and enter the two commands individually (mkdir ~/.ssh followed by chmod 700 ~/.ssh). Then, if you don’t already have an authorized_keys file on the remote system, go back to your local terminal or iTerm window for this:
scp ~/.ssh/id_rsa.pub username@remote:~/.ssh/authorized_keys
The above creates a new list of authorized keys on the remote system (overwriting any existing file with that name) and copies your public key to it. If you already have such a file and don’t want it overwritten, then you’ll have to manually add the contents of your local ~/.ssh/id_rsa.pub file to the end of the ~/.ssh/authorized_keys file on the remote system.
ssh username@remote ‘chmod 600 ~/.ssh/authorized_keys’
This fixes the permissions on the authorized_keys file on the remote system. Once again, there may be the odd situation where you can only run the command within the single quotes from the remote system.
And, that’s basically all there is to it. If you are the system administrator of the remote system, but you don’t ever plan to login from a remote location as root, then for extra security edit the file /etc/ssh/sshd_conﬁg on the remote system (you’ll probably have to be root, or use sudo to do this task). Just use your favorite text editor on the remote system to open the file, and look for a line that says:
And change the “yes” to “no”.
If you are still asked for a password after you are finished making the above changes, look for a line in /etc/ssh/sshd_conﬁg that says:
And change the “yes” to “no”. You’ll need to reboot or restart the ssh server for this to take effect. An alternate, and probably more secure fix is to check the permissions on your home directory – if it is not writable by anyone but the owner, then it should not be necessary to change the StrictModes parameter. For more troubleshooting hints see Debugging SSH public key authentication problems.
The above are very basic instructions for setting up ssh public/private key authentication. There are other ways to do this (including some that are arguably a bit more secure) but we wanted to keep it simple. Hopefully this will help someone who is using ssh, MacFusion, etc. and wants something a bit more secure and less bothersome than password access.
One other note: If you find the connection drops within a minute or so, particularly after you’ve just purchased a new router, then on the client machine running Mac OS X edit the file /private/etc/ssh_config (under Linux it’s /etc/ssh/sshd_config and I don’t know what it would be called under Windows, or if they even have such a file) and add this line:
If it still stops working lower the timeout to 30. See How to fix ssh timeout problems for more information.
If you find my instructions confusing, try SSH Passwordless Login Using SSH Keygen in 5 Easy Steps.
And, for hints on making ssh more secure (particularly if you permit access from the Internet in general and not just your local network), see this article on Securing OpenSSH (via the CentOS wiki).