OpenSSH

Summary

Configuration files

  • /etc/ssh/ssh_config
  • /etc/ssh/moduli
  • /etc/init.d/ssh
  • /etc/pam.d/ssh
  • /etc/default/ssh

Software

  • conspy -- remote control of Linux virtual consoles
  • screen -- run several virtual consoles in one, also remote
  • ssh
    • scp
    • sftp
  • sshfs (mount a remote directory via ssh using fuse)
  • ssh-askpass (under X, asks user for a passphrase for ssh)
  • kssh

Security

Make sure that your sshd is installed and configured properly:

  • PermitRootLogin without-password
  • disable SSH v1 -- allow only SSH v2
  • LoginGraceTime 5 seconds (time to type a password once)
  • PasswordAuthentication yes (but not for root)
  • ChallengeResponseAuthentication no (otherwise "without-password" is bypassed)
  • UsePAM no (requires ChallengeResponse, don't use with PasswordAuth)
  • ssh-keygen -t dsa may be better than ssh-keygen -t rsa
You could disable password login on some machines, allowing only public/private key login, but the arrangement above is pretty good. 

Also, make sure all the passwords on your system are strong.

See What is encryption for an overview of the technology.

sshfs

Mount remote drives per user with ssh.

The fuse module is in kernel 2.6.14 onwards; see fuse. You may need to manually create the device node (or figure out how to help udev do it) -- or it may get created when you "modprobe fuse" -- it does on trevi.

mknod -m 666 /dev/fuse c 10 229
When installing sshfs (in Debian and Ubuntu), let it create group "fuse" and add relevant users to this group with "adduser tord fuse".

To mount and unmount (user must of course have write access to mountpoint),
sshfs chi:/tv4 mountpoint
fusermount -u mountpoint
If root can do it but others not, issue
chmod u+s /usr/bin/fusermount
The advantage here is that the mount process uses ssh and the ssh keys that already exist on the remote machine.  It is the mounting machine that needs the fuse kernel module and the sshfs package -- the remote machine where the resource is actually located sees only an sftp connection! You can even give a special port:

        sshfs -p 9022 wester:/pub /mnt/vd

This means really remote systems can be mounted, per user, safely, with no need to set up exports.  You can run it through tunnels.  Wow -- this stuff is slick; no error messages, no fuss, and reportedly faster than NFS (not tested).  Automount on boot can be handled in a script; if you use keys, there are no passwords.

Remote Display

Try this one:

  • ssh trevi
  • X -ac :0 &
  • set DISPLAY 128.97.221.30:0
  • DISPLAY=128.97.221.30:0; export DISPLAY
  • exec startkde

This should let you run all of KDE remotely on Clitunno, on two conditions: you must be running X on Sigillo, and that X session must allow Clitunno to connect. So those permissions must be set first. I've still not tested this -- but here's what I get on Sigillo when the permissions have not been set:

AUDIT: Tue Oct 4 08:17:03 2005: 5306 X: client 1 rejected from IP 128.97.221.35

You can also run a KDE (or IceWM etc.) session remotely using x2x so that your mouse and keyboard switches between a local display and a remote display -- cf. instructions.

Automatic Network Login with SSH

First check the /etc/ssh/sshd_config file on the server side, and make sure PubkeyAuthentication isn't set to no. If it's not in the file at all that's fine, since the default setting is yes. If you have to change your sshd_config file make sure you restart sshd after you save it.

Next, you need to make sure you have a key pair client side, so check if ~/.ssh/id_rsa.pub exists. If it doesn't, you can generate it by running the command 'ssh-keygen -t rsa'. It's fine to leave the passphrase blank. (I get "Your public key has been saved in /home/steen/.ssh/id_rsa.pub".)

Once you have id_rsa.pub, run the command 'ssh-copy-id -i ~/.ssh/id_rsa.pub username@192.168.0.101' (replace username with your login on the server and replace the ip with that of your server). I just did "ssh-copy-id -i ~/.ssh/id_rsa.pub sigillo" -- or you can do

ssh-copy-id -i ~/.ssh/id_rsa.pub steen@spello
Now try logging into the server, you should now be able to login without a password. Keys from other computers can be added the same way from those computers, if you want to be able to login without a password from different boxes on your LAN.

Note that the logic of this is that the RSA keys need to be generated on machine A only if you want machine A to have direct access to other machines. Target machines don't need the keys.

Reverse Port Forwarding

Here's a recipe that will let us set up a connection into a firewalled network ("inside") from UCLA ("outside"), using a secure tunnel (http://www.yak.net/fqa/81.html -- a bit out of date, so modified accordingly).

1. Generate a secure key on the "outside" machine, Spello, by issuing

ssh-keygen -t rsa
It will ask "Enter passphrase (empty for no passphrase):" -- just press return. This creates ~/.ssh/id_rsa.pub.

2. E-mail your ~/.ssh/id_rsa.pub file to the "inside" machine (sokrates), save the key in /tmp, open a console and issue,
cat /tmp/id_rsa.pub >> ~/.ssh/authorized_keys
This gives the outside machine password-free access to the inside machine, once the tunnel has been established.

3. Generate a secure key on the inside machine by issuing,

ssh-keygen -t rsa -f ~/.ssh/tunnel -C "tunnel sokrates"

Again, just press return for passphrase. This creates two files, tunnel (the private key) and tunnel.pub (the public key).

4. Copy the secure public key to the outside machine by issuing,

ssh-copy-id -i ~/.ssh/tunnel.pub spello

You'll be asked for a pw, log in as usual.

5. Test access. Back on the inside machine, issue

ssh -i ~/.ssh/tunnel spello

You should now be logged in without being asked for a pw. Exit the connection.

6. Establish the tunnel. Again back on inside machine, issue

ssh -i ~/.ssh/tunnel -R 7000:sokrates:22 spello

This sets up a "reverse port forwarding".

7. On the outside machine, add this to /etc/hosts:

127.0.0.1 sokrates

This allows ssh to assign the RSA key to the correct host when going through the tunnel.

8. Enter the tunnel. On the outside machine, issue

ssh -X -p 7000 sokrates

and you'll go right through to the inside machine (or you'll get a login prompt; enter the password for the inside machine). The tunnel is working.

9. In kcron on the inside machine, enter

ssh -i ~/.ssh/tunnel -R 7000:sokrates:22 spello sleep 3200

Here a script you can run to make the tunnel -- save it as /usr/local/bin/tunnel:

#!/bin/bash
while `true`; do
    ssh -i ~/.ssh/tunnel -R 7000:sokrates:22 spello sleep 32000
    sleep 1
done

10. If you start konqueror on the outside machine:

fish://sokrates:7000/

You can see the inside machine in the gui, and move files around.

LISa -- LAN Interface Server

I set this up in March 2003; see configuration files under /etc/LISa.

OpenSSH key management by IBM

Remote X11 through SSH

To enable A to run remote programs on B, enable X11 forwarding in the ssh configuration. Enter "yes" in A:/etc/ssh/ssh-config and B:/etc/ssh/sshd_config. List B in A's /etc/hosts.allow (not positive this is required).

Or use "ssh -X <remote>

Screen (dtach allows shared sessions)

Start by typing screen.

Ctrl-a d        = detach
Ctrl-a c         = new session
Ctrl-a x          = screen lock
Ctrl-a spacebar = next session
Ctrl-a p           = previous session
Ctrl-a r          = reattach

Multi-user sessions:

Start up screen with a temporary screenrc file that contains:
multiuser on
addacl other_username
detach

Note the screen session detach. Type "screen -ls" to get the screen session name (for the other person), then type "screen -r" to reattach. The other person ssh'd into my machine and typed "screen -x session_name". It is possible to script all of this to make it easier.

You can then edit a single file at the same time -- better be on the phone too!

SSH under Linux

Note that I'm able to run programs remotely on cyberspace from gubbio, but not on gubbio from cyberspace -- the authentication isn't set up. So I don't exactly know what I did to make it work on cyberspace, or to keep it from working on gubbio -- and you need to have a clear recipe for this. Maybe when you get Debian you'll figure it all out.

SFTP

