On Thu, 24 Oct 2019, Paul Slootman wrote:
> Note also that ssh is very particular about permissions of all directories
> concerned, e.g. if /, /root, or /root/.ssh are in any way writeable by
> others, ssh will refuse to use any keys as those may have been
> manipulated. Ideally /root and /root/.s
On Wed, 23 Oct 2019, wes wrote:
> Ok, try ssh -vi /root/.ssh/id_ed25519 localhost
Wes,
This is very interesting:
# ssh -vi id_ed25519 localhost
OpenSSH_7.4p1, OpenSSL 1.0.2t 10 Sep 2019
debug1: Reading configuration data /root/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
On Thu 24 Oct 2019, Rich Shepard wrote:
> On Wed, 23 Oct 2019, wes wrote:
>
> > Ok, try ssh -vi /root/.ssh/id_ed25519 localhost
>
> Wes,
>
> This is very interesting:
>
> # ssh -vi id_ed25519 localhost
Note you're not doing what Wes suggested. You're missing the path to the
identity file, whi
On Thu, 24 Oct 2019, Paul Slootman wrote:
> Note you're not doing what Wes suggested. You're missing the path to the
> identity file, which is OK if your current directory is /root/.ssh .
Paul,
I happened to be in root/s .ssh/ directory when I ran the command.
> First with, and the without the
BTW, did you try already removing the root@ from the client: line?
On Thu 24 Oct 2019, Rich Shepard wrote:
>
> I happened to be in root/s .ssh/ directory when I ran the command.
OK
> > First with, and the without the path?
>
> With the absolute path:
> # ssh -vi /root/.ssh/id_ed25519 localhos
On Thu, 24 Oct 2019, Paul Slootman wrote:
> Or the ssh thing just worked and you never noticed that it was using ssh.
Paul,
That is the case.
> I would change this to just:
> client: salmo.appl-ecosys.com
Done.
> Dirvish will then "know" that it's a local transfer. Adding a username
> forces
On Thu, 24 Oct 2019, Paul Slootman wrote:
> BTW, did you try already removing the root@ from the client: line?
Paul,
Yes. I did.
> Somehow the server rejects the id_ed25519 public key.
This is the continuing problem.
> I see that in my system (Debian) sshd messages are logged in
> /var/log/au
I didn't follow the entire thread, but seeing that it sees your keys but
refuses to use them, sometimes that is caused by sshd being picky about the
permissions on the key file.
THey have to be rw---, which is weird because Linux uses UID=GID, so
group permissions aren't relevant. Please make s
On Thu, 24 Oct 2019, Przemek Klosowski wrote:
> I didn't follow the entire thread, but seeing that it sees your keys but
> refuses to use them, sometimes that is caused by sshd being picky about the
> permissions on the key file.
Przemek,
# ll .ssh/
total 20
-rw--- 1 root root 92 Oct 24 07:
that looks good, so it must be something else. The .ssh directory itself
has to be drwx-- (ls -ld /root/.ssh, or wherever your root's .ssh is)
BTW the 'remote' system is the localhost, which you're ssh-ing to. So look
at the sshd daemon messages on your local system. if your system uses
syste
On Thu, 24 Oct 2019, Przemek Klosowski wrote:
> that looks good, so it must be something else. The .ssh directory itself
> has to be drwx-- (ls -ld /root/.ssh, or wherever your root's .ssh is)
Przemek,
Those are the perms.
> BTW the 'remote' system is the localhost, which you're ssh-ing to
I’m not sure my phone is quoting this entire message. Apologies if this is
messed up.
I find that “ssh -vv” (two v’s) is helpful for debugging permission problems.
--
Eric V. Smith
(301) 502-0945 cell
> On Oct 24, 2019, at 12:03 PM, Przemek Klosowski
> wrote:
>
___
On Thu, 24 Oct 2019, Eric V. Smith wrote:
> I’m not sure my phone is quoting this entire message. Apologies if this is
> messed up.
Eric,
Phone must be too small for the message. :-)
> I find that “ssh -vv” (two v’s) is helpful for debugging permission
> problems.
Here it makes no difference o
On Thu, Oct 24, 2019 at 10:12 AM Rich Shepard
wrote:
>
> > I find that “ssh -vv” (two v’s) is helpful for debugging permission
> > problems.
>
> Here it makes no difference over the output of a single 'v.' The debug2
> rows
> concern ciphers.
>
>
At this point we've established that the SSH clien
On Thu, 24 Oct 2019, wes wrote:
> At this point we've established that the SSH client is doing its job
> properly. The problem resides with the SSH server component. We need to
> find its logs.
>
> Try grep -i ssh /var/log/* and see if anything pops up.
Wes,
Mea culpa! I should have looked for s
On Thu, Oct 24, 2019 at 11:48 AM Rich Shepard
wrote:
>
> /var/log/messages:Oct 21 06:02:02 salmo sshd[11376]: User root from
> 192.168.55.1 not allowed because not listed in AllowUser
>
> I just added root to sshd_config's AllowUsers, then stopped and restarted
> sshd. No joy:
>
> # dirvish --vau
On Thu, 24 Oct 2019, wes wrote:
> Ok, check the logs again after having made that config change? Is the
> error still the same?
Yes.
> Is there any PermitRootLogin related option in sshd_config?
No. Only: AllowUsers rshepard,root
Rich
___
Dirvish mai
On Thu, 24 Oct 2019, wes wrote:
> If that doesn't work, we may have to run sshd in debug mode.
Wes,
That's what we've done: using the -v (verbose) option. I cannot find any
other debug mode than that option.
Regards,
Rich
___
Dirvish mailing list
Dir
On Thu, Oct 24, 2019 at 12:45 PM Rich Shepard
wrote:
> On Thu, 24 Oct 2019, wes wrote:
>
> > If that doesn't work, we may have to run sshd in debug mode.
>
> Wes,
>
> That's what we've done: using the -v (verbose) option. I cannot find any
> other debug mode than that option.
>
>
That was in rega
On Thu, 24 Oct 2019, wes wrote:
> That was in regards to running the _client_ with debug output. Doing this
> with the server is slightly more complicated.
Wes,
Oh. I tried a web search for 'sshd debug' and found no relevant hits.
FWIW, before the old desktop died I regulary used rsync and scp
On Thu, 24 Oct 2019, wes wrote:
> That was in regards to running the _client_ with debug output. Doing this
> with the server is slightly more complicated.
Wes,
Okay.
# /usr/sbin/sshd -D -d -E sshd-debug.log -f /etc/ssh/sshd_config -p
sshd-debug.log:
debug1: sshd version OpenSSH_7.4, OpenSSL
On Thu, Oct 24, 2019 at 1:00 PM Rich Shepard
wrote:
> On Thu, 24 Oct 2019, Przemek Klosowski wrote:
>
> > that looks good, so it must be something else. The .ssh directory itself
> > has to be drwx-- (ls -ld /root/.ssh, or wherever your root's .ssh is)
>
> Those are the perms.
>
You did sh
On Thu, 24 Oct 2019, Przemek Klosowski wrote:
> You did show the perms for the files (shown with ls -l /root/.ssh ) but
> what are the perms for the directory, as shown with ls -ld?
# ls -ld .ssh/
drwx-- 2 root root 4096 Oct 23 15:09 .ssh/
Rich
_
On Thu 24 Oct 2019, Rich Shepard wrote:
> On Thu, 24 Oct 2019, wes wrote:
>
> > Ok, check the logs again after having made that config change? Is the
> > error still the same?
>
> Yes.
>
> > Is there any PermitRootLogin related option in sshd_config?
>
> No. Only: AllowUsers rshepard,root
Then
24 matches
Mail list logo
