secure shell

If you want to remotely connect to a machine, use ssh because that works on a secure connection and at least on our servers it is guaranteed to run.

debugging

Especially for password less logins etc, you can debug on the client side by using one (or more) -v options.

ssh -v -v -v 10.10.1.4

On the server side, the easiest way is to alter the LogLevel option in /etc/ssh/sshd_config and to for instance :

LogLevel=DEBUG3

Which is also similar to the 3 -v's above. And then restart sshd

/etc/init.d/ssh restart

Now you can monitor the debugging information with :

sudo tail -f /var/log/auth.log

slow login : Cannot determine realm for Numeric host

The solution to this was to disable GSSAPIAuthentication in /etc/ssh/sshd_config. Then restart sshd.

Other causes can be reverse DNS look ups (set UseDNS no) or ssh attempts to connect to ipv6 first (no solution yet)

banner

You can alter the banner that display messages even before you login, by editing the file /etc/issue.net and adding the line :

Banner 

timeout problems

The linksys routers we use have a very annoying 'feature': they cut any tcp connection going through them after it has been idle for a while. It is the "stateful packet inspection" option in the firewall tab that seems to do that, but disabling it means you cannot login at all so we chose the lesser evil. Linksys should keep its hand of and just pass packets like a good boy. Most annoying is an ssh session that get's killed and what works is adding KeepAlive? to either the server (untested) or the client. For the server allegedly in /etc/ssh/sshd_config:

TCPKeepAlive yes
ClientAliveInterval 30

Should work , though i have not tested it yet, what i have tested is from the client side in /etc/ssh/ssh_config:

TCPKeepAlive yes
ServerAliveInterval 30

In the linksys log you see these packets pass every 30 seconds. You could set them longer of course. What happens now is you get disconnected as well, but much later and with another error, and NOT by the linksys router. Maybe now the server throws you out, and maybe the server config above helps in keeping the connection forever.

key files

When you install sshd (the server) on a host, default key files are generated for that host, and placed in /etc/ssh, normally rsa is used so the files generated are :

/etc/ssh/ssh_host_rsa_key (keep on the server) 
/etc/ssh/ssh_host_rsa_key.pub (copy to all clients)

These are the private and public key files used to setup the ssh sessions. The private key is the one that stays on the server and the public keys is distributed to all hosts attempting to log in to the server. This is the line you will find in your .ssh/authorized_keys file, it is the same for every user on every host that logged in to the server.All this is handled automatically by ssh when the first time you log in. You can also make your own private (and corresponding public) key file, ( for instance to be able to log in without password, see below ). In that case the name of the private file is ~/.ssh/id_rsa. You then have to manually put your generated public key in the authorized_keys file on every host you want to use to login to the server. It's worth the effort though ;) See the next chapter on how to generate your own key.

password less ssh

very short guide

For logging in from a to b:

a>ssh-keygen -t rsa
a>ssh-copy-id -i ~/.ssh/id_rsa.pub b
a>ssh b
b>

long guide

Here is a guide on how to connect without having to issue a password. This is mostly needed when using ssh/scp in scripts. Both sides need the other sides pub key to translate the data, but i always tend to turn things around. Maybe naming it here will help. These are the files used in setting up a key based login, for clarity the private key files are not shown, but of course they are represented with their .pub files on both client and server side. The direction of the arrow indicates where the key originated and where it was copied to. Where you see multiple arrows pointing at the same file, it contains multiple entries. And that's typically what you see in "authorized_keys", and "known_hosts" files. So here is an example, where the receiving machine will be called the server and the connecting machine(s multiple for clarity) are the clients. The server is called overthere. and the clients here. It is all user based so your username should be present on all system, the password may differ by the way. This all works from the clients perspective : first you create a key pair on your client :

[here1] ssh-keygen -t rsa

It will prompt you for stuff, if you want no password, don't fill one in when prompted. After this step, you will have a .ssh containing :

[user@here1] ls ~/.ssh
id_rsa
id_rsa.pub

If you use dsa they will be called identity and identity.pub. rsa is the newest so use that. The easiest way now to pass less login to overthere is :

ssh-copy-id -i ~/.ssh/id_rsa.pub overthere

You have to know the password for this copy operation. This will handle file creation, after this you will have one extra file on server and the client side :

[user@overthere] ls ~/.ssh
authorized_keys

and

[user@here] ls ~/.ssh
id_rsa
id_rsa.pub
known_hosts

authorized_keys contains as suspected the public key from 'here', known_hosts however contains a strange key, but it is actually the 'host' key which is stored in overthere:/etc/ssh/ssh_host_rsa_key.pub If you do the same from here2, authorized_keys will be augmented with the new public key, just as known_hosts will be augmented when you connect to another server. However, this still allows other machines to login using the normal password authentication, if you really only want to allow key login, alter this setting in /etc/ssh/sshd_config:

PasswordAuthentication no

and restart ssh, now you only get in with the correct key.

key realm

For klopt.org all login will be disabled and keys will be used, here are the installation instructions for admins (servers) and clients (clients;)

serverside install

There is really only one key pair, it will be replaced when needed. Here are the instructions for a server. Get the usb stick called ssh keys and take the public key from klopt.org/id_rsa.pub and install that in authorized_keys :

cat (usbstick):klopt.org/id_rsa.pub >> ~/.ssh/authorized_keys

cat >> makes sure the keys is added to the previous content. If just plugging in the usbstick does not automatically mount, watch watch what's printed on the command line or view dmesg. It probably mentions which device it is coupled to, for instance: sdc If so add this line to /etc/fstab

/dev/sdc /media/usbstick auto rw,defaults 0 0 

and type :

mkdir /media/usbstick
mount -a

After testing it first ;) turn of password authentication with

PasswordAuthentication no

See section above.

client side install

On linux, the procedure is to create the klopt.org user account first, end then copy the private key from the usb stick:

adduser klopt.org
cp (usbstick):klopt/id_rsa ~/.ssh
chmod 600 id_rsa

bind address

The syntax for this is :

ssh [bindaddres:]port:host:port

In the man page, but try the command itself: this syntax is not supported !?! So another solution must be :

chaining

Ok the idea remains : i want to reach the website of zakaf, an internal machine within klopt.org, from the outside world. You can do this in steps, and since you get a login on the next machine you can do it 'as you go'. For instance starting on any machine outside klopt.org:

anywhere> ssh -L 8888:localhost:8888 obelix.klopt.org
obelix> ssh -L 8888:localhost:80 zakaf.klopt.org
zakaf>

You now have a login on zakaf, but also chained anywhere:8888 to obelix:8888 and obelix:8888 to zakaf:80 The port can be the same, but must be above 1024 if you are not root and available. Open up your browser on 'anywhere' with the url localhost:8888 and you get the webpage of zakaf. And of course as a bonus, everything passing back and forth is encrypted. You can even do it with ssh itself, but of course you cant use port 22, it is not free so :

anywhere> ssh -L 8888:localhost:8888 obelix.klopt.org
obelix> ssh -L 8888:localhost:22 zakaf.klopt.org
zakaf>

You can now login directly to zakaf (or for instance [wiki:scp scp] data) by using the -p(ssh) or -P(scp) option :

anywhere> scp -P 8888 localhost:datafile .
anywhere> ssh -p 8888 localhost

Also when you try to logout your 'tunnel' session it waits if you are still connected over the second ssh session. A side effect of this is that you get a "REMOTE HOST IDENTIFICATION HAS CHANGED!" warning, because that tries the 'false' key for localhost