The program gFTP is great. It provides you with secure FTP access to Merton, to mail, and to cyberspace. The trick for cyberspace was to enter /usr/lib/ssh in the Properties panel in the bookmark for the site in gFTP -- at that point, it all worked. (Make sure you don't enter it into the File | Options | SSH panel, as this kicks in for all connections.) It's really like a good secure CuteFTP, and you should put it on both gubbio and cyberspace. You should also investigate to see if Dreamweaver can be made safe, through ssh tunneling.

sftp cogweb@cogweb.net -- log into user@host with sftp, the secure shell ftp client. Cf. rsync.

SSH for Windows

When you connect to SSC from the laptop, it's listed like this:

laptop.sscnet.ucla.edu (ts12-106.dialup.bol.ucla.edu [164.67.22.115])

SecureCRT has SSH and works fine. You can also use the free version of OpenSSH (installed on the laptop). It assumes user steen -- you may be able to use the -l switch to change to root. On the Mac, Tim has a program that lets you define the user as well..

On 18 March 2002, I succeeded in using the ssh2 protocol in SecureCRT from Spello (running Win98) to log onto Cyberspace (running Linux), by the IP number. I got full control, but of course no GUI. Ask the UCLA LUG about enabling X windows remotely.

Within that ssh session, I started an ftp session on Cyberspace, but Spello refused the connection. Nor was I able to use CuteFTP Pro from Spello to Cyberspace.

There are commercial packages for remote login from Xi Graphics: at http://www.xig.com, and MetroLink: http://www.metrolink.com. The most promising solution is Virtual Networking, reviewed at http://www2.linuxjournal.com/print.php?sid=4840 in August 2001.

When I tried to start Opera in Cyberspace remotely, I got "opera: cannot connect to X server." However, you can easily run pine on Cyberspace. It's pretty cool to be able to browse Nicco through Cyberspace -- in fact, I can move files between Nicco and Cyberspace with cp or mv commands. How can I move files through ssh?

To transfer files secure from a remote computer:
% scp <your-login>@route66.cs.wisc.edu:</path/to/remote/file> </local/directory>
scp steen@128.97.184.97:/home/steen/C*.jpg *

It actually looks like this will work. It's connecting, storing the RSA1 fingerprint, and asking for a password. It doesn't accept what I type and a return gives me "permission denied". These are troubles at the Windows end; see samba -- I added the trick of allowing non-encrypted passwords, but I'll try going the other way before I reboot.

To transfer to a remote computer:
% scp </local/file(s)/to/transfer> <your-login>@route66.cs.wisc.edu:</remote/dir/to/transfer/ to>
scp D:/Webs/home.html steen@128.97.184.97 /home/steen/KDesktop/home.html

Well, this command has to be given in Windows, not in the remote Linux. You might be able to do this with a ssh client other than SecureCRT -- maybe even OpenSSH running on Win?

Notes from the SuSE installation

Use OpenSSH -- there's a security patch from the online update. Note that OpenSSH also creates sshd, the ssh daemon, which handles requests for logging in from the outside. The configuration file is at /etc/ssh/sshd_config

For simple ssh login, you have what it takes (the daemon sshd, which at least in the new kernel starts at bootup) On 14 December 2001 I successfully logged into gubbio (ssh 128.97.184.152) as steen from www.ssc.ucla.edu. I would like to be able to log in as root, and of course to start KDE. You list who is on the network by the command who. When I tried to start gscanbus, I got:

_X11TransSocketINETConnect: Can't get address for merton
Gtk-WARNING **: cannot open display: merton:0.0.

This is certainly an interesting error; it suggests X11 is attempting to send screens to the remote terminal.

    Note the parameters in /etc/rc.config (not in this order):

    # start the inet daemon in multi-user? ("yes" or "no")
    # this is needed if you have to telnet/rlogin to your own machine.
    # It is also needed for the man page formatter in SuSE Help system.
    START_INETD="no"

    # Allow remote access to your display manager (kdm only for now)
    DISPLAYMANAGER_REMOTE_ACCESS="no"

    # Should the X Font Server "xfs" be started at boot-up? (yes/no)
    # Xfs is the X Window System font server. It supplies fonts
    # to X Window System display servers. This font server works for
    # CID-keyed fonts and TrueType fonts as well.
    # Please have a look at the configuration file /etc/X11/fs/config
    # for more information.
    START_XFS="no"

 

 

top
Debate
Evolution
CogSci

Maintained by Francis F. Steen, Communication Studies, University of California Los Angeles


CogWeb