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

Re: ssh-ing in inside private network



On Tue 31 May 2016 at 20:31:32 (+0100), Lisi Reisz wrote:
> On Thursday 31 March 2016 15:08:24 Brian wrote:
> > On Thu 31 Mar 2016 at 13:27:35 +0100, Lisi Reisz wrote:
> > > On Thursday 31 March 2016 12:28:57 tomas@tuxteam.de wrote:
> > > > 1. Each computer should have an SSH server running (on Debian that
> > > > would be package openssh-server: in Debian it has priority "optional":
> > > > I'd double-check that it's installed)
> > >
> > > It is installed.  How do I check that it is running?
> >
> > Use 'ssh user@somewhere'. 'Connection refused' is a good indication
> > there is no ssh server on port 22.
> >
> > > Previously (under Wheezy) using Fish, I have been getting the first part
> > > of the message and asked if I want to accept the new identification. 
> > > Fish presumably then edited the file.  So I need static IPs fast!  or a
> > > hosts file?  I have some learning to do.  Static IPs I have no problem
> > > over, I just
> >
> > The IP and host in /etc/hosts is fine. Alternatively, with avahi-daemon
> > on the machines you would do 'ssh someone@eros.local'. Use with static
> > or dynamic IPs and not have the bother of maintaining a hosts file.
> 
> Right, I am making (slow) progress.  My next question is at the end after my 
> progress report.
> 
> Here is how far I have got:
> 
> I tried and failed to edit ~/.ssh/known_hosts because it was encrypted. So I 
> googled, and set it in ssh_conf to unencrypted.  It remained encrypted, of 
> course, so I did the following:

The commands in https://lists.debian.org/debian-user/2016/03/msg01299.html
handle encrypted ~/.ssh/known_hosts without your having to weaken security.

$ ssh-keygen -l -v -f ~/.ssh/known_hosts -t ecdsa -F foo        <-test
$ ssh-keygen -f ~/.ssh/known_hosts -t ecdsa -R foo              <-remove
(foo is the hostname or IP#.)

> [...]
> 
> So - the key changed when you change operating system.  A nuisance but hardly 
> surprising, and easily remediable after you kind souls showed me the way.

If you copy the keys from one OS to another (on the same host, of course),
you shouldn't have this rigmarole. The files concerned are:

$ ls -l1 /etc/ssh/*key*
-rw------- 1 root root  668 Apr 28  2014 /etc/ssh/ssh_host_dsa_key
-rw-r--r-- 1 root root  599 Apr 28  2014 /etc/ssh/ssh_host_dsa_key.pub
-rw------- 1 root root  227 Apr 28  2014 /etc/ssh/ssh_host_ecdsa_key
-rw-r--r-- 1 root root  171 Apr 28  2014 /etc/ssh/ssh_host_ecdsa_key.pub
-rw------- 1 root root 1679 Apr 28  2014 /etc/ssh/ssh_host_rsa_key
-rw-r--r-- 1 root root  391 Apr 28  2014 /etc/ssh/ssh_host_rsa_key.pub
$ 

The posting referred to above also contained a quick fix to temporarily
circumvent said rigmarole (without copying the keys) if you need to
flip between OSes a lot (ie use /dev/null as your known_hosts file).

ssh -o GlobalKnownHostsFile=/dev/null -o UserKnownHostsFile=/dev/null user@host

Cheers,
David.


Reply to: