Ssh basics

From openSUSE

SSH Basics

Author: Sander

Goals. This howto is not meant to go in to the dirty details of ssh. It is just meant to help you solve some common problems.

Who? This howto is for starting linux users with ssh problem or who just want to sharpen there knowledge. It is however NOT intended for experienced users, although they are welcome to comment they ,most likely will not learn anything new.

So lets start: SSH is short for: Secure Shell. This explains just what it is ssh is a way to just a shell on another computer in a secure way. the data transmitted over Ssh is an encrypted where as for example Telnet is not encrypted. in fact when you sniff an telnet connection you'll see username and password used to setup a connection flying across you screen. which is very useful if you're a bad person. but as we don't want that to happen we'll use SSH. SSH consists out of two parts. 1. the client, we'll be talking about that one. 2. the server, we'll not be talking about that one, but port 22 in the fire wall must be open.

Loging in: When you want to log in on an other computer using ssh you'll have to give the command "ssh username@host" after the client and server have made there connection. Or if you use the same user name on you client machine as on the server machine you can just give the "ssh host" command. When you give the correct password you'll be logged in. have fun.

However: When you log in for the first time encryption keys will be made. You'll be noticed of this with the massage:

{The authenticity of host '"hostname" ("host ip")' can't be established.
RSA key fingerprint is :::::::::::::::.
Are you sure you want to continue connecting (yes/no)?}

type yes. and you'll be able to connect.

Problems do arise when the ip address of the target host changes. you'll get an error message and there will not be an connection. In this case you can got to your home dir and go to the .ssh directory. here lives a file called "known_hosts" you can open this file in vi and delete the line which has the hostname and ip address in front of it. (use dd to delete the line) when you try to connect to the server after this you'll be asked if you want to make a key, you'll know what to do.

you can also have a problem when the host name is not resolved. the error here is:

"ssh: (hostname): Name or service not known"

In such a case use the ip address in stead of the hostname or get your resolve problem fixed.

The end: to log out of your ssh session type simply "exit". There is a lot more the be known about SSH, but the above is what i think is the knowledge you'll need to work with ssh and solve the most common problems.

SSH with Konqueror

In order to use Konqueror to support ssh sessions which use key pairs you will need to follow the steps below

1. create a file called config file here: ~/.ssh/config

I have a server called anaconda, the config I use client side (the contents of ~/.ssh/config used to connect to anaconda) looks like this:

Host anaconda
Hostname anaconda
IdentityFile /home/mblanc/.ssh/anaconda_key
LocalForward 8080 127.0.0.1:8080
PasswordAuthentication no
Port 3423
PubkeyAuthentication yes
User mblanc

You can get all the available parameters from here: http://developer.apple.com/documentation/Darwin/Reference/Manpages/man5/ssh_config.5.html. Of course, you can also query man ssh_config from the command line.

2. Open a Konqueror session. Konqueror won't read user from the config file. It won't read port either.

What you need to do is use this form in the address if you want to use keys with a non standard user name (i.e. not the user name you are currently logged into Linux as) and a non standard port (i.e. not port 22 for SFTP)

sftp://<user name>@hostname:<port#>

Example

sftp://billy@mywork.com:5332

Config file will work (set user name and port) for command line sftp connections though.

Also...

You can test your ssh server with a loopback session.

I have found with openSUSE11.0 that when a new user (with keypair auth) is added remotely i.e. over ssh, and then an attempt is made to connect to the server using the new account (with an rsa2 key pair) that connection is refused. Strangely the problem is fixed by connecting to the machine using a loopback address (localhost or 127.0.0.1) once. Then remote connections will be accepted. Weird eh!

An example of a loopback connect is:

ssh -l <username> -i <keyfile> -p 22 localhost

where:

<username> is the user you will to connect as - may be omitted if you are already logged into the machine as that user.

<keyfile> is the path to the key used to authenticate <username> i.e. a private key which has a public key counterpart in /home/<username>/.ssh/authorized_keys.

Note that I have also found that for the loopback (with keypairs, first attempt to access via ssh for a new user) to work you must be logged into the server as the user whose account you are trying to access. For example, DON'T log in as root and then su to the user - I've found this can give a strange error where the client attempts to present the key as a public key (rather than a private). I imagine it has something to do with root masquerading as the user. I realise this will all sound quite strange but I have tested it extensively. Set up the keys, su to the user (not from root) and establish a loopback connection. Then all will be fine.