Enable root login from LAN only

Having SSH access to the root account can be catastrophic if someone ever does succeed in breaking into your machine. While the majority of sysadmins turn into rabid wolves upon mention that your machine allows root access, at times it may be necessary.

This should work on any UNIX-based operating system running OpenSSH 4.3p or later. You may determine the version of OpenSSH by using ssh -V.

On Linux, edit /etc/ssh/sshd_config. On Macs, edit /etc/sshd_config. Locate the line that defines PermitRootLogin, uncomment if it is commented out, and change its value to no.

On a separate line, add the following:

Match Address 192.168.2.*,127.0.0.1
      PermitRootLogin yes

This will allow root to login exclusively from your LAN, while denying all attempts from outside.

Tips: Extra security features to go along with this would be:

- Denying usage of 'sudo su'
- Disabling passwordless, guest, or otherwise anauthorized users from using 'su'
- Using the above Match Address syntax to only allow root to login using a publickey, not passwords
Read Full Post

Fixing a slow SSH prompt

For owners of multiple Linux machines, it's happened to all of us -- the machine in the living room responds immediately to SSH; but it takes forever to log in to the one in the closet, although it does succeed eventually.

This happens because of the SSH client attempting various authentication methods. Using ssh -vvv user@host, the output of a slow connection will look something like this:

debug3: check_host_in_hostfile: filename /home/drsavoye/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 11
debug1: Host '192.168.2.107' is known and matches the RSA host key.
debug1: Found key in /home/drsavoye/.ssh/known_hosts:11
debug2: bits set: 499/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/drsavoye/.ssh/id_rsa (0xb7f541a8)
debug2: key: /home/drsavoye/.ssh/identity ((nil))
debug2: key: /home/drsavoye/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug3: Trying to reverse map address 192.168.2.107.
debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure.  Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure.  Minor code may provide more information


debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/drsavoye/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/drsavoye/.ssh/identity
debug3: no such identity: /home/drsavoye/.ssh/identity
debug1: Trying private key: /home/drsavoye/.ssh/id_dsa
debug3: no such identity: /home/drsavoye/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
root@192.168.2.107's password: 

In this case, GSSAPI is failing alongside publickey-authentication, but unlike publickey, takes much longer to give up. To disable it, edit /etc/ssh/sshd_config and remove or comment out the lines #GSSAPIAuthentication yes and #GSSAPICleanupCredentials yes.
Read Full Post

Disabling / enabling SSH timeout

Read from remote host ariel.localhost: Connection reset by peer
Connection to ariel.localhost closed.

There are two ways to prevent SSH from timing out when left idle. The first is on the server, the second on the client. Both require editing the SSH config file.

The configuration is split between two files: On Linux, /etc/ssh/ssh_config and /etc/ssh/sshd_config. On OS X, they tend to reside in /etc/ssh_config and /etc/sshd_config. ssh_config is the configuration for the SSH program itself on the client, while sshd_config is the configuration for the SSH daemon on the server.

On the server machine uncomment, or add if it does not exist, the line:
ClientAliveInterval 60

On the client side, the line is:
ServerAliveInterval 60

The interval is in seconds, so you may specify any time period you like. On the server side, this defines the timeout interval after which no data has been received from the client that it should send a quick poke to request a response from the idle client. If the interval is set to 0, or the line does not exist, these messages will not be sent.

Similarly, on the client side, the interval is how often it should send a message to the server indicating that the connection is still active.

You must restart the sshd daemon after editing the file.
On Linux:
/etc/init.d/sshd restart

and on OS X: launchctl unload /System/Library/LaunchDaemons/ssh.plist and
launchctl load /System/Library/LaunchDaemons/ssh.plist

You can also restart sshd on OS X by unchecking and rechecking the box in System Preferences:


Read Full Post

Why does SSH refuse my RSA publickey?

After successfully generating RSA keys and copying the public key to the remote authorized_hosts, I have encountered many times a message like this when trying to ssh in:

Executing: program /usr/bin/ssh host
office-minimac, user (unspecified), command scp -v -t
~/.ssh/authorized_keys
OpenSSH_5.1p1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to office-minimac [192.168.2.103] port 22.
debug1: Connection established.
debug1: identity file /home/drsavoye/.ssh/identity type -1
debug1: identity file /home/drsavoye/.ssh/id_rsa type 1
debug1: identity file /home/drsavoye/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'office-minimac' is known and matches the RSA host key.
debug1: Found key in /home/drsavoye/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue:
publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more
information
No credentials cache found

debug1: Unspecified GSS failure. Minor code may provide more
information
No credentials cache found

debug1: Unspecified GSS failure. Minor code may provide more
information


debug1: Next authentication method: publickey
debug1: Trying private key: /home/drsavoye/.ssh/identity
debug1: Offering public key: /home/drsavoye/.ssh/id_rsa
debug1: Authentications that can continue:
publickey,gssapi-with-mic,password
debug1: Trying private key: /home/drsavoye/.ssh/id_dsa
debug1: Next authentication method: password
drsavoye@office-minimac's password:

This happens when the permissions of the .ssh directory or any of its items are incorrect. Commonly the mode of the .ssh directory itself will be set to 775 or 777; setting group write permissions on any of the files will cause this effect. The correct permissions of the .ssh directory:

~/.ssh{drsavoye@ushuaia} pts/4$ ls -la
total 40
drwxr-xr-x    2    drsavoye drsavoye  4096  feb 26 08:31 .
drwxr-xr-x    143  drsavoye drsavoye 20480  feb 26 08:31 ..
-rw-r--r--    1    drsavoye drsavoye   408  feb 25 22:01 authorized_keys
-rw-------    1    drsavoye drsavoye  1671  feb 25 22:01 id_rsa
-rw-r--r--    1    drsavoye drsavoye   405  feb 25 22:01 id_rsa.pub
-rw-r--r--    1    drsavoye drsavoye   810  feb 25 22:01 known_hosts

If they differ, use chmod 755 ~/.ssh and chmod 644 ~/.ssh/* to correct them.

Tip: using ssh -vvv {host} will return this verbose output.
Read Full Post