<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<blockquote type="cite"
cite="mid:3231c302-27a9-3437-849a-767850d12fd0@linux.ibm.com">
<blockquote type="cite" style="color: #000000;">Yes, that could be
a solution for the problem we discuss, providing both integrity
and confidentiality, without any major OpenBMC development
necessary - but it would mean more operational burden for BMC
admins. The problem with SCP/SFTP in this context is that for
this to work in the same manner as TFTP, the BMC must be an SSH
client - i.e. have some sort of identity/credentials for the
SCP/SFTP server provisioned first. That might not be the easiest
solution to setup, but it's of course possible and can be
automated if OpenBMC provides respective config knobs.
<br>
<br>
Existing ways we have in code-update.md either don't require
credentials (TFTP), so being a client is easy, or are not making
a "client" from BMC, it's the admin who uploads stuff
(SCP/REST).
<br>
</blockquote>
<br>
Yes, that's what I was thinking. (And no, I am not going to
recommend setting up a SCP or SFTP server that allows anonymous
access.)
<br>
<br>
This highlight the need for OpenBMC to put together a guide to
provisioning your BMC. Such as guide would give us a place to
talk about uploading to the BMC SSH client certificates needed to
access and download the firmware images.
<br>
<br>
- Joseph
</blockquote>
<p>Agree, the provisioning guide could be a good point to have this
discussion. However I beieve updates in general is a broader and
more "operational" (i.e. "continuous" as opposed to provisioning
being rather "one-time") topic, so the approach in the
organization/of a given BMC admin can change and I believe
whatever configuration mechanism we develop for this (if at all),
should be available at any point during BMC lifetime, not only at
provisioning, and be architected respectively.</p>
<p><br>
</p>
<p>regards,<br>
Alexander<br>
</p>
<p><br>
</p>
</body>
</html>