openssh NOT ssh1.27 type
overview
"Ssh (secure shell) is a program for loggin into a remote machine and for executing commands in a remote machine. It is intended to replace rlogin and rsh, and provide ecure encrypted communications between two untrusted hosts over an insecure network."
There is good text in the OVERVIEW file found in /usr/share/doc/openssh-2.1.1p4-1. Here is a extract:
The sshd server (daemon)
- The sshd daemon starts by processing arguments and reading the
configuration file (servconf.c). It then reads the host key,
starts listening for connections, and generates the server key.
The server key will be regenerated every hour by an alarm.
- When the server receives a connection, it forks, disables the
regeneration alarm, and starts communicating with the client.
They first perform identification string exchange, then
negotiate encryption, then perform authentication, preparatory
operations, and finally the server enters the normal session
mode by calling server_loop in serverloop.c. This does the real
work, calling functions in other modules.
- The code for the server is in sshd.c. It contains a lot of
stuff, including:
- server main program
- waiting for connections
- processing new connection
- authentication
- preparatory operations
- building up the execution environment for the user program
- starting the user program.
what starts and runs this daemon? There is a script in
/etc/rc.d/init.d/sshd.
quickstart
- ssh hostname
do not use ssh-add, ssh-keygen, do not make keys, and this will work because the default is to allow password authentication.
The 'ssh' command is the client program which connects to the sshd server (daemon).
It is run as "ssh [-l login_name] [hostname | user@hostname] [command]"
logins according to: equiv.hosts, RSA based authentication (public key cryptography).
for example: ssh -l joe 192.168.1.3
the above is the simplest method to configure. Else {if other methods used} for a client to connect to a server, the client hostname must appear in a trusted host file on the server (not always true).
naming keys
client publickeys
- id_rsa.pub
- for ssh protocol 2
- identity.pub
- for ssh protocol 1
- id_dsa.pub
- public key for dsa protocol
the private keys are the same minus the
.pub extension
server keys
- public server host key
- /etc/ssh/ssh_host_key.pub
- private server host key
- /etc/ssh/ssh_host_key
- not encrypted
- set the immutable bit
/etc/ssh/ssh_host_rsa_key.pub
/etc/ssh/ssh_host_dsa_key.pub
You have to generate public/private keys using 'ssh-keygen'. man ssh-keygen.
recent shipments of openssh make keys for server at compile time. not for client, however.
Generate these keys with the ssl library. It's an amazing library, which lets you generate certificates, too, as well as keys for assymetric encryption {assymetric encryption: using a public/private key pair, that kind of thing}. After generation of the keys, or certificates, you then place them in the places specified here so that the daemon can find them. At present, ssl is dealt with by ssl.htm
- ssh-keygen -f file_name
- -t dsa
- -t rsa
-
original command
the original command goes in the key file, just before the key.
note that you can invoke a wrapper script which in turn invokes arguments like so:
#!/bin/sh
echo "$SSH_ORIGINAL_COMMAND" > /tmp/foo
exec $SSH_ORIGINAL_COMMAND
authentication schemes
rhosts authentication
trusted host authentication scheme
- $HOME/.shosts
- $HOME/.rhosts
- /etc/shosts.equiv
- /etc/hosts.equiv
one and three are unique to ssh
if RhostsAuthentication in /etc/ssh/sshd_config is set to yes, then if there is a match in 3 or 4 access is granted
if that fails, if 1 or 2 access is granted.
I NEVER GOT THIS TO WORK!
above with added requirement that the client's public key in ssh_known_hosts on server. APPARENTLY CLIENT ALSO HAS A PUBLIC HOST KEY which is here used for auth????
rsaauthentication
sample /etc/ssh/sshd_config www.boran.com/security
note the following about this:
- public user key comes into play only in this scheme, not in others
- the server gives the client its keys early on in the transaction, but other than that, are not required for configuration here
- if the client doesn't recognize the server's keys, it asks the client if it will accept it anyhow
- RSAAuthentication yes in the conf file
- the keys are generated upon installation of a binary rpm (server) or ssh-keygen(client)
- debug server with sshd -d
- debug client with sshd -v -v -v
- cool!
One step on this path, is you need to copy $HOME/.ssh/identity.pub from local host to $HOME/.ssh/authorized_keys on remote host. i.e. to do this you need to copy YOUR PUBLIC KEY from LOCAL host to REMOTE SERVER. The following is all the steps:
checklist for user root logging in from www.sirfsup.com to mail.sirfsup.com:
- for server mail.sirfsup.com:
checklist:
- /root/.ssh/authorized_keys
- ssh-rsa AAA.................................................................................................................................................................................................UKs= root@www.sirfsup.com
- matches /root/.ssh/id_rsa.pub on client
- modes on this file must be 644
- /etc/ssh/sshd_config
- HostbasedAuthentication yes
- RhostsAuthentication yes
- RSAAuthentication yes
- PubkeyAuthentication yes
- AuthorizedKeysFile ~/.ssh/authorized_keys
- ChallengeResponseAuthentication yes
- AuthorizedKeysFile %h/.ssh/authorized_keys as a replacement for the tilde specifygin $HOME
- /etc/ssh/ssh_host_rsa_key.pub
- ssh-rsa AAAAB...............................................................................................................................................................................................Ghs=
- will match ~/.ssh/known_hosts on client
-
- checklist for client www.sirfsup.com:
- /root/.ssh/known_hosts
- includes among other entries the one for mail.sirfsup.com (the server in this case) .....
- mail.sirfsup.com ssh-rsa AAA.................................................................................................................................................................................................Ghs=
- this matches mail:/etc/ssh/ssh_host_rsa_key.pub
- it's all about logging in over there, not logging into here
- if removed from server side no password => login
- used for verification of server public host key
- /root/.ssh/id_rsa.pub
- ssh-rsa AAA................................................................................................................................................................................................pUKs= root@www.sirfsup.com
- matches mail:/root/.ssh/authorized_keys
- /etc/ssh/ssh_config
- Host *
- ForwardAgent no
- ForwardX11 no
- RhostsAuthentication no
- RhostsRSAAuthentication no
- RSAAuthentication yes
- PasswordAuthentication yes
- BatchMode no
- CheckHostIP yes
- StrictHostKeyChecking ask
- IdentityFile ~/.ssh/identity
- IdentityFile ~/.ssh/id_rsa
- IdentityFile ~/.ssh/id_dsa
- Port 22
- Protocol 2,1
- Cipher 3des
- Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
- EscapeChar ~
mistakes:
- authorized_keys2 and authorized_hosts2 are not valid, what the hell is a '2' for????
- forget about dsa keys for the time being, just follow above, get rsa keys to work
- /root/.ssh/known_hosts
- not required on server
- /root/.ssh/authorized_hosts
- this is not a valid file name, serves no purpose except to confuse!
port forwarding
- /etc/ssh/sshd_config
- port forwarding yes
Forward connections to local port 4225 to internal.server.com port 22
- $ssh -L 4225:internal.server.com:25 lilly.csoft.net
- use port 25
- use port 22
- etc.!
another example
- ssh -C -f popserver -L 11110:popserver:110 sleep 5
- -C enables compression
- -f backgrounds
- we need to run this command on the machine doing the forwarding
- incoming connections from A will go through B (us) to get to B, the popserver
- configure A to connect to B via port 11110 after creating the connection from A to B and telling B to accept connections on port 11110
example script
- #!/bin/sh
- ssh mail.sirfsup.com
- ssh www.sirfsup.com
- commands go here
return to top
