On 01Jul2017 07:48, William Oliver <vendor@xxxxxxxxxxxxx> wrote:
On Fri, 2017-06-30 at 18:35 -0700, Rick Stevens wrote:
Uh, mount the USB stick somewhere and use something like:
ssh -i /path/to/usb/stick/name-of-your-identity-file user@host
e.g.
mkdir ~/usbstick
mount /dev/sdb1 ~/usbstick
ssh -i ~/usbstick/my_id_rsa_file rick@xxxxxxxxxxxx
If the mountpoint is always the same you can make this easier with a clause in
your .ssh/config file, eg:
Host *-travelling
IdentifityFile /path/to/usb/mount/id_dsa_travelling
Then you can adjust some clauses for places you access when travelling:
Host home home-*
Hostname name-or-address-of-"home"-machine
and go:
ssh home # when on a personal machine with your key
or
ssh home-travelling # when using the mounted USB key
I believe the identity file must still have the right permissions
(0600
or "rw-------" and that it's the identity file, NOT the public
identity key file.
Yes. ssh will refuse to trust a private key that is readable or writable by
others. Note that the directories leading to the key must also not be
_writable_ by others (eg group write) as that would allow others to switch the
key file out and provide another.
Thanks. I'll give it another try. It may be that I'm just not patient
enough. A couple of years ago, I set up a surveillance camera or two
for a friend and wanted to make them sftp the images to a server. I
swear to God I could never get it to authenticate.
The key file must be private. The ancestor directories must not be writable by
others. At the receiving end, the .ssh/authorized_keys file must not be
writable by others.
For batch use (cron job sending camera images), the key file must not have a
passphrase. _Because_ it would have no passphrase protecting it from use by
others, you should use extra care with what can be done with it - your personal
key should always have a passphrase.
Ideally, such a passphraseless key should be locked down at the remote end, or
the key file very carefully managed. Preferably the remote end would be a
special purpose account eg to store the camera images, not your general purpose
personal account.)
Oh yes: if you make a travelling key, it should be different to your home
machine's key. That way it can be revoked (==> remove the public key from the
relevant authorized_keys files).
Cheers,
Cameron Simpson <cs@xxxxxxxxxx>
Using encryption on the Internet is the equivalent of arranging an armored
car to deliver credit-card information from someone living in a cardboard box
to someone living on a park bench. - Gene Spafford
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx