Re: attempts to hack in?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux