OpenSSH Summary
Configuration files
Software
Security Make sure that your sshd is installed and configured properly:
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 229When 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 mountpointIf root can do it but others not, issue chmod u+s /usr/bin/fusermountThe 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:
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@spelloNow 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 rsaIt 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_keysThis 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,
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,
You'll be asked for a pw, log in as usual. 5. Test access. Back on the inside machine, issue
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
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
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
Here a script you can run to make the tunnel -- save it as /usr/local/bin/tunnel: #!/bin/bash 10. If you start konqueror on the outside machine:
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 Multi-user sessions: multiuser on 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. 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.
SSH for Windows
When you connect to SSC from the laptop, it's listed like this:
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?
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.
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 _X11TransSocketINETConnect: Can't get address for merton 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") |
|
|
|
|||||
Maintained by Francis F. Steen, Communication Studies, University of California Los Angeles